“We need an AI agent” is often the second sentence in a conversation whose first sentence is still missing. The first is what the team needs to get done, and what prevents it from happening reliably today.
Draw the workflow before choosing the architecture. Write down the input, the expected output, the rules, the exceptions, and the person responsible for each important decision. A simple sketch can reveal that the hardest part is a missing data contract or an unclear handoff.
Choose the smallest approach that fits
Anthropic’s engineering guidance distinguishes fixed workflows from agents that decide their own sequence of actions. It recommends starting with the simplest solution and adding complexity only where needed. More autonomy brings trade-offs in latency, cost, and the risk of errors compounding.
Our practical framework starts with three options:
| The work | A starting approach | Example |
|---|---|---|
| Known rules, structured inputs | Conventional automation | Route an enquiry according to its chosen service. |
| Unstructured input, fixed output | A model call inside a workflow | Extract defined fields from a document and validate them. |
| Several possible steps, with context determining the route | A bounded agent | Investigate an internal question through approved retrieval tools. |
Map the contract between steps
For each transition, define what information the next step can expect. Identify required fields, acceptable values, and the behavior when an input is missing. A model output should pass the same kind of check as any other external input.
- Input: Which event starts the process, and how do you identify it uniquely?
- Transformation: What is the minimum information the next step needs?
- Decision: Can a rule make it, or does it need interpretation?
- Action: What can change, and who has permission to change it?
- Recovery: How does the team see a failure and resume safely?
Make review points explicit
Writing a draft and sending it are different actions. Reading a record and changing it are different permissions. Separate those steps when the consequences warrant review.
A support workflow might prepare a response for a person to approve. A document pipeline might accept complete, validated records while sending exceptions to a queue. Define these boundaries in the workflow, not only in a prompt.
Use examples to decide whether it works
Collect a small set of representative inputs before the build. Include ordinary cases, missing information, ambiguous requests, and examples that should be rejected. Agree what a correct result looks like.
Measure both output quality and operational cost. A system that answers correctly but needs constant intervention may still be a poor fit. Keep a record of the exceptions and update the tests when the process changes.
Our Operations Audit produces this map and a scoped recommendation. For a system already running, the first-response playbook helps you diagnose the failure before changing the architecture. The care plan covers agreed maintenance after handover.
Primary source
Anthropic: Building effective agents, originally published 19 December 2024, read on 13 October 2026. Tooling has evolved since its original publication; this article uses its architectural distinction, rather than its older product examples. The checklist above is Qixazow’s implementation framework.