The agent stack: a map for platform teams

Every AI agent operates on a stack. Most of the conversation about that stack focuses on the model and the orchestration layer. This piece focuses on the tools layer: what it is, what it has to do to work reliably in production, and what happens when it's missing or underbuilt.

This is a reference piece. The audience is engineering and product leaders making architecture decisions about how their agents will interact with the products they're building on.

The four layers

An AI agent has four core components. Understanding how they relate is necessary for understanding where the tools layer fits.

Model — the reasoning engine. The model takes in a task description, available tools, memory context, and the results of previous actions. It decides what to do next. The model doesn't act directly; it selects the next action.

Orchestration — the loop manager. The orchestration layer runs the cycle: give the model context, receive a decision, execute the decision, feed results back to the model, repeat until the task is complete or the agent determines it can't complete it. Orchestration also handles multi-step planning, memory integration, and tool selection interfaces. This is where frameworks like LangChain/LangGraph, the OpenAI Agents SDK, and similar tools operate.

Tools — the action layer. Tools are what the agent actually does. When the model decides "call this tool with these parameters," the tools layer handles the invocation. Tools are typed: they have defined input schemas, defined output schemas, and defined behaviour. The agent's ability to act on any given product is entirely determined by the tools that are available to it.

Memory — the context layer. Memory provides the agent with information about the current session, the user's state, previous actions taken, and any long-term context relevant to the task. Memory is what allows an agent to maintain coherent behaviour across a multi-turn interaction.

What the tools layer has to do

The tools layer is deceptively complex. It looks simple from the outside — the model calls a tool, the tool does something, the result comes back. The operational requirements underneath that simplicity are significant.

Coverage. The tool definitions have to reflect what the product can actually do. This is the most common failure point. Tools built from a public API spec often cover a fraction of the product's real capabilities — the fraction that was designed for external consumption. Capabilities that live in controller logic, UI workflows, or internal APIs are invisible to tool definitions built from the spec alone. Coverage means building tools from the codebase, not just the spec.

Schema precision. Tool definitions need typed, precise input and output schemas. Imprecise schemas produce two failure modes: the model makes calls with inputs the tool doesn't handle correctly (leading to errors or silent wrong results), or the model misunderstands what a tool does and selects the wrong one. Schema precision is the interface between the model's reasoning and the tool's execution — quality at this interface determines how well the agent performs.

Determinism. The same tool called with the same inputs should produce the same result. Agents depend on this to reason correctly about what to do next. Non-deterministic tool behaviour makes it impossible for the model to plan reliably.

Auth at the user level. Every tool call should execute with the permissions of the authenticated user, not a shared service account. Service account execution collapses the permission model: the agent can do things the user isn't allowed to do, and the audit trail doesn't reflect who actually initiated the action. User-scoped execution is the correct architecture.

Reliability handling. Retries, timeouts, and error propagation need to be handled at the tools layer, not delegated to the agent or to the product's underlying APIs. An agent that has to reason about whether to retry a tool call because the runtime timed out is a less capable agent than one where the runtime handles that transparently.

Freshness. Tool definitions go stale when the underlying product changes. An API field renamed, a workflow updated, an endpoint deprecated — each of these can produce tool invocations that fail or produce wrong results. Tools definitions need a maintenance mechanism that keeps them current with the product, ideally aligned with the product's own change cycle.

What happens when the tools layer is underbuilt

Underbuilt tools layers produce a characteristic set of failure modes that are often misdiagnosed.

Coverage failures present as the agent being unable to complete tasks that seem straightforward. The diagnosis is usually "the agent needs better reasoning" or "the prompts need improvement." The real problem is that the capability isn't in the tools.

Schema failures present as the agent making tool calls with wrong parameters, or selecting the wrong tool for a task. The diagnosis is often a model problem. The real problem is that the tool definitions don't give the model enough information to select and invoke correctly.

Auth failures present as permission errors in production that didn't appear in testing. Testing often uses a service account with broad permissions; production uses real user identities with scoped permissions. The failure appears at launch.

Drift failures present as agent tasks that worked last month failing today. The diagnosis is usually an investigation into what changed in the agent or the model. The real problem is that the underlying product changed and the tool definitions didn't update.

Protocol considerations

The tools layer doesn't dictate which protocol agents use to discover and invoke tools. MCP (Model Context Protocol) has emerged as the de facto standard for agent-to-tool integration; other formats remain in use (OpenAI tool/function definitions, custom schemas). Adjacent protocols like A2A address agent-to-agent communication rather than tool invocation, and are complementary to MCP rather than alternatives to it. The right architecture for the tools layer is protocol-agnostic: the tool definitions and execution runtime should be able to surface tools in whatever format the agent framework requires, rather than being locked to a specific protocol that may not be the standard in two years.

Protocol is an implementation detail. The structural requirements of the tools layer — coverage, precision, determinism, user-scoped auth, reliability, freshness — are constant regardless of which protocol surfaces them to the agent.

Building vs. buying the tools layer

For engineering leaders deciding how to approach the tools layer, the core question is whether to build it as part of the agent project or treat it as infrastructure.

Building it as part of the agent project means writing tool definitions manually, handling auth and reliability per tool, and owning the maintenance as the underlying product changes. This works for a small number of tools against a stable, well-documented API. It doesn't scale to a portfolio of products with active development.

Treating it as infrastructure means either building a generation and runtime platform internally (a multi-year investment) or using an external platform designed for this purpose. The infrastructure question is the same as any infrastructure question: build vs. buy is a function of how central the capability is to your differentiation, how complex the build is, and what it would cost to own long-term.

The tools layer is not where most agent teams want to spend their engineering capacity. It's the necessary foundation — the thing that has to be right before the work that actually matters can happen.