Agentic architecture articles

An agent demo is easy and an agent in production is not, and the gap between them is almost never about the model. It is about the same engineering discipline any other system needs, applied to a component whose output is not deterministic.

Start with evaluation, before the prompt. You need to say what a good answer looks like on a set of real cases. Otherwise you cannot tell whether a change made the system better or simply different. Build the eval set from work people have already done, so there is a known-good answer to compare against. Sample it across a window long enough that seasonality does not flatter you.

Put that eval run in continuous integration. This is the single change that most often turns a prototype into something a team will let near a customer. It moves the question from an argument about vibes to a number that blocks a merge. A regression should fail the build, in the same job, with the same authority as a broken unit test.

Instrument every call. When an answer is wrong you want to see which retrieval returned which document and what the model was given, not reconstruct it from memory. Tracing turns a support escalation into a quick check instead of a day of guessing.

Set a cost ceiling per outcome and check it in the same job as the evals. A loop that retries three times on a bad tool response is fine in a demo and ruinous at volume. If you cannot state the cost of one completed task, you do not yet know whether the system makes sense.

Then design the boundary. Tool interfaces are where agents actually break. That is why an explicit protocol between the model and your systems is worth adopting, rather than one improvised inside a prompt. Keep the tools narrow, validate their inputs, and make every destructive action reversible.

Finally, keep a rollback path. A prompt is a deployment. Version it, ship it behind the same controls as code, and be able to put yesterday back quickly.