# Worked example: a support agent

> A vendor-neutral architecture review of one production AI agent across all five BROCS obligations.

Source: https://brocs.fyi/resources/worked-example/
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---


Frameworks become useful when they force a decision. This example applies BROCS to a
fictional but ordinary system: a customer-support agent that answers product questions,
reads account history, updates tickets, and issues refunds within a fixed limit.

The example is illustrative. It is not a reference architecture, benchmark, or product
recommendation. Its purpose is to show the level at which a BROCS review should operate.

## Start with the operating boundary

The agent runs in two regions. It retrieves from a product knowledge base, reads and
writes the customer relationship system, creates support tickets, and may issue refunds
up to $200. Larger refunds and low-confidence answers go to a human. Customer records
must remain in their assigned region.

That paragraph matters more than the model choice. It names where data may move, which
actions change the world, what requires approval, and what the organization has promised
to customers. Those constraints drive all five letters.

## Review the evidence, not the diagram

| Letter | Capability that should exist | Evidence to ask for |
| --- | --- | --- |
| **Build** | A sanctioned path for changing prompts, tools, retrieval logic, and evals | A versioned change, its test result, reviewer, deployment record, and time from approved change to a running environment |
| **Run** | A durable runtime with regional placement, secrets, state, retries, and a defined provider-failure path | A deployment manifest, region policy, checkpoint or queue behavior, restore result, and a demonstrated failover |
| **Observe** | One trace across retrieval, model calls, tools, human handoff, quality, latency, and cost | A real production trace, an eval trend, an alert with an owner, and cost per resolved case rather than cost per token alone |
| **Control** | Versioned configuration, identity, staged rollout, rollback, routing, and action limits | The current configuration, who changed it, canary criteria, a rollback drill, and proof that the refund tool can be disabled without taking down answers |
| **Secure** | Permissions and policy enforced at retrieval and tool boundaries | A denied cross-customer retrieval, scoped tool credentials, retention behavior, a prompt-injection test, and an incident record that reconstructs what the agent accessed and changed |

The review is not complete because each row has an owner. It is complete when the owner
can produce the evidence without reconstructing it by hand.

## A plausible first scoreline

Suppose the team can demonstrate all four Build statements, three Run statements, one
Observe statement, one Control statement, and two Secure statements. The scoreline is
`B4 R3 O1 C1 S2`.

That is not a grade. It says the delivery path is ahead of the operating controls. The
team can ship changes faster than it can explain or reverse their effects. Launch risk
therefore sits in Observe and Control, even if a security review has already approved
the model provider.

The useful follow-up is not “How do we get to 20?” It is:

> Which unchecked capability would make the next credible incident shorter, smaller,
> or less likely?

For this system, the answer is an end-to-end action trace and a tested rollback path.
Without the trace, the team cannot tell which retrieved document, model response, or tool
call produced a bad refund. Without rollback, it may know exactly what happened and still
be unable to stop it safely.

## The first operating increment

A credible first increment can be narrow.

1. Give every case one trace identifier across retrieval, model calls, tool calls, and
   human handoff.
2. Put model, prompt, route, tool permissions, and refund limit in a versioned
   configuration record.
3. Send a small share of traffic to each change and define the signal that stops the
   rollout.
4. Make retrieval enforce the caller's customer and regional permissions before any
   document reaches the model.
5. Exercise one rollback and one provider-outage path in the environment that will
   carry production traffic.

None of those steps requires replacing the stack. Together they turn an impressive
agent into the beginning of an operable system.

## Questions for the room

Use these before debating suppliers:

- Can someone show one case from user request to every read, model call, action, and
  final outcome?
- Which changes can ship without code, and are those changes still reviewed and
  reversible?
- What happens to in-flight work when the model provider, retrieval system, or ticketing
  tool is unavailable?
- Does the refund tool receive standing authority, or authority scoped to one approved
  case?
- Can the organization prove that a European customer record stayed in its assigned
  region?
- Who can stop actions while preserving read-only answers?

If the answers require several teams to assemble a special presentation, the surface is
not yet producing operational evidence. That is the gap BROCS is meant to expose.

Next: [score your own surface](/resources/assessment/) or take
[the buyer questions](/resources/questions/) into the architecture review.