AI Agents in the Enterprise

The most consequential change in enterprise AI begins when a system stops suggesting what someone should do and starts doing it on their behalf. A flawed answer can mislead a reader. A flawed action can alter a customer record, disclose confidential information, or create a commitment the enterprise must honour. Moving from assistance to agency changes the architecture of responsibility.

As an Enterprise Architect, I believe the strategic question is how much authority an organisation can delegate while retaining evidence that its systems are acting within that authority and producing worthwhile outcomes. Model capability matters. So do the boundaries around it, the quality of the information it receives, and the operational discipline that surrounds every release.

The adoption forecasts explain the urgency. In August 2025, Gartner predicted that 40% of enterprise applications would include task-specific AI agents by the end of 2026, compared with less than 5% at the time. That is a forecast, rather than confirmation that the transition has already happened. It nevertheless describes a substantial expansion in the software capable of acting for us.

Adoption and impact must be measured separately. McKinsey's 2025 survey found that 88% of respondents reported regular AI use in at least one business function. Around 6% met its definition of AI high performers: respondents attributing at least 5% EBIT impact and significant value to AI. These are different measures, not a conversion funnel proving that 94% of adopters failed. The same survey found 23% scaling an agentic system somewhere in their organisation and another 39% experimenting with agents. The opportunity is real; enterprise-wide impact remains a separate achievement.

Other research reinforces the need for discipline without establishing a universal failure rate. S&P Global Market Intelligence reported in May 2025 that 42% of companies abandoned the majority of their AI initiatives before production. RAND's 2024 research cited estimates of more than 80% of AI projects failing, rather than deriving that figure as a new representative failure-rate measurement. These findings concern broader AI projects and different populations. They should encourage scrutiny of delivery economics, rather than be combined into a dramatic but misleading statistic.

The distinction between copilots, agents, and digital workers is useful when it describes delegated work. A copilot supports a person who remains in control of the sequence. An agent can select and execute multiple steps towards a bounded goal. A system described as a digital worker may coordinate an entire workflow, but an accountable human owner must still carry responsibility for the outcome. These are design choices, not inevitable stages that every process should climb.

Greater autonomy is valuable only where adaptation improves the result. A predictable calculation may need ordinary software. A fixed sequence may need a workflow engine. An agent becomes useful where selecting the next action requires interpreting changing context. Nor does memory mean that an agent automatically learns safely from experience. Retaining a conversation, improving a model, and changing an approved operating policy are distinct activities with different assurance requirements.

The model is one component of the operating system around that decision. The agent harness supplies instructions, tool definitions, execution logic, context management, and controls. Its loop proposes an action, invokes an authorised tool, observes the result, and decides what comes next. The surrounding software must also determine when to stop, when to escalate, and how to recover from a partial failure.

This is where architecture becomes concrete. A system prompt can state that an agent must respect a transaction limit. Only an independently enforced permission or transaction check can reliably prevent the tool from exceeding it. Policy written in natural language is guidance; policy enforced at the action boundary is a control.

Every tool therefore represents delegated authority. Access should be scoped to the agent's identity, business purpose, permitted records, and approved operations. Short-lived credentials, explicit limits, and separation between proposing and executing consequential actions make that authority manageable. Delegating to another agent must preserve the original restrictions rather than create a route around them.

Risk cannot be inferred from a tool's name alone. Reading an account record may expose sensitive information. Searching documents may retrieve malicious instructions embedded in otherwise legitimate content. Creating an internal ticket may be reversible and routine, while sending a client communication may establish a commercial expectation. Code execution needs isolation and constrained network and filesystem access. The relevant questions concern sensitivity, consequence, reversibility, and scope.

For material transactions and external commitments, I would require human approval unless the organisation has explicitly authorised a narrow, tested form of automatic execution. The reviewer needs the proposed action, supporting evidence, affected parties, and meaningful alternatives. Approval must bind to that specific action and expire when relevant inputs change. A confirmation button that conceals the consequences creates little assurance.

The security evidence makes this practical rather than theoretical. IBM's 2025 Cost of a Data Breach announcement reported that 13% of organisations studied had experienced breaches of AI models or applications; 97% of that affected group reported lacking proper AI access controls. The denominator matters. The finding does not mean that 97% of all AI deployments were breached, but it highlights the danger of extending capability faster than access governance.

A second system must accompany the agent harness: an evaluation harness. The first enables action. The second provides evidence about whether the system performs acceptably under defined conditions. Neither a convincing demonstration nor a model benchmark establishes that an enterprise workflow is ready for production.

Evaluation should begin with representative tasks and explicit acceptance criteria. Test whether the agent completes the business objective, uses authorised information, chooses permitted tools, respects approval gates, and recognises when it lacks sufficient evidence. Include ambiguous requests, stale data, conflicting records, malicious retrieved instructions, unavailable dependencies, and repeated attempts at the same transaction. A failed request followed by a retry must not quietly create two payments or two orders.

Every prompt revision, model replacement, retrieval change, and tool update should face the relevant regression tests. Measure task success alongside unauthorised actions, unsupported claims, escalation quality, latency, and cost per successful outcome. An aggregate score can conceal a rare but serious failure, so critical scenarios need their own release thresholds. Automated graders can help, provided their judgements are calibrated against human review and objective checks.

Evaluation also continues after release. Controlled rollout, production sampling, incident analysis, and tested rollback procedures provide evidence that laboratory performance survives contact with real work. Record versions, retrieved evidence, tool requests and responses, policy decisions, and approvals, with appropriate redaction and retention. Auditors need an actionable execution record and a concise decision rationale; a generated explanation should never be mistaken for proof of the model's internal reasoning.

Data architecture deserves equal attention. Structured systems provide authoritative records. Documents and conversations explain institutional context. Live feeds provide timely signals. Calculation and execution tools allow the agent to verify quantities and act. Connecting these sources is useful only when the enterprise also defines their authority, freshness, ownership, and permitted uses.

Grounding reduces some unsupported outputs, but it does not eliminate hallucination. A system can retrieve the wrong document, misread a correct one, combine incompatible reporting dates, or draw an unjustified conclusion from accurate facts. Retrieved text must be treated as evidence rather than as instructions with authority over the agent. Persistent memory needs provenance, expiry, correction, and deletion controls so that yesterday's mistake does not become tomorrow's assumed fact.

Consider an agent supporting an investment operations exception. It may retrieve the trade record, compare settlement instructions, consult an approved procedure, and propose a resolution. That does not automatically authorise it to amend standing instructions or release a payment. If sources disagree, the appropriate outcome may be a well-supported escalation. Successful automation includes knowing when to stop.

Production readiness in this example means that the organisation can identify the source records and their timestamps, explain the proposed resolution, verify the approval, prevent duplicate execution, and reconcile the result with the system of record. A dashboard showing that the agent completed its loop is insufficient. The business outcome must be confirmed independently.

Scaling this capability requires an operating model. A centralised team can provide consistency when domain teams lack engineering capacity. Federation can work where domains have the skills and operational accountability to run their own systems. Neither organisation size nor the number of agents alone determines the right arrangement.

For a large enterprise with uneven capabilities, I favour a hybrid approach: common identity, policy enforcement, registries, telemetry, and evaluation standards, with domain ownership of workflows, data meaning, acceptance criteria, and business results. Application operations can remain central or move into capable domains. The division must be explicit: platform teams own shared infrastructure reliability; domain owners remain accountable for agent quality and the consequences of their business process. Cross-team incidents still need a single coordinator and a rehearsed escalation path.

Governance can develop through three practical moves: establish visibility, enforce controls, and maintain assurance as systems change. Visibility means an inventory connecting each agent to an owner, purpose, model version, data sources, tools, and deployment. Controls mean permissions, risk-based approval, budgets, execution limits, and a reliable suspension mechanism. Continuous assurance means those controls and evaluations remain effective as the environment evolves.

I would treat maturity as a planning aid. Initial pilots become an emerging capability when basic policies, budgets, and logging exist. A defined capability adds a complete inventory, accountable owners, and per-agent controls. Proactive governance embeds evaluation and cost gates into delivery and monitors production behaviour. Optimised governance connects assurance, economics, and outcomes over time. Even at that stage, changes to consequential policies require controlled approval; maturity should not imply that agents can rewrite their own limits.

The next step should address the most important missing capability. A team without an inventory needs visibility. A team with reliable logs but no regression tests needs evaluation. A team with technically successful agents but no demonstrated benefit needs to revisit workflow design and its business case. More agents are not evidence of greater maturity.

Leaders should judge the economics at the level of completed work. Include model usage, retrieval, tool calls, retries, human review, incident handling, and ongoing maintenance. Establish the existing process baseline and decide how released capacity will produce value. Faster processing matters when it improves service, reduces an actual expense, or enables useful work that previously went undone.

The Enterprise Architect's contribution is to connect that outcome to the capability being changed, the information required, the authority delegated, and the evidence needed to justify expansion. Begin with one bounded workflow. Give it an owner, an operational baseline, explicit permissions, an evaluation suite, and a recovery path. Expand its authority only when results support doing so.

The durable advantage will belong to organisations that can delegate responsibly and improve that delegation through evidence. Speed matters because opportunities do not wait. Judgement matters because automated mistakes also scale. Enterprise leadership must build the conditions in which both can coexist.