A prototype agent and a production agent differ in almost nothing except the boring parts: limits, traces, timeouts, retries, and a way to change things without breaking them. The one number that governs everything else is steps per task — it drives latency, and because the whole transcript is re-sent on every step, it drives cost faster than linearly. Reduce steps and most of your operational problems shrink at once.

The prompt is not a limit. "Do not use more than ten steps" is a request the model will sometimes honour. The loop counter in your code is a limit. Anything you would be unhappy to see exceeded belongs in the harness, where the model has no vote.

Whatever you choose, the cap must be visible in your metrics. An agent that silently truncates at twenty steps and returns something plausible looks healthy right up until someone reads the output carefully. This is the loop rate from Evaluating Agents; it should be close to zero, and a rise in it is one of the earliest signals that something upstream has broken.

Log the arguments, and scrub them. Traces are stored, exported, and read by more people than you expect. Redact credentials and personal data at the point of writing, not in a later cleanup job that will not happen.

Alert on rate of change, not only on thresholds. A tool that has started failing intermittently shows up first as a slow rise in average steps per task, because the agent retries and works around it, long before it shows up as a visible error.

Retries and idempotency are the same subject. An agent retries on its own initiative, in addition to whatever your infrastructure does. A send or a payment that timed out after succeeding looks like a failure to the agent, which will reasonably try again. Idempotency keys on every write are the only reliable protection, because the caller genuinely cannot tell a lost response from a failed action.

Step count dominates everything. Shaving 200 ms off a tool call saves you about a second across a whole task. Removing four unnecessary steps saves twelve. Before optimising any individual call, look at why the agent needed that many steps — usually a vague goal, a missing tool, or a tool that returns too little per call.

Cost grows faster than step count. Each extra step costs more than the one before it, because it carries everything that came before. A run that takes twice as many steps typically costs three to four times as much. This is the single strongest argument for keeping runs short.

Track cost per completed task, not per model call. Per-call cost looks fine while an agent takes fifteen steps to do a two-step job. Per-task cost against a success rate is the number that tells you whether the system is worth running.

Change one thing at a time. With a non-deterministic system and a noisy metric, two simultaneous changes cannot be untangled afterwards. You will know the result moved and never know which edit moved it.

A handoff that arrives with a clear summary and the full trace is worth far more than one that says "the assistant could not help". The agent has usually already done half the investigation — losing it is pure waste, and it is the difference between an agent that reduces human workload and one that adds a step to it.