Where AI Agents Fit in the Enterprise Platform and Data Landscape
AI has moved past the point where the only interesting question is whether it can produce a useful answer. Many organisations already run assistants that summarise, draft and retrieve. The harder question is architectural: when AI is expected to help move work forward, where does it sit in the enterprise? An agent is best understood as an execution and orchestration layer that runs on top of existing data, applications, workflows and controls. Its usefulness is set less by the model behind it than by how well that layer connects to the systems that already run the business.
The design question changes
Once an agent is meant to act rather than only respond, the decisive questions stop being about model selection. They become: what data and systems can the agent reach, what can it trigger, what context does it receive, and under which controls does it operate? These belong to architecture, integration and governance. They also explain why many organisations already hold part of the foundation without having built a single agent. Data platforms, integration services, workflow engines, observability tooling, API gateways and access management are all directly relevant to agentic readiness.
A single request, four layers
A concrete view helps. Imagine a customer or back office request arriving at an agent. To handle it, the agent first assembles context: customer master data from the CRM, order or stock status from the ERP, case or contract data from a domain specific application, and relevant passages from an internal knowledge base. This is the context layer, and its quality is decisive. If that data is fragmented, outdated or missing key state, decision quality degrades quickly. This is why the harder work is increasingly about deciding what data, state and retrieved information an agent should see at each step, rather than about wording a prompt, a shift sometimes called context engineering.
With context in hand, the agent plans and selects an action. This reasoning and orchestration layer decides what should happen and in what order. To carry the step out, it reaches the action layer and calls a tool or API to verify an entitlement, update a record or trigger a workflow. Before anything executes, a control point applies: the agent checks permissions, records the action, and either performs a bounded operation or routes the case to a person with the full trace attached. These four layers, context, reasoning, action and control, are where the enterprise landscape becomes the agent's operating environment rather than background.
Figure 1 — An agent sits between the existing systems it reads from and acts on (left) and the control plane that governs every step (right).
The connective tissue
Two elements hold this together and deserve architectural attention. The first is how agents connect to systems. Rather than building bespoke integration for every system, agents increasingly reach them through defined tool and function interfaces. Each interface works as a contract: it states what the agent may call and what it gets back in return. Open, shared conventions for these interfaces are now emerging, the Model Context Protocol being one example, and they make the connections more consistent and reusable across systems.
An agent is a machine actor, and it should inherit bounded, auditable permissions rather than run under a broad service account.
The second element is orchestration. Enterprise value rarely comes from a single inference. It comes from coordinating several steps reliably: retrieving context, choosing a tool, executing an action, checking the result, then deciding whether to continue, pause or escalate. Here the operational discipline that platform teams already practise becomes essential. Steps need timeouts and safe, idempotent retries, so that repeating a failed call does not duplicate an order or a payment. Each step should also emit signals that monitoring can pick up, from tool call latency and success rates to unexpected outputs. That way teams notice when behaviour drifts, rather than finding out after the fact. Not every process needs an open ended agent either. Stable, well defined processes are often better served by structured workflows that are easier to test and audit, with agents reserved for cases that genuinely need flexible, model driven decisions.
Control is the enabler, not the obstacle
The closer agents move to action, the more identity, permissions, observability and policy enforcement become part of the design itself. Every action the agent takes should be recorded: its inputs, the tools it called and the result. That audit trail supports traceability and, where needed, a replay of what happened. In regulated Swiss industries such as banking, insurance, healthcare and the public sector, this control plane is what makes agents viable in the first place. Traceability, bounded permissions and clear points of human approval turn control into an enabler rather than a brake. And the underlying architecture question stays the same whether the platform runs on Microsoft Fabric, Databricks, Snowflake or a cloud native stack.
This suggests a practical next step for organisations already past isolated assistants. Ahead of selecting a model or drafting an ambitious list of use cases, the more useful exercise is an honest look at architecture fit, taken process by process: where trusted context already exists, where safe paths to action are already in place, and where the control mechanisms are still missing. That review usually shows that part of the groundwork is already there, and it points clearly to the gaps worth closing first. This is where the path from AI experimentation to dependable enterprise capability begins.