Agentic infrastructure: What sits behind the agent

Access, tools, process state and operations: the shared foundation AI agents need, and when building it makes economic sense.

Agentische Infrastruktur: Was hinter dem Agenten steckt

English edition — originally published in German as Agentische Infrastruktur: Was hinter dem Agenten steckt.

One agent prepares contract renewals. A second handles service requests. A third supports purchasing. All need customer data, documents, permissions and reliable connections to business systems. If each team builds these foundations separately, more agents also mean duplicated integrations, inconsistent rules and unclear responsibilities.

This is where agentic infrastructure becomes relevant. In this article, the term means the shared technical and organisational foundation that lets agents use information and act within defined limits. It includes more than models and computing capacity. Its value is that the next use case can build on capabilities that have already been tested.

:::takeaways{title="For implementation"}

:::

From one assistant to a shared foundation

Consider contract renewal as an illustrative process. The agent reads the current contract, checks outstanding work and prepares a proposal. A responsible person decides. The permitted changes are then recorded and the agreed next steps initiated.

For this process, the application needs to know who is asking, which contract is involved, what data they may see and which change has been approved. After an interruption, it must also know what has already happened. These responsibilities cannot reliably be delegated to a long prompt.

In our prototype work on a shared work surface, responsibility, sources and the next action appear together. Using demo data helps us examine the process. For production use, the infrastructure must enforce those rules against the connected systems too. A visible approval button alone does not do that.

Six capabilities that belong together

A modest architecture is enough to get started. What matters is that the required capabilities exist and each has an owner. They do not all need to be purchased as new products or developed as a separate platform.

| Capability | Its role in the contract example | |---|---| | Identity and permissions | Check the person, role and permitted contract data at each relevant access point. | | Context and sources | Bring together the contract, outstanding work and the currency of information with traceable sources. | | Tools and interfaces | Provide small, clearly defined functions for reading, preparing and changing records. | | Process and state | Persist the current step, approval and confirmed changes. | | Rules and control | Enforce limits on actions, amounts and data access outside the model. | | Testing and operations | Monitor and address quality, errors, costs and outstanding human tasks. |

Existing identity management, integration services and process systems may provide parts of this foundation. The first architecture decision is therefore what is already dependable and what is missing for this process. A new agent project is no reason to replace established foundations wholesale.

A tool needs a precise purpose

“Access to the contract system” is too broad. Bounded capabilities such as “read contract status”, “prepare a change” and “execute an approved change” are more useful. Each needs defined inputs, appropriate permissions, recognisable errors and an understandable result.

The MCP tools specification describes a common format for exposing and invoking tools. The MCP authorisation specification covers access authorisation for HTTP connections; authorisation is optional in the protocol overall. An available MCP connection therefore does not establish that business permissions have been implemented correctly.

For this process, we recommend that the executing service checks permissions and a valid approval itself. It should not rely solely on text supplied by the model. Content in an email or document must not grant additional rights either. This separation belongs in the implementation and in acceptance tests.

The process must survive a restart

A contract renewal may wait for clarification or span several days. Its current state therefore needs persistent storage. A chat history alone is insufficient as a work queue. At minimum, the application needs a case identifier, an accountable person, the pending decision and evidence of steps already completed.

After a restart, the application should resume from the actual processing state. A fresh model response must not accidentally trigger a change that has already been made. Our article “When is an AI task actually complete?” explains confirmed completion and uncertain outcomes.

Multiple agents are not a prerequisite. If separate agents later need to collaborate, A2A provides concepts for tasks, status and outputs. A communication protocol does not replace the business owner or the decision about when a business process counts as complete.

Operations begin with an accountable person

The business team needs someone responsible for outcome quality and exceptions. Integration needs a technical owner for interfaces and changes to them. Operations must detect and handle disruptions and be able to stop further actions when necessary. One person may hold several roles, but they must be explicitly assigned.

The operational view should include open cases, error rates, processing time, human rework and costs. A central tool service can affect several use cases at once, making monitoring, limiting the impact and a manual fallback more important. A global overview also does not replace access separation between teams.

Before changing a model, prompt or tool version, run the same set of representative cases again. Include denied access, conflicting sources, interrupted processing and approvals that have become invalid. Define the expected state in advance. A plausible response is not a sufficient acceptance criterion.

When shared infrastructure makes economic sense

Value comes from less duplicated work and consistent operations. A shared solution also creates work: support, version maintenance, testing and coordination. These costs must not disappear from the first project or be treated as zero in later projects.

:::callout{type="info"} Hypothetical planning example: Three teams each estimate ten development days to build the same integration, totalling 30 days. Assume a shared implementation takes 14 days, plus two days to connect each of the three use cases: 20 days overall. The difference is ten development days. Additional ongoing platform operations are not yet included. With just one use case, the shared approach would take 16 days instead of ten. This is a comparison of assumptions, not a measured project result. :::

The comparison is meaningful only if scope, quality and permission requirements are comparable. Three similarly named interfaces are not automatically the same capability. Verify genuine reuse before including the saving in a plan.

Prove the foundation through one process

Start with a bounded business case and an accountable business team. First clarify data sources, permitted actions and the fallback. Then connect a few tools, persist the process state and test both normal operation and deliberate disruptions. Use existing operational services wherever they meet the requirements.

A second concrete use case reveals which components can actually be shared. Move those into a maintained service with documented limits. Infrastructure then grows from demonstrated demand. The simple work surface of the AI cockpit gains a foundation that supports everyday operations.

Which recurring process could become your first dependable building block? We can define a bounded implementation with clear ownership, acceptance criteria and an operating cost assessment.

Sources and interpretation

Reviewed: 29 October 2026. The linked protocol documentation establishes technical interface concepts. The six capabilities, operating roles and implementation steps are our architectural recommendation, not a universal product standard. The example contains no customer data and makes no promise of a particular saving.