Managing the Growth
of Enterprise AI Agents

This article looks more closely at the architectural changes and context data the enterprise data platform needs for a future in which both people and agents consume its data.

Consider three requests. Customer service wants an agent to resolve enquiries, operations want one to investigate delivery failures, and commercial teams want one to flag accounts needing attention. All need the same customer and order data, yet each brings its own definitions, access rules and permissions to act. Unless those differences are settled early, the next wave of AI recreates the duplication the platform was built to remove.

Agents carry the argument of our earlier articles on enterprise AI economics and operating discipline into how work gets done. Build them around a priority use case, and agree ownership and conditions for reuse before separate teams build their own.

Architecture Becomes a Context Problem

Connecting an agent to customer, order and service data doesn't tell it how the records fit together. A dispatched order may still be late, a customer ID may mean an account rather than a person, and a closed ticket may not mean the problem was fixed. An analyst knows these caveats; an agent needs an explicit route to definitions, current evidence and open exceptions.

Gartner's May 2026 guidance names semantic context, the relationships and rules within enterprise data, as a requirement for reliable agents. Treat it as a maintained business asset: domain owners answer for what the data means, the data function for how it is published, traced and consumed. A customer data product should state its intended uses, freshness requirements and known limits, not just list fields.

Context also covers operating knowledge: policies, exceptions, contractual commitments and the reasoning behind decisions. The first build needs only the relevant subset, owned and kept alongside the data. Where sources conflict or evidence is too old, the agent should escalate with the facts rather than settle the dispute by inference.

Authority Must Be Designed Into Execution

Explaining a delivery failure supports an employee's judgement; applying a fixed routing rule automates a bounded task. Delegating a sequence of decisions and actions is autonomy, and it needs explicit limits and escalation paths, agreed with the operational owner and enforced by application and security teams.

Access to a trusted data product doesn't confer authority to act.

An instruction to seek approval means little if the agent can call a service that skips it. Controls should require approval before a change is accepted, keep the evidence used, and record who or what authorised the action. Plan for partial failure too: if one system updates and another doesn't, someone must own reconciliation and recovery.

An orchestration layer should coordinate steps, tool calls and hand-offs, including when to stop or bring in a person. Start with bounded work and test exceptions and recovery before widening authority. Add agents only where splitting the work justifies the coordination. The business owner stays accountable for the process; a named technical owner runs it in production.

Extend the Data Platform Into Governed Intelligence

The data platform must still serve reporting, as originally intended, and now must serve agents too. That brings new requirements, such as live transactional data for in-process decisions. Its architecture needs to be redrawn for the multiple uses an agentic workforce brings.

Decision Inc.'s architecture approach links the data platform with business context and intellectual property, control and administration, and model routing. Build on the catalogue, identity and storage capabilities you already have. Curated data products keep their lineage and quality controls, and maintained semantic definitions set how the data is read, giving analytics, predictive models and agents a common base.

The serving layer makes that base usable inside a workflow, through controlled retrieval, prediction inputs and low-latency interfaces. It must preserve access restrictions and be tested under expected demand; a pilot that queries a warehouse successfully doesn't prove production readiness. Check what the existing platform can be configured to do before copying the data again.

Reuse Requires Common Meaning and Accountable Ownership

Duplicated business logic can cost as much to maintain as duplicated integrations. Several teams may need the same customer identification and order retrieval. Share them where definitions and service requirements match; permissions to contact a customer or change an order stay with the process. Separate truly reusable components from similar-looking requests before funding a common service.

Before relying on a component, teams need the owner, permitted uses, data dependencies, version, test coverage and support arrangements, all visible in a capability catalogue. A change to a customer definition or source schema should trigger an assessment of the agents using it, with their owners involved in testing. Reuse spreads errors as efficiently as it spreads good capabilities.

The CDO should centralise shared standards and leave domain teams accountable for their own rules and outcomes. Fund the reusable semantic, serving and model capabilities explicitly, with support ownership, so the first use case doesn't carry an unexplained platform bill, then test them against the next use case's delivery time and maintenance effort. Reuse earns its place when it cuts repeated work without creating a central queue.

Measure Platform Value Through Delivered AI Outcomes

Data and Analytics leaders need to show whether shared foundations improve delivery as well as whether individual agents perform. Track how long it takes to move a qualified use case into production, how much integration and definition work must be repeated, and the support effort after release. Assess those measures alongside the business owner's process outcomes. A growing catalogue of agents is weak evidence of platform value if each one still requires extensive engineering and human oversight.

The relevance for Data and Analytics leaders is the trade-offs between architectural choices and the cost of operating the platform. Before introducing additional workloads, leaders should establish whether the platform supports a coordinated Agent workforce with the relevant context for them to take on unsupervised workloads. Addressing those constraints creates a firmer basis for assessing the cost and performance of subsequent AI use cases.

Model selection follows the task

Model selection should follow tested task requirements, supported by version control, evaluation and monitoring. Reassess quality when models, prompts or underlying data change, and set execution limits and spending ceilings. Measure the cost of an accepted outcome, including retrieval, supporting services, human review and rework. A deterministic calculation may need no language model; a complex investigation may justify a more capable one, so choose the least capable and cheapest model per use case. These controls should remain owned and maintained after launch.

Validate the Architecture Against One Priority Workflow

Define the target way of working first: what people keep, what an agent could carry, and which outcome justifies the investment. Then work back through data, knowledge, integration and identity to find the constraints. Pick one use case with accessible enterprise content, a clear process and a committed owner, and validate it on real business material. Set up monitoring, support and handover before production, then use the results to sequence further investment and test what the next build can reuse.