An Agentic Platform (AxP) is the digital environment an enterprise builds so that AI agents can work safely across every vertical team. Agentic platforms are built as products by the AI platform team in collaboration with the respective business units. They share a common foundation: the agent infrastructure. The tooling and paths built on top of this infrastructure differ by vertical and turn the platform into, for instance, an Agentic Engineering Platform, an Agentic Sales Platform, or an Agentic Finance Platform.
Figure 1: Reference architecture of an Agentic Platform showing its three layers: tooling, path specs, and agent infrastructure.
Agentic Platforms have three layers. At the top sits the tooling: the software and data stores the business units need to get their work done. Next come the path specifications, comprising agent paths (specs that agents follow) and deterministic paths (pipelines). Think of them as the map through the platform. The base layer is the agent infrastructure which, as the name suggests, is the infrastructure the agents run on.
Figure 2: An Agentic Platform can be accessed through several interfaces, depending on which best suits the end user's workflow.
Agentic Platforms are consumed through whichever interface the work arrives on. That might be a chatbot, a user interface, a schedule, or a signal-based trigger via API or MCP.
An Agentic Platform is more than a chatbot, a model, or a workflow engine, although it can include all of these as components. In this article, we explore why agents need an Agentic Platform and what each layer does. We also look at how a path runs on it and how it adapts to different verticals, before discussing how to start building one.
Why agents need a platform
Handing out licenses for frontier models is not a strategy. For agents to work autonomously and actually yield productivity gains, they need to be managed in an environment optimized for them. We explored this in a recent article using the analogy of an intern you hire and never onboard. You wouldn't be surprised if they hallucinated and were unproductive. Instead, you'd give them a handbook, a badge, a toolkit, and a reviewer on day one. The same goes for agents. An environment is ready for agents when it is legible (context is documented and machine-readable), known (every agent has an identity, a scope, and a budget), capable (tools are exposed through interfaces agents can call), and checked (output is evaluated against a definition of done, and failures loop back). These requirements form the specification. An Agentic Platform meets them, once, across every vertical, rather than leaving individual teams to meet them independently.
The unit of work is the agent path, not the agent
From a technical perspective, there’s no such thing as an agent, at least not beyond the few seconds or minutes a request is running. An agent is a run: specified beforehand and alive during execution, then accounted for afterward. Like a mayfly, it's short-lived. What actually persists is the path.
Figure 3: An agent typically exists for only seconds or minutes. The stable, maintainable unit is the agent path.
A path is a repeatable route from intent to usable output. An agent path is one whose steps are performed, in whole or in part, by an agent on shared agent infrastructure. Paths have inputs, capabilities, and outputs that can be checked against policies. Each has an owner and a lifecycle, along with a definition of done. Every time a path is walked, it leaves a run behind. The Agentic Platform holds the paths and produces the runs. We discuss this in more detail in the article Why agents are mayflies.
Figure 4: An agent path for a marketing team that creates a campaign briefing. Input arrives through several interfaces. Capabilities operate in the background, and the output is a structured briefing. The path runs on an Agentic Platform.
What each layer does
As you recall, an Agentic Platform has three layers: Tooling, Path Specs, and Agent Infrastructure. Let’s go through them in detail.
Tooling: Where the work happens
The tooling belongs to each vertical: a CRM in sales, a Git repository in software engineering, an ERP in finance, or a CMS in marketing. Rather than replacing these tools, the platform makes them accessible to agents through interfaces they can call. Each interface has a contract defining its inputs and outputs, and is registered so that paths can discover it. Business units already own and understand this layer, so they retain ownership. The AI platform team's role is to enable discoverability and access, not replace existing tools.
Figure 5: The tooling layer of an Agentic Engineering Platform showing the tools needed to manage software.
Path specs: The map
Agent paths and pipelines are documented so that systems, not just people, can navigate the platform. A path spec defines the intent and which capabilities it uses. It also defines what done looks like, which gate decides it, and whether the route is deterministic, probabilistic, or a loop between the two. Specs are authored in the verticals, where teams understand what a valuable outcome looks like, then reviewed and promoted by the platform's enablement function. This layer makes the enterprise's tribal knowledge executable, turning knowledge most organizations have never formally documented into defined paths.
Agent infrastructure: The engine room
This is where most of the engineering lives, and it comprises three distinct areas.
Figure 6: The agent infrastructure, the shared foundation of an Agentic Platform comprising the harness, governance layer and model layer.
The harness is the operating system around an individual agent.
Execution: Orchestration, the gateway and model routing, the runtime and its sandbox.
Context: The service graph and ontology, retrieval, memory and state, so the agent knows what the organization knows.
Capability: Tool gateways, contracts, and registries, allowing the agent to access the tooling layer in a controlled way.
Evaluation: Evals, goldens and rubrics, replay, and the change-safety gates a path must pass before anything ships.
The harness is what makes the environment legible, capable, and checked.
Governance serves all agents at once. Identity gives every agent a workload identity, along with its secrets and budget. Agent security centralizes output guardrails, compliance checks, and data-loss prevention. Agent observability provides the traces and audit trail with the cost attribution needed to determine which agent did what and what it cost. Governance is built once for the entire fleet rather than separately for each agent, because managing governance agent by agent produces an estate nobody can audit. This layer is the one that makes agents known.
Models encompass the provider portfolio and inference endpoints, including self-hosting where sovereignty or operational requirements demand it. It’s tempting to treat this as a procurement exercise, but leaving it unowned means every team ends up managing model routing and rate limits independently, along with tracking costs.
Every component of the infrastructure answers one of three questions: How does an agent do the work? Who is allowed to do what? What intelligence is being consumed?
How a path runs on the platform
When something needs to be done, it's invoked through an interface. That could be a UI, chatbot, API call, MCP server, or an automated trigger. The interface doesn't matter. An agent path is invoked, which means the agent infrastructure reads its specification and starts executing it step by step. A sandbox is spun up. Identity is bound, context and capabilities are loaded. Then the probabilistic reasoning happens.
Paths fall into three categories. Deterministic paths are pipelines: the same input produces the same output, and they predate agents entirely. Probabilistic paths are agent-driven (which is why we call them agent paths): the model does the work, and evals and humans verify the results.
Hybrid paths combine the two in a loop. A probabilistic step produces a candidate, a deterministic gate evaluates it, and the loop continues until the gate passes or the budget is spent. Most of what runs on Agentic Platforms will be hybrid, because this loop is where autonomy and safety stop being a trade-off.
Figure 7: The hybrid loop. Output is rejected by the quality gate until it meets the required criteria.
One platform, many verticals
The first part of your organization to go furthest with AI will most likely be engineering. But software developers using AI to write code don’t make you an agentic enterprise.
The development vertical's instance is the Agentic Engineering Platform, which is what the Internal Developer Platform (IDP) becomes when agents are among its users. Sales, marketing, finance, and clinical teams use the same stack with different tooling and different paths built on top. The underlying agent infrastructure remains the same.
That consistency lets one platform serve the enterprise, not just the engineering department. It’s also why the agent infrastructure has one owner, while the paths have many.
Paths feed into other paths. A trends path ranks what the market is talking about and a planning path turns that into an agenda. A publishing path then turns the agenda into posts scheduled for Monday at 09:30.
Several paths queued alongside a value stream toward a business outcome form the Paths to Outcome model, described in our book Thinking in Platforms. An agentic platform is what it looks like when agents are the ones walking it.
Figure 8: The Paths to Outcome model for a content value stream, designed with an agent-first approach.
Who builds it
The agent infrastructure has one owner: the AI platform team, which builds and runs it as a product. The team includes a head of AI platform and a product manager, supported by specialists in the different capabilities of the agent infrastructure layer. An enablement function bridges the AI platform team and the business units.
The tooling and the paths have multiple owners: the verticals, which understand their own workflows. The rule that separates these responsibilities is simple. Path authorship is federated to the verticals, while identity, budgets, evaluation, and audit remain centralized. We describe the team and its functions along with its reporting lines What is an AI platform team.
How the platform grows
An agentic platform isn’tbuilt for full autonomy on day one. In The four levels of agentic development, we describe how far an organization allows agents to go, measured by how much work humans still do. This ranges from agents assisting while humans execute to agents initiating work on their own within guardrails. The platform must grow with that autonomy, and each level asks something new of it.
At Level 1, agents assist while humans execute. The platform needs a gateway and context along with an initial set of pipelines.
At Level 2, agents generate work for humans to approve.; The platform adds the Dispatch Work to Agents path and workload identity. It also adds a review queue where agent output awaits human approval.
At Level 3, agents execute long-running paths in the background while humans orchestrate. Evaluation and the hybrid loop become the center of gravity, and governance must hold without a person in every loop.
At Level 4, agents initiate paths within guardrails, and the platform treats them as a class of user alongside humans.
The order matters. Organizations that attempt Level 3 on a Level 1 substrate risk having their agents running faster than their guardrails.
How to start
Follow the pattern a decade of platform engineering has already tested. Treat the platform as a product with users, rather than a project with an end date.
Start with a Minimum Viable Platform (MVP), make the gateway your first priority. That's where the pain arrives first, particularly around spend and provider access, and where one central piece of infrastructure pays off fastest. Build in identity and budgets from the start, along with evaluation, because these are far harder to retrofit later.
Bring one vertical's paths onto the platform before you bring ten, and let that vertical author them. Then expand function by function, path by path. An organization doesn'tbecome agentic on a Tuesday. It progresses, one path at a time, with the Agentic Platform making each subsequent each next path cheaper than the last.
