Lesson 1 · Domain Agent Design · Senior

The Domain Agent Design Method

~13 min · 3 modules · one repeatable 9-part template for designing any business agent, walked once on a worked example

Published

ResponsibilitiesTool surfaceApproval gatesBuild vs buyROI

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:

Draw the responsibility boundary before any tool

size the tool surface — it is the agent’s reach

place approval gates by blast radius

then run the ROI / build-vs-buy test

One template · nine parts · same order every domain 1 · Responsibilities the boundary 2 · Tools the surface 3 · Context the window 4 · Memory persisted state 5 · Runtime the loop 6 · Evaluation how you score it 7 · Security untrusted input 8 · Approval gates by blast radius 9 · ROI / build-buy ship or kill Boundary (1) sets the surface (2) → surface sets the risk (6–7) → risk sets the gates (8) → value decides ship (9) Parts 3–5 are the machinery the agent runs on; 1–2 and 8–9 are the design decisions you own. Per-domain lessons (billing, SRE, research…) don't reinvent this — they fill it in. The more an agent can do unsupervised, the more an approval gate matters.
The method on one page. You walk the nine parts in order because each one constrains the next: the boundary decides the tool surface, the surface decides the blast radius, the blast radius decides where humans sign off, and the ROI test decides whether you build it at all.1
1

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 cheques 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

Draw the boundary first, then fit the surface to it 1 · Responsibility boundary OWNS: answer, draft, small refund DEFERS: large refund → human REFUSES: legal / medical advice REFUSES: anything outside support the contract: what's in, what's out implies 2 · Tool surface (smallest that fits) read order · read account · search KB — zero blast issue refund — bounded write escalate to human — hand-off each tool = more capability + more blast radius
The tool surface is the agent's reach.3 Fit the smallest surface that covers the boundary: every tool you add widens what the agent can do — and what can go wrong if it's confused, jailbroken, or looping. A tool you didn't add is blast radius you don't carry.
✗ “Pick the tools first, then figure out what the agent should do.”

✓ 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 model

  • Why 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 job

  • What 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.

2

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

PartWhat it decidesWhere it comes from
3 · ContextWhat goes in the window each turn (instructions, retrieved docs, the request)Context Engineering — curate before the model runs
4 · MemoryPersisted state retrieved back into context (prior tickets, learned facts)Context Engineering — reachable only by retrieval
5 · RuntimeThe loop, tool execution, retries, step/cost limitsAI Agents — the orchestration layer
6 · EvaluationHow you score the agent before and after shipNew per domain — pick the metric that matches the job
7 · SecurityUntrusted input, least privilege, the failure modesOWASP LLM Top 10 — the threat model

Internal working: the runtime is the agent loop with guard-rails

Runtime = the agent loop + limits + gates observe request + tool results think (LLM) choose next action act (tool) call the surface repeat until done or limit hit 3 Context + 4 Memory curated window, retrieved state into observe limits (5) + gates (8) sit on "act" step cap · cost cap · high-blast tools pause for a human The reason-then-act loop is what makes it an agent, not a chatbot — grounding each action in the last observation.
The runtime wraps the observe → think → act loop with the things that keep it safe: a step/cost limit so it can't run forever, and approval gates on the act step for high-blast tools. Reasoning interleaved with acting — grounding actions in observations — is the pattern underneath every domain agent.4

Failure modes: what part 7 (security) has to contain

Failure modeHow it shows upWhat contains it
Excessive agencyAgent takes a high-blast action it shouldn’t (refund, delete, deploy)Smallest tool surface + approval gate on the action
Prompt injectionUntrusted input (ticket, doc) steers the agent off its boundaryTreat all input as data; scope tools; least privilege
Insecure tool useA tool with too much reach (open SQL, arbitrary egress) is abusedNarrow, parameterized tools that encode the boundary
Runaway loopAgent loops, burning tokens and tool calls with no progressStep limit + cost cap in the runtime
✗ “Context and memory are new problems I solve fresh for each agent.”

✓ 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 them

  • Where 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 human

  • Name 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.

3

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

Blast radius decides where the gate goes read order / account / KB ✓ auto-allow — zero blast radius issue refund ≤ $50 ✓ auto-allow under a bounded cap refund > $50 · close account · escalate to billing ⚠ gate — pause for a human delete / bulk action across many records ⚠ gate — irreversible & fan-out The valve between "agent proposed" and "system did" — placed where blast radius exceeds trusted autonomy. More unsupervised reach → the gate matters more, not less.
An approval gate is the valve between "agent proposed" and "system did."6 Gate by action, not globally: auto-allow the zero-blast reads, cap the cheap writes, and pause the irreversible or fan-out actions for a human. Sizing the blast radius of each action is what tells you where the gate belongs.

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

✗ “Building an agent platform from scratch is our differentiation.”

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

✗ “Buy the whole thing — the vendor knows agents better than we do.”

✓ 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

#PartSupport agent instantiation
1Responsibilities

Answer account/order questions, draft replies, issue small refunds; refuse legal/medical advice and anything outside support

2Tools

read order, read account, search KB, issue refund, escalate to human — smallest set that covers the job

3ContextThe user’s question + retrieved KB articles + the order record, scoped to this customer
4MemoryPrior tickets for this customer, retrieved into the window — not dumped wholesale
5RuntimeBounded observe–think–act loop with retries and a step/cost limit
6EvaluationDeflection rate, resolution quality, escalation correctness on a labelled ticket set
7Security

Treat ticket text & KB content as untrusted; scope retrieval by customer; least-privilege tools

8Approval gatesReads auto-allow; refund ≤ $50 auto; refund > $50 and escalate-to-billing pause for a human
9ROI / build-buyDeflected 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 reads

  • What’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 ROI

  • Default 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?

Q2. Why does adding one more tool to an agent's surface carry a cost?

Q3. Blast radius is best described as…

Q4. Which cost most often makes a domain agent's ROI negative?

Q5. For a domain agent, the default build-vs-buy split is…

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?
Hit these points: a domain agent is an LLM using tools in a loop, scoped to one business domain (billing, support, SRE) with a defined goal, a fixed tool surface, and an owner → a general assistant has an open-ended goal and an unbounded surface; the domain agent does one job → the design artifact is the boundary, not the model → because the job is narrow you can actually evaluate it, secure it, and size its blast radius → the model is interchangeable; the boundary, tools, and policies are what you own.
List the 9 parts of the design template in order, and say which one comes first.
Hit these points: (1) responsibilities — the boundary, drawn first → (2) tools — the surface → (3) context → (4) memory → (5) runtime → (6) evaluation → (7) security → (8) approval gates → (9) ROI / build-vs-buy → responsibilities first because the boundary defines the surface, the surface defines the risk, the risk defines the gates, and value decides whether you ship at all.
What is blast radius, and how does it relate to approval gates?
Hit these points: blast radius = the worst-case scope of damage if one action is wrong, malicious, or repeated → a read-only query has near-zero blast radius; an irreversible write or a fan-out to many records has large blast radius → the rule: the more an agent can do unsupervised, the more an approval gate matters → so you gate by action — auto-allow the safe reads, pause the high-blast writes for a human.
What's the default build-vs-buy answer for a domain agent, and why?
Hit these points: split the system into commodity plumbing (model, runtime loop, tool protocol, eval harness) and domain glue (boundary, tools, policies, gates) → the plumbing is the same for every domain — buy it → the glue encodes your business rules and risk tolerance, which no vendor can know — build it → the call is really "where is our differentiation," and it's in the boundary and policies, not the runtime.
A teammate says "we'll add a system-prompt rule: never refund over $50." Push back.
Hit these points: a prompt rule is a request to the model, not an enforced control — it can be ignored, overridden, or jailbroken via injected input → a refund over $50 is a high-blast, irreversible write; that's exactly where the boundary must be enforced in code → enforce it in the tool: the refund tool caps the amount, or requires an approval gate above the threshold → keep the prompt rule as defense-in-depth UX, but the gate is the boundary → this mirrors authorization in the data layer — never in a comment asking the query to behave.
What goes into an agent's ROI calculation, and what's the most common trap?
Hit these points: ROI = value returned vs all-in cost → all-in cost = tokens + tool calls + human-review time + failure/cleanup cost, not just the model bill → the trap: 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 coupled to gate design: more gates means more safety but lower ROI → it's the build-or-kill test — if deflected work doesn't clear all-in cost, don't ship it.
Your agent occasionally loops for dozens of steps, burning budget without resolving. Which template parts failed?
Hit these points: the symptom is a runaway loop, so the primary gap is part 5 (runtime) — no step cap, no cost cap → add a hard step limit and a per-session cost ceiling so it terminates and escalates instead of spinning → it's also an eval gap (part 6): no resolution metric means you didn't catch it → possibly a context gap (part 3): if the right info never lands in the window, the model keeps retrying → fix the runtime to stop the bleeding, then instrument eval, then check whether retrieval feeds the loop what it needs.
Why is the tool surface the hinge that everything downstream turns on?
Hit these points: the surface is the agent's reach — it defines what the agent can do, so it defines what can go wrong → a read-only surface has near-zero blast radius: no gates, light security, easy ROI → add one irreversible write and you now need a gate on it (part 8), a tighter security review (part 7: can injected input trigger it?), an eval that checks it fires correctly (part 6), and higher all-in cost from review (part 9) → so parts 6–9 are all functions of part 2 → keep the surface as small as the job allows, because every tool cascades cost and risk through the rest of the template.
You're standing up agents for five business domains at once. How do you avoid five bespoke designs?
Hit these points: the whole point of a template is that the method is shared and only the instantiation varies → standardize the commodity layer once: one runtime (loop, retries, limits), one tool protocol (e.g. MCP), one eval harness, one gate mechanism — buy or build it a single time → per domain, fill in only parts 1, 2, 8, 9: the boundary, the tool surface, where gates fire, and the ROI test — the parts that encode that domain's rules → this gives you consistent security and observability across all five and lets one platform team own the plumbing while domain teams own the glue → the failure mode to avoid is five teams each rebuilding a loop and a gate — that's where bespoke creeps in and security drifts.
Two proposed agents are identical except one has a read-only surface and the other can also write. Compare the full design implications.
Hit these points: the surface difference cascades through every later part → read-only: near-zero blast radius — no approval gates, security is mostly "don't leak data," eval checks answer quality, ROI is clean because there's no cleanup cost → the writer: every write is an irreversible action — now you need a gate sized to its blast radius (part 8), a security review for whether injected input can trigger it (part 7), an eval that the write fires correctly and only when intended (part 6), and a higher all-in cost from human review (part 9) → the design lesson: capability is not free — the moment you cross from read to write you've signed up for the gate, the review, and the cleanup-cost line in the ROI → so justify each write against the deflection it buys, and gate it.
How does this track build on AI Agents and Context Engineering, and what's genuinely new here?
Hit these points: AI Agents taught the primitives — LLM, tool, agent loop, runtime, memory, MCP — and introduced business-agent archetypes → Context Engineering taught how to curate the window — retrieval, assembly, caching, ordering, security → this track turns those into a design discipline: a repeatable template you instantiate per domain → parts 3–4 (context, memory) lean on Context Engineering; parts 2, 5 (tools, runtime) lean on AI Agents → genuinely new here is the boundary, the approval gates, and the ROI/build-vs-buy test — the parts specific to a business domain that no general track can hand you.
Design-round framework — narrate a domain agent in template order so the interviewer hears boundary-first, risk-aware, value-last:
  1. Clarify scope: what domain, what's the goal, what's the cost of a wrong action vs a wrong answer, who owns it?
  2. Part 1 — responsibilities: state what it owns, what it defers/escalates, what it refuses. This is the contract.
  3. Part 2 — tools: the smallest surface that covers the boundary; flag each tool's blast radius as you list it.
  4. Parts 3–5 — context, memory, runtime: what's in the window, what persists, the loop + limits.
  5. Part 6 — evaluation: the metric that matches the job (deflection, resolution, escalation correctness).
  6. Part 7 — security: untrusted input, least privilege, map to the OWASP failure modes.
  7. Part 8 — approval gates: gate by blast radius — auto-allow reads, cap cheap writes, pause irreversible/fan-out.
  8. Part 9 — ROI / build-vs-buy: all-in cost vs deflected work; buy plumbing, build glue; ship-or-kill.
Design a Support agent end to end using the 9-part template. Where do the gates go and why?
A strong answer covers: responsibilities — answer account/order questions, draft replies, issue small refunds; refuse legal/medical advice and anything outside support → tools — read order, read account, search KB, issue refund, escalate; smallest set that covers the job → context — the question + retrieved KB + the order record, scoped to the customer; memory — prior tickets retrieved, not dumped → runtime — bounded loop with retries and a step/cost limit → evaluation — deflection, resolution quality, escalation correctness on a labelled set → security — ticket text and KB are untrusted, scope retrieval by customer, least-privilege tools → gates — reads auto-allow (zero blast); refund above a cap and escalate-to-billing pause for a human (high blast) → ROI — deflected agent-hours vs tokens + review time; if every refund needs review the gate eats the savings, so set the auto-approve cap where the blast radius is acceptable.
Design an SRE incident-triage agent. Contrast its gates and ROI with the Support agent's.
A strong answer covers: responsibilities — read alerts/logs/metrics, correlate, summarize, propose remediations; refuse to apply changes it can't reason about → tools — query metrics, read logs, read deploy history, (gated) restart service, (gated) roll back; the writes are the high-blast ones → context/memory — the firing alert + recent deploys + prior similar incidents retrieved → runtime — bounded loop, step/cost cap → evaluation — time-to-correct-diagnosis and false-remediation rate, not just deflection → security — treat log/alert content as untrusted (it can carry injected text), least-privilege infra tools → gates vs Support — SRE's blast radius is far higher: a wrong restart or rollback can take down prod, so far more should be propose-only with a human gate; the Support agent can safely auto-resolve most tickets, the SRE agent should mostly recommend → ROI — the value is faster MTTR and analyst time saved, but if every remediation is gated the deflection is in the diagnosis, not the action — which is fine, because the cleanup cost of an unsupervised bad remediation dwarfs the saving.
Sources
Anthropic, "Building effective agents" — anthropic.com/research/building-effective-agents. Workflow vs agent; start with the simplest thing; agents trade latency/cost for autonomy. The spine for whether to build an agent at all.
Anthropic, "Effective context engineering for AI agents" — anthropic.com/engineering. Context as a finite, curated resource; the layer parts 3–4 of the template depend on. Cross-links to the Engineering Vault Context Engineering track.
Anthropic, "Writing effective tools for AI agents" — anthropic.com/engineering. Tool surface design — how many tools, naming, error shapes; the basis for the "smallest surface that fits the boundary" rule. Smallest-surface framing is editorial.
Yao et al., 2022, "ReAct: Synergizing Reasoning and Acting in Language Models" — arXiv:2210.03629 (ICLR 2023). The reason-then-act loop underneath every domain agent; grounding actions in observations is what makes it more than a chatbot.
OWASP, "Top 10 for LLM Applications" — owasp.org. Excessive agency, prompt injection, and insecure tool/plugin use — the failure modes a domain agent's boundary and approval gates must contain.
Was this lesson helpful? Thanks — noted.

These notes reflect my current understanding and are updated as I learn, build, and discover better explanations.