How we structure AI agent architectures for production

A demo agent and a production agent share almost no architecture. A demo needs to look impressive once. A production agent needs to be safe on its worst day, observable when it misbehaves, and cheap enough to run thousands of times an hour. Those are different problems.

Separate planning from acting

We keep the model that decides what to do distinct from the code that actually does it. The model proposes a tool call; a deterministic executor validates the arguments, enforces permissions, and runs it. The model never touches a database or an API directly — it only ever emits a structured intent that our code chooses to honour or reject.

Make every tool call a typed contract

Each tool has a schema, and we validate the model output against that schema before anything runs. An invalid call is rejected and fed back to the model as an error it can recover from, rather than crashing the run. This single discipline removes a whole class of "the model hallucinated a parameter" failures.

Budget, log, and replay

Every run carries a token and tool-call budget; when it is exhausted, the run stops rather than looping forever. We log every prompt, every tool call, and every result, so a misbehaving run can be replayed exactly. In production, the ability to replay a failure is worth more than any amount of clever prompting.

None of this is exotic. It is the same engineering rigour we would apply to any system that spends money or changes state — applied to a component that happens to be a language model.