Platforms for many agents

When a platform starts to matter

The first agent rarely needs a platform. It can call a model directly, connect to two or three systems and log to a simple store. The second and third can follow the same pattern.

Around the fourth or fifth agent, the pattern starts to cost. Each team has built its own connection to the ERP. Each agent logs differently. Nobody can say what the company spent on models last month. A model change means touching every agent. At that point, a shared platform pays for itself.

The volume is coming. Gartner expects a third of enterprise software applications to include agentic AI by 2028, up from under 1% in 2024, and at least 15% of day-to-day work decisions to be made autonomously by then. Companies that run dozens of agents will need one way to run them.

Chapter 1 warned against starting with the platform. This chapter is about the right time to build one: after a few agents have proven their value and their needs are known.

What a platform provides

A platform for agents is a set of shared services. Each agent uses them, so each team can focus on its own process.

A company does not need all of these on day one. Model access, tracing, cost tracking and the register usually come first, because they solve the problems that appear soonest.

Model independence

Models change every few months, in quality, price and terms. A platform protects the company from that churn with one rule: no agent calls a model provider directly.

Twistag learned the value of this on its own product. Refraction, an AI code generation tool Twistag built in 2022, routed each request to the model judged best for the language, framework and task. When providers had outages, changed prices or released better models, the routing layer handled it as routine. Refraction served more than 20,000 engineers across 56 programming languages.

The same design shows up across client work. The European RegTech platform from Chapter 4 swapped model providers twice during the engagement without changing the product. The AI radio station from Chapter 7 replaced one provider mid-campaign without users noticing.

Open standards

Two open standards now shape how agents connect.

• Model Context Protocol (MCP) gives agents a common way to connect to tools, systems and data. It was created by Anthropic in 2024 and donated in December 2025 to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft and AWS. By then there were more than 10,000 active public MCP servers, and it had been adopted by ChatGPT, Gemini, Microsoft Copilot and leading developer tools.
• Agent2Agent (A2A), created by Google, gives agents from different vendors a common way to talk to each other. It moved to the Linux Foundation in 2025.

For a company, the practical point is simple. A connection to the ERP or the document store, built once on an open standard, can be used by many agents and by tools from many vendors. Ask every vendor and partner how their agents support these standards.

Build, buy or assemble

As with agents themselves, the platform can be bought, built or assembled from parts.

• Cloud platforms. The major cloud providers each offer services for building and running agents, with model access, guardrails and monitoring. They suit companies already committed to that cloud.
• Specialist tools. Open-source and commercial tools cover single parts well, such as tracing and evaluation, review and labelling, or search over documents. In client work, Twistag has used tools like LangFuse for tracing every model call and Argilla for structured human review.
• Custom layers. A thin internal layer for model access, cost tracking and the register, on top of bought or open-source parts.

Most mid-market and enterprise companies do best with the third option: a thin internal layer they own, assembled from parts they can replace. The rules from Chapter 5 still apply. Own the data, the prompts, the test cases and the right to switch.

Who owns the platform

The platform belongs to the small central team from Chapter 2. That team:

• runs the shared services and keeps them current;
• sets the standards every agent follows;
• keeps the register and reports cost by agent;
• helps business teams build their next agent faster.

It should act as an internal service, judged by how fast teams can build safe agents on it. When the central team becomes a queue that every agent waits in, the platform has become a brake.

Common mistakes

• Platform first. A large platform built before any agent has proven value, with no users when it launches.
• Every team for itself. Five teams, five ways of calling models, and no total view of cost or risk.
• One provider everywhere. Every agent tied to a single model provider, with no way to switch.
• Ignoring standards. Custom connections for each tool, rebuilt for each new vendor.
• A central team as gatekeeper. Every agent waits months for platform approval, and teams find ways around it.

What to do this month

1. Count the agents running every day, and list the tools and providers each one uses.
2. Put a model access layer in place, with cost tracking by agent.
3. Choose one connection that several agents need, and build it once, on an open standard.
4. Give the central team a clear remit: the shared services, the standards and the register.

Questions for the leadership team

1. How many agents run every day across the company, and on how many different tools and providers?
2. Could the company report the total cost of AI models last month, by agent?
3. How long would it take to move every agent to a different model provider?
4. Which connections to company systems have been built more than once by different teams?
5. Who owns the shared platform, and how do teams ask for what they need?