The most expensive mistakes in agent projects happen before any code is written.
First: does this need an agent?
Be genuinely willing to answer no.
Build a workflow when you can draw the flowchart. Fixed steps, known order, conditions you can enumerate. Cheaper, faster, testable, and it does not surprise you at 3am.
Build an agent when the steps genuinely cannot be known in advance — when how many searches are needed depends on what the first one returns, when the path branches on content rather than on rules you could write down.
The common middle, and usually the right answer: a workflow with model decisions inside it. Deterministic structure, judgement at the two or three points that need it. Most successful production systems look like this, whatever they are called in the announcement.
Define done, precisely
Before anything else, write the success condition. Not "handles support tickets" — something checkable:
A ticket is resolved when it has been assigned a category from the fixed list, a response draft exists, and either the draft is approved or the ticket is escalated with a stated reason.
This does three jobs at once: it gives the agent a stopping condition, it gives you something to evaluate against, and it forces the scope conversation early rather than after two weeks of building.
Then define the boundaries
What must it never do? Write these as hard constraints in code, not as instructions in a prompt. "Never email outside the organisation" is a validation rule; a prompt asking nicely is not a control.
What needs approval? Decide now, not after the first incident.
What is the budget? Maximum iterations, maximum time, maximum spend per run. Every agent needs all three.
Choosing a shape
Single agent with tools. One loop, one model, a set of tools. Start here. It handles more than people expect and is far easier to debug than anything else.
Workflow with model steps. Deterministic pipeline, judgement injected. The most reliable production shape.
Multi-agent. Several specialised agents coordinating. Genuinely useful for a narrow set of problems and dramatically harder to debug — failures compound across agents, and reproducing a run becomes difficult. Do not start here. Reach for it only when you have a single agent working and a specific, articulated reason it cannot scale.
Design tools before prompts
The set of available actions determines what the agent can do far more than its instructions do. Decide the tools first, keep each one narrow, and you will find the instructions become much easier to write — because there are fewer wrong things available to do.