# Brida Reflex — Agent Guide

Revision: 2026-09-21

Use this guide when a person asks an AI agent to use, implement, discover, configure, test, or optimize Brida Reflex.

## What Reflex is

Brida Reflex gives recurring events a small, fast, typed semantic decision.

An event can come from almost anywhere: a customer message, a lead, a document, an invoice, a task, an alert, a browser action, a research claim, an application event, or another business process.

A Reflex answers a bounded semantic question about that event — Binary, Choice, or Score — cheaply enough to sit before a larger workflow, human review, or expensive AI reasoning.

A Reflex is not autonomous authority. It returns semantic evidence and a recommendation. The calling application, workflow, or human keeps authority over protected actions.

## Choose the mode first

Do not run the same discovery interview for every request.

### Known use case — implement it directly

If the user already names a use case, goal, feature, workflow, or concrete bounded decision:

1. Inspect the project, files, connected tools and conversation context already available.
2. Map the request to the closest existing official/public Reflex contract or focused Reflex skill.
3. Do not ask broad company/workflow questions that are not needed for this implementation.
4. Ask only when a missing fact truly blocks progress and cannot be recovered from available context.
5. Keep deterministic parsing, permissions, freshness, exact policy and side effects in host code.
6. Use the current MCP, released SDK or REST surface that fits the environment.
7. Execute the bundled/canonical synthetic fixtures through the real execution surface before claiming the integration works.
8. Add separately authored holdout/evaluation cases before production reliance.
9. Revalidate current state and authorization before any protected downstream action.

Examples: semantic content blocking/AdBlock, support triage, OCR routing, completion verification, model-effort routing, context retention, issue triage, retrieval relevance and claim verification.

### Open-ended discovery — keep it brief

Use discovery only when the user has not identified the decision they want.

1. Inspect available context before asking anything.
2. Find repeated events where a small semantic decision could avoid unnecessary model, agent or human work.
3. Prefer decisions that are frequent, latency-sensitive or expensive to escalate every time.
4. Ask at most a few high-value questions, and only when they materially change the candidates.
5. Return no more than three strong candidates.
6. Start implementing the best candidate unless the user asked only for analysis.

For each candidate define:

- event/state;
- exact bounded question;
- Binary, Choice or Score;
- explicit branches;
- uncertainty/review behavior;
- deterministic prechecks;
- protected authority that stays outside Reflex;
- validation plan.

It is valid to conclude that deterministic code or a larger workflow is the right tool instead.

### New Custom Reflex — design the smallest contract

If no existing Reflex fits:

1. define the minimum bounded state;
2. define one or more narrow Binary, Choice or Score questions;
3. keep branch policy explicit and deterministic;
4. include an explicit uncertain/default path when consequences require it;
5. use synthetic or properly redacted fixtures;
6. keep the output recommendation-only;
7. activate only through the currently supported Organization-scoped authoring flow.

Do not invent arbitrary executable hooks, provider credentials, network destinations or tool authority inside the Reflex definition.

### Verification / benchmark — test, do not assume

When asked whether a Reflex works or whether one engine/model is better:

- distinguish raw semantic-answer quality from final branch accuracy under policy thresholds;
- measure abstention/review rate, calibration, selective accuracy, latency and error coverage where relevant;
- use separate calibration/train/dev data and holdout evidence;
- do not tune thresholds on the same holdout later reported as unseen evidence;
- never turn third-party benchmark claims into Brida performance claims.

## Agent skills

The public Reflex repository provides:

- `brida-reflex` — general intent-first implementation/discovery skill;
- `brida-reflex-<use-case-id>` — focused skills generated from canonical public Custom Reflex examples.

If the environment supports agent skills and the use case is already known, prefer the focused skill. It bundles the exact public contract, playbook and synthetic fixtures for that case.

Install the general skill with:

npx skills add brida-ai/reflex@brida-reflex

For a known case, install only that focused skill, for example:

npx skills add brida-ai/reflex@brida-reflex-semantic-content-blocking

Do not require a skill installation when the environment can already read the public contract directly.

## General design rules

Use deterministic code first for:

- exact parsing and schema validation;
- stable identifiers and exact matching;
- authentication and authorization;
- allow/deny lists;
- hard invariants;
- current-state/freshness checks;
- arithmetic;
- browser/tool/file permissions;
- side-effect execution.

Use Reflex only for the bounded semantic remainder.

A high probability or low-risk branch is not permission. Keep payments, deploys, external messages, publication, account changes, browser actions, purchases, merges and destructive mutations under normal application/human authority.

## Useful patterns

Good Reflex candidates include:

- **Sales** — lead fit, follow-up worthiness, research escalation.
- **Support** — self-serve, queue, escalate.
- **Documents** — extraction route, review/exception gate, evidence relevance.
- **Operations** — run now, defer, investigate, human attention.
- **Content** — quality score, policy review, semantic blocking, sponsor detection.
- **Research** — event relevance, retrieval relevance, claim verification.
- **Browser/computer use** — action risk, clutter relevance, semantic blocking.
- **Software** — issue triage, change classification, review depth, test relevance, completion evidence, execution-failure classification.
- **Agents** — wakeup/progress, model effort, context retention, memory relevance.
- **Interactive systems** — turn state, bounded game/simulation actions.
- **Scoring** — bounded rubrics whose thresholds remain deterministic host policy.

Do not force a dynamic runtime candidate catalog into a static Choice contract. Generate/authorize candidates in code and evaluate them per candidate until the public contract supports first-class dynamic candidate sets.

## Official starting points

- **Agent Wakeup** — decide whether an event deserves expensive agent work.
- **Agent Router** — recommend a bounded route class.
- **Context Pruner** — identify removable semantic context.
- **Tool Risk** — provide an advisory semantic risk signal.
- **Quality Gate** — recommend pass, review, or stop-review.

Hosted availability can differ from the public recipe catalogue. Query the Brida API/MCP surface rather than assuming every public recipe is executable.

## Custom Reflex

A Custom Reflex is a private, Organization-scoped versioned semantic decision for the user's own recurring event.

A typical Custom Reflex contains:

- bounded state;
- Binary, Choice, or Score questions;
- bounded decision branches;
- synthetic/redacted fixtures and evals;
- explicit activation;
- immutable active versions.

Authoring requires `reflex:write`; read/run authority alone is not enough. Draft fixture evaluation uses the normal Reflex execution pipeline and consumes bounded Decision Capacity. Repeating the same evaluation is idempotent rather than a second provider call.

If the current Brida deployment does not expose the required authoring/integration surface, prepare the proposed definition and fixtures, explain the gap, and do not pretend it was activated.

## Safety and data

During the current Free Preview:

- do not send sensitive personal or regulated-sensitive data unless the active Brida route explicitly permits it;
- never put provider credentials or reusable secrets into Reflex state;
- keep reusable API credentials server-side rather than in browser/mobile/client bundles;
- do not treat a Reflex result as authorization;
- preserve human/application authority for protected side effects.

## Connect

Start at:

- Reflex product: https://brida.ai/reflex
- Explore use cases: https://brida.ai/reflex/use-cases
- Start free: https://brida.ai/reflex/signup
- Open-source Reflex registry/examples/skills: https://github.com/brida-ai/reflex
- Brida SDK: https://github.com/brida-ai/sdk

When authenticated, use the available Brida MCP tools or REST/SDK contract to list current hosted Reflexes before selecting one.

## Free Preview

The current product is a no-card Free Preview. Fair-use and rate limits apply. Do not assume unlimited capacity or automatic paid overage.

## Product principle

Give recurring events the smallest useful decision.

Use deterministic code for exact rules. Use Reflex for bounded semantic judgment. Escalate to larger AI workflows or humans only when the event actually deserves them.