Trigger, Context, Model, Tools, Review

An agent is a system, not a prompt

The single biggest mistake engineers make is treating an agent as a clever prompt. In production it is a system with distinct parts, and each part fails differently. Draw all five before you write code, or you will patch the gaps under pressure later.

The five parts

• Trigger: the event that starts a run, such as a webhook, a queued job, a new ticket, or a schedule. The trigger defines how much you control input quality and how bursty your load is.
• Context gathering: the step that assembles the facts the model needs, from retrieval, database reads, and prior state. Most wrong answers trace back to missing or stale context, not the model.
• Model call: the reasoning step where the model decides what to do next given the context and the instructions. This is where you set the system prompt, the output schema, and the temperature.
• Tools and actions: the functions the agent can call to read or change the world. Each tool is an API boundary you must validate on both sides.
• Review and output: where a human or a rule inspects the result before anything irreversible happens, and where the final output is emitted.

Why the explicit map matters

When these parts are drawn out, you can reason about each one independently. You can say "context gathering is flaky because the CRM read times out" instead of blaming the model. You can decide the model call is deterministic enough to cache, or that the review step can be skipped only for a specific low-risk action. Without the map, every incident becomes a guessing game across an undifferentiated blob.

A worked example

Consider a support triage agent. The trigger is an inbound ticket. Context gathering pulls the customer record, the last five tickets, and the top three matching help articles. The model call classifies urgency and drafts a reply constrained to a JSON schema. The tools are read-only account lookup plus a draft-create action, with sending gated. Review is a human approving the draft. Each arrow between parts is a place a run can stall, so each gets a timeout and a defined fallback.

What good looks like

You can hand someone a one-page diagram showing the trigger, what context is gathered and from where, the model call and its output contract, every tool and whether it is read-only, gated, or automatic, and the review point. If any box is vague, that is where your first production incident will come from.

Common mistakes

• Collapsing context gathering into the prompt, so you cannot see or fix what the model actually read.
• Leaving tools undefined until late, then bolting on broad access that is hard to secure.
• Designing with no review box because the demo looked clean on tidy input.