Article
A platform is not one agent with a bigger budget. It is infrastructure that lets many agents, tools, and tenants share a foundation without stepping on each other, and it is a different design problem from shipping a single agent. Most of the teams we meet who are struggling with "the agent" are actually missing the platform underneath it, and no amount of prompt work fixes that.
Separate the model from everything around it
The layer that talks to a model provider should be the thinnest layer in the system, and it should be the only one that knows which provider it is. Everything else, the tool registry, the permission checks, the conversation state, the logging, sits above it and does not change when you swap GPT for Claude for a fine-tuned open-weight model. Platforms that skip this separation end up rewriting the harness every time a better model ships, which in this market is often.
A tool registry, not scattered API calls
Every tool an agent can call belongs in one registry: its schema, its permission level, its rate limit, its owner. An agent requests a tool by name; the platform decides whether this tenant, this user, and this conversation are allowed to use it right now. This is what makes the difference between "the agent has a bug" and "the agent did something it was never authorized to do" — the second should be structurally impossible, not a hope encoded in a prompt.
Tenant isolation, decided early
If more than one customer will use the platform, isolation is an architectural decision, not a filter added later. Data, conversation history, and tool credentials need a boundary that a bug in the agent logic cannot cross — row-level security in the database, not just a WHERE tenant_id = ? that a future query might forget. We treat this the same way we treat multi-tenant cost isolation: decided once, at the schema, rather than audited forever at the query.
State that survives a restart
An agent mid-task is not a stateless request; it has a plan, a set of completed steps, and a reason it is waiting. That state belongs in a database, not in a process's memory, so a deployment or a crash resumes the task instead of losing it. This is the single biggest difference between a demo agent and a production one: the demo can restart from zero, and the production one cannot.
Observability across every agent, not per agent
A platform with ten agents and ten separate logging setups cannot answer "which agent is expensive" or "which tool is failing most" without ten separate queries. One event schema, one place every step lands: which agent, which tool, which tenant, cost, latency, outcome. This is what makes the routing and cost work possible at platform scale instead of one agent at a time, and it is the same discipline behind LLM observability generally, applied per agent.
The build order that avoids rework
Tool registry and permissions first, because everything else depends on them existing. State and resumability second, before more than one agent is live, because retrofitting durability into running agents is painful. Observability third, so the fourth phase — actually adding agents — produces data from day one instead of guesswork. Framework choice, the part everyone wants to discuss first, is a decision made against this foundation, not before it; a comparison of the current options matters far less than whether the platform underneath can outlive whichever one you pick. At enterprise scale this foundation also has to answer governance and compliance questions a single-agent build never faces. Our AI Agents service covers this end to end.