There is a pattern I see over and over. A business gets an AI agent demoed, it works beautifully for three people on a quiet Tuesday, they sign off, it goes live, and the first busy Monday it falls over. A model provider rate-limits it. An update breaks a permission rule. Someone asks the agent to do something irreversible and there is no undo. Demos are easy because nothing is at stake. Architecture is what decides whether the agent survives the days with stakes.
I have been building my own assistant, Seepient, for long enough to hit every one of those failures. This post is the architecture that came out of it, the same structure I recommend when an agent has to handle real business work at real volume. I already wrote about the six layers that keep the codebase clean; this one is about the pieces that keep the business running.
The four guarantees, before any features
When I design an agent system, I insist on four guarantees. Features can be added later. Missing guarantees mean the agent cannot be trusted with anything important, ever.
- Nothing irreversible happens without a person. The agent can draft, prepare, and stage all day long. Sending money, deleting records, emailing a customer, those wait for a human yes. And the approval has to survive a crash: if the system restarts mid-approval, the pending decision is still there on one screen, not lost in the void.
- One failed provider cannot stop the work. Models are rented, not owned, and their APIs change, retire, and throttle without warning. So the agent treats the model supply like a business treats a single supplier: with backups. When a provider fails, work routes to the next one automatically, with rest periods so a broken provider never gets hammered in a loop.
- Every action is on the record. What the agent did, when, why, and who approved it. Not for compliance theater: when something goes wrong at 11pm, you can reconstruct what happened in minutes instead of days.
- The model is swappable. The architecture must allow you to switch from one provider to another, or to a model you host yourself, without touching business rules. Vendor lock-in in an AI agent is not an inconvenience; it is a hostage situation.
The underlying AI model is not the architecture. It is one swappable component inside an architecture you own.
The shape of the system
Here is how those guarantees map to structure. In plain terms, the agent is separated so that each concern can change without dragging the others with it:
- One front door. Whatever way work arrives, whether a web dashboard, chat, or an API call from your other systems, the same rules apply. I made all entrances share one brain because duplicated policy is how exceptions sneak in.
- Rules live in one place. Permission boundaries only ever narrow what the agent can do, and they are checked the same way no matter who is asking. A tool cannot quietly grant itself more access.
- Tools run in a confined space. File and system actions happen inside a sandbox boundary, a playpen where the agent can experiment freely, and damage cannot reach anything outside it.
- Providers sit behind a wall. Each AI provider lives in its own isolated wrapper. If your provider changes pricing or retires a model, one wrapper is updated and nothing else moves.
Where it nearly broke
The design earned its shape through failures, and it is worth naming two. Early on, I wired approval requests to live only in memory while the process was running, so a crash mid-review made the request evaporate, along with the work it was guarding. That is when I learned approvals need their own journal on disk, written before anything executes. The second one: three different interfaces each had a slightly different idea of the rules. A request that was blocked in the dashboard sailed through the command line. Rebuilding around a single rule engine felt slow for a week and then prevented exactly that class of bug forever.
The lesson underneath both: architecture problems do not announce themselves as architecture problems. They show up as weird one-off incidents until you trace them back to a missing boundary.
What this means if you are buying, not building
You do not need to read a line of code to use this checklist. Before you sign with anyone building you an agent, including me, ask:
- What happens when the model provider goes down mid-task?
- Can I see a complete record of what the agent did last week?
- If we part ways, do I keep the system, and can it run on a different AI model?
- What must a human approve, and does that approval survive a restart?
Good answers exist and they are not exotic. They are just the difference between an agent that impresses and an agent your business can lean on. If you want an agent built on this foundation, book a call and I will walk you through it in business terms, not diagrams.
