Worked example: a support agent
A vendor-neutral architecture review of one production AI agent across all five BROCS obligations.
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.
- Give every case one trace identifier across retrieval, model calls, tool calls, and human handoff.
- Put model, prompt, route, tool permissions, and refund limit in a versioned configuration record.
- Send a small share of traffic to each change and define the signal that stops the rollout.
- Make retrieval enforce the caller’s customer and regional permissions before any document reaches the model.
- 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 or take the buyer questions into the architecture review.