# Brida Reflex — Agent Guide

Revision: 2026-09-20

Use this guide when a person gives you the Brida Reflex bootstrap prompt.

## What Reflex is

Brida Reflex gives recurring events a small, fast, typed 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.

## Your job

Start with the user's real work, not with the API.

1. Briefly understand the user's company, role, workflow, process, product, or automation.
2. Identify recurring events where someone or something repeatedly has to make a small decision.
3. Look for decisions where frequency, latency, review cost, or unnecessary expensive AI work makes a cheap Reflex valuable.
4. For each candidate, define:
   - the event/state that arrives;
   - the exact bounded question;
   - Binary, Choice, or Score;
   - explicit branches, including uncertainty/review;
   - what deterministic rule or protected authority must remain outside Reflex.
5. Show the user the 3 best candidates for their context. Explain practical value and the failure mode in plain language.
6. Prefer an official Brida Reflex when one matches. Otherwise, if current Brida authoring tools are available, propose a private Custom Reflex.
7. Only after the use case is clear, choose the best integration surface for the user's environment: MCP, Brida SDK, or REST/API.
8. Test with synthetic or user-approved non-sensitive examples before production use.
9. Ask before activating configuration or making protected changes.

It is valid to conclude that Reflex is not useful for a candidate. If deterministic code solves the decision reliably, recommend code instead.

## Useful patterns

Think broadly. Good Reflex candidates can include:

- **Sales** — is this inbound lead worth follow-up, deeper research, or review?
- **Support** — should this message self-serve, queue, or escalate?
- **Documents** — should this invoice/document continue, verify, or go to review?
- **Operations** — should this task run now, defer, or ask a human?
- **Content** — does this output publish, revise, or reject against a bounded rubric?
- **Research** — should this claim continue, be verified, or stop the workflow?
- **Browser/computer use** — is this proposed action a candidate, review, or block?
- **Software events** — ignore, batch, or wake an expensive agent/workflow?
- **Routing/classification** — which allowed route or category best matches this event?
- **Scoring** — how strongly does this event match a small, explicit rubric?

The user may have a much better domain-specific event. Do not force their work into these examples.

## 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.

A Custom Reflex is declarative. Do not upload or invent arbitrary executable hooks as part of the Reflex definition.

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 Custom Reflex authoring yet, prepare the proposed definition and fixtures, explain what is missing, 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 a Reflex state;
- do not treat a low-risk Reflex result as authorization;
- preserve human/application authority for money movement, deployment, publication, account changes, or other protected side effects.

## Connect

Start at:

- Reflex product: https://brida.ai/reflex
- Explore use cases: https://brida.ai/reflex/use-cases
- Sign up: https://brida.ai/reflex/signup
- Open-source Reflex registry/examples: 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 the currently 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.