The Domain Agent Design Method: A 9-Part Template
Your bar: design any business agent with one repeatable 9-part template — responsibilities, tools, context, memory, runtime, eval, security, approval gates, ROI.
Your bar: stop designing agents ad hoc. Take any business domain — billing, support, SRE, research — and run it through the same nine-part template, in the same order, every time. By the end you can answer the question an architect actually gets asked: given a domain, what does the agent own, what can it touch, where does a human have to sign off, and is it worth building at all? 1 The later lessons just instantiate this template per domain — this is the method they share.
This track turns the archetypes from AI Agents · Lesson 4 (Business agent architecture) into a repeatable design discipline. The whole method is four moves:
The Boundary & the Surface
A domain agent is an LLM using tools in a loop, scoped to one business domain with a defined goal, a fixed tool surface, and an owner. The design artifact is the boundary, not the model — and you draw it before you wire a single tool. 2
Definition & why it exists
Is A domain agent does one job: answer billing questions, triage an incident, draft a research brief. Its responsibility boundary is its API contract — inputs it accepts, actions it owns, things it must defer, escalate, or refuse.
Why it exists A general assistant has an open goal and an unbounded surface — you can’t evaluate it, secure it, or size its risk. Narrow the job and all four become tractable.
Like (world) A job description. A teller cashes checks and answers account questions; they don’t approve mortgages or give tax advice. The role is the boundary — written before the desk is built.
Like (code) A service interface. You define the contract (accepted requests, owned operations, errors it throws) before you implement the handlers. Tools are the implementation; the boundary is the interface.
Boundary → surface: every tool widens the reach
✓ Boundary first. Choosing tools first decides the reach before the job — you end up with a wide surface and no contract for what’s out of bounds.
✗ “More tools make the agent more capable, so add everything it might need.”
✓ Every tool added widens capability and blast radius. The smallest surface that covers the job is the goal — unused reach is pure risk.
📥 Memory rule: Boundary before tools. The boundary is the agent’s contract; the tool surface is the smallest set that fits it.
Memory check
What is a domain agent’s “design artifact”?
→ the responsibility boundary — inputs accepted, actions owned, things deferred/escalated/refused; not the modelWhy draw the boundary before choosing tools?
→ the boundary tells you the smallest tool surface that covers the job; tools-first decides the reach before the jobWhat does adding a tool cost you?
→ more capability AND more blast radius; an unused tool is risk you carry for nothing
M1 — A teammate wants to give the support agent a “run any SQL” tool “so it can answer anything.” Talk them out of it.
Hit these points: “run any SQL” is the widest possible surface — it can read every tenant’s data, mutate rows, drop tables → that’s enormous blast radius for a job that needs three read tools → the boundary says the agent answers support questions, so the surface is read-order, read-account, search-KB — scoped, parameterized, least-privilege → an open SQL tool also makes injection catastrophic: untrusted ticket text could steer a query → replace it with narrow tools that encode exactly the reads the boundary allows, and the agent loses no real capability while shedding most of the risk.
The Machinery (Context, Memory, Runtime, Eval, Security)
Parts 3–7 are the machinery the agent runs on. Two of them — context and memory — you already designed in Context Engineering; here you just instantiate them per domain. 2
The five middle parts, at a glance
| Part | What it decides | Where it comes from |
|---|---|---|
| 3 · Context | What goes in the window each turn (instructions, retrieved docs, the request) | Context Engineering — curate before the model runs |
| 4 · Memory | Persisted state retrieved back into context (prior tickets, learned facts) | Context Engineering — reachable only by retrieval |
| 5 · Runtime | The loop, tool execution, retries, step/cost limits | AI Agents — the orchestration layer |
| 6 · Evaluation | How you score the agent before and after ship | New per domain — pick the metric that matches the job |
| 7 · Security | Untrusted input, least privilege, the failure modes | OWASP LLM Top 10 — the threat model |
Internal working: the runtime is the agent loop with guard-rails
Failure modes: what part 7 (security) has to contain
| Failure mode | How it shows up | What contains it |
|---|---|---|
| Excessive agency | Agent takes a high-blast action it shouldn’t (refund, delete, deploy) | Smallest tool surface + approval gate on the action |
| Prompt injection | Untrusted input (ticket, doc) steers the agent off its boundary | Treat all input as data; scope tools; least privilege |
| Insecure tool use | A tool with too much reach (open SQL, arbitrary egress) is abused | Narrow, parameterized tools that encode the boundary |
| Runaway loop | Agent loops, burning tokens and tool calls with no progress | Step limit + cost cap in the runtime |
✓ They’re the same problem you already designed in Context Engineering. Per domain you only choose what to retrieve and persist — the mechanics carry over.
✗ “Evaluation can wait until after we ship — we’ll watch it in prod.”
✓ Pick the metric before you ship (deflection, resolution quality, escalation correctness). Without a score you can’t tell a regression from noise, or justify the ROI.
📥 Memory rule: The runtime holds the limits the prompt can’t enforce. A step cap, a cost cap, and a gate on high-blast tools live in code — not in an instruction asking the model to behave.
Memory check
Which two template parts come straight from Context Engineering?
→ context (3) and memory (4) — you instantiate them per domain, not reinvent themWhere do limits and approval gates sit in the loop?
→ on the “act” step — the runtime caps steps/cost and pauses high-blast tool calls for a humanName the OWASP-style failure mode behind an unsupervised refund.
→ excessive agency — contained by the smallest surface plus an approval gate on the action
M2 — Your agent occasionally loops for 40 steps and burns the token budget without resolving the ticket. Which template parts are you missing?
Hit these points: the symptom is a runaway loop, so the gap is in part 5 (runtime) — no step cap and no cost cap → add a hard step limit and a per-session token/cost ceiling so the loop terminates and escalates instead of spinning → but a loop that never resolves is also an eval gap (part 6): you have no resolution metric telling you it’s failing → and possibly a context gap (part 3): if the right info never lands in the window, the model keeps re-trying → fix the runtime first to stop the bleeding, then instrument eval to catch it earlier, then check whether retrieval is feeding the loop what it needs.
Gates, ROI & the Worked Example
Parts 8–9 are the decisions that make or break the agent in production: where a human signs off (sized to blast radius) and whether it’s worth building at all. Then we walk the whole template once on a Support agent. 6
Approval gates — sized to blast radius
ROI — and why the gate design decides it
Is ROI = value returned (deflected human work) vs all-in cost: tokens + tool calls + human-review time + failure/cleanup cost. Not just the model bill.
Why it exists An agent that needs review on every action often costs more than the human it replaced — you pay the model and the reviewer. ROI is the build-or-kill test.
Like (world) Hiring an assistant you must double-check on every task. If you re-do everything they do, you’ve added cost, not capacity.
Like (code) A cache with a 0% hit rate: all the machinery, none of the saving. If the gate fires on every action, the deflection never materializes.
Build vs buy — commodity plumbing vs domain glue
✓ The loop, model, tool protocol, and eval harness are commodity — buy them. Your differentiation is the boundary, tools, and policies no vendor can know — build those.
✓ No vendor knows your business rules, refund limits, or risk tolerance. Buy the platform; build the domain glue. That glue is the agent’s actual value.
The worked example: a Support agent, all nine parts
| # | Part | Support agent instantiation |
|---|---|---|
| 1 | Responsibilities | Answer account/order questions, draft replies, issue small refunds; refuse legal/medical advice and anything outside support |
| 2 | Tools | read order, read account, search KB, issue refund, escalate to human — smallest set that covers the job |
| 3 | Context | The user’s question + retrieved KB articles + the order record, scoped to this customer |
| 4 | Memory | Prior tickets for this customer, retrieved into the window — not dumped wholesale |
| 5 | Runtime | Bounded observe–think–act loop with retries and a step/cost limit |
| 6 | Evaluation | Deflection rate, resolution quality, escalation correctness on a labelled ticket set |
| 7 | Security | Treat ticket text & KB content as untrusted; scope retrieval by customer; least-privilege tools |
| 8 | Approval gates | Reads auto-allow; refund ≤ $50 auto; refund > $50 and escalate-to-billing pause for a human |
| 9 | ROI / build-buy | Deflected agent-hours vs tokens + review time; buy the runtime, build the boundary/tools/policies |
📥 Memory rule: Gate by blast radius, price by all-in cost. Every gate adds safety and subtracts ROI — set the auto-approve threshold where the blast radius is acceptable.
Memory check
What decides where an approval gate goes?
→ the blast radius of the action — gate the irreversible/fan-out, auto-allow the zero-blast readsWhat’s in “all-in cost” beyond the model bill?
→ tool calls + human-review time + failure/cleanup cost; review time is the one that quietly kills ROIDefault build-vs-buy for a domain agent?
→ buy the commodity plumbing (model, runtime, tool protocol, eval), build the domain glue (boundary, tools, policies)
M3 — Leadership wants the support agent to auto-approve all refunds “to maximize deflection and ROI.” What do you say?
Hit these points: deflection and ROI aren’t the same thing — auto-approving every refund maximizes deflection but exposes the full blast radius of the refund tool → a confused or injected agent can now issue unbounded refunds with no human in the path; one incident’s cleanup cost can dwarf months of savings → the right move is a threshold: auto-allow refunds up to a bounded cap where the blast radius is acceptable, gate the rest → that keeps most of the deflection (most refunds are small) while bounding the worst case → then measure: if review on the gated tail is eating the savings, raise the cap deliberately with eyes on the blast radius — don’t remove the gate to chase an ROI number.
Retrieval practice — test the method
Q1. In the 9-part template, what must you design <em>before</em> you choose the agent's tools?
- The exact prompt wording that tells the model how to behave each turn
- The memory backend that will persist state across separate sessions
- The responsibility boundary: what it owns, defers, escalates, refuses
- The evaluation dashboard you will watch once the agent is in production
Q2. Why does adding one more tool to an agent's surface carry a cost?
- It widens both the agent's capability and its blast radius if misused
- It always forces a full retrain of the underlying language model first
- It removes the agent's ability to refuse requests outside its remit
- It converts the agent from a workflow into an unbounded assistant
Q3. Blast radius is best described as…
- The number of tokens an agent consumes across one full reasoning loop
- The latency an agent adds versus a human handling the same request
- The count of distinct tools wired into the agent's available surface
- The worst-case damage if one action is wrong, malicious, or repeated
Q4. Which cost most often makes a domain agent's ROI negative?
- The one-time price of buying the agent runtime platform from a vendor
- The human-review time when an approval gate fires on every action
- The disk storage used to persist the agent's long-term memory state
- The cost of writing the system prompt that defines the agent's role
Q5. For a domain agent, the default build-vs-buy split is…
- Build everything in-house because no vendor understands AI agents well
- Buy everything from one vendor because the loop is the hard part to get right
- Buy the commodity plumbing; build the domain glue (boundary, tools, policies)
- Build the model and runtime; buy the business rules from a consultancy
Interview — pick your bar
Answer out loud in ~60s, then reveal. Core = recall · Senior = trade-offs & failure modes · Staff = synthesis under ambiguity · System Design = open design round (a different axis, not a harder level).
What is a domain agent, and how is it different from a general assistant?
List the 9 parts of the design template in order, and say which one comes first.
What is blast radius, and how does it relate to approval gates?
What's the default build-vs-buy answer for a domain agent, and why?
A teammate says "we'll add a system-prompt rule: never refund over $50." Push back.
What goes into an agent's ROI calculation, and what's the most common trap?
Your agent occasionally loops for dozens of steps, burning budget without resolving. Which template parts failed?
Why is the tool surface the hinge that everything downstream turns on?
You're standing up agents for five business domains at once. How do you avoid five bespoke designs?
Two proposed agents are identical except one has a read-only surface and the other can also write. Compare the full design implications.
How does this track build on AI Agents and Context Engineering, and what's genuinely new here?
- Clarify scope: what domain, what's the goal, what's the cost of a wrong action vs a wrong answer, who owns it?
- Part 1 — responsibilities: state what it owns, what it defers/escalates, what it refuses. This is the contract.
- Part 2 — tools: the smallest surface that covers the boundary; flag each tool's blast radius as you list it.
- Parts 3–5 — context, memory, runtime: what's in the window, what persists, the loop + limits.
- Part 6 — evaluation: the metric that matches the job (deflection, resolution, escalation correctness).
- Part 7 — security: untrusted input, least privilege, map to the OWASP failure modes.
- Part 8 — approval gates: gate by blast radius — auto-allow reads, cap cheap writes, pause irreversible/fan-out.
- Part 9 — ROI / build-vs-buy: all-in cost vs deflected work; buy plumbing, build glue; ship-or-kill.