Agents | Pillar 6 of Enterprise AI Architecture

Introduce Autonomy Only After the Enterprise Foundation Is Ready

AI agents are often presented as the starting point for enterprise AI: give an agent a goal, connect it to tools and let it perform the work.

That reverses the correct construction order.

An agent can only be as reliable as the strategy, work definition, capabilities, services, interfaces and controls beneath it. If those foundations are vague or unstable, autonomy does not fix them. It executes the ambiguity faster and with less human visibility.

Within Enterprise AI Architecture, agents are Pillar 6—the final construction layer.

This is the principle behind agents last.

Agents last does not mean agents never. It means autonomy is introduced only after the enterprise has something stable, bounded, observable and valuable to automate.

Agents should orchestrate validated enterprise capabilities. They should not invent the enterprise architecture while they run.

What Is an Enterprise AI Agent?

An enterprise AI agent is a software system that can interpret a goal or event, select among approved capabilities, make bounded execution decisions and take actions on behalf of a user or organization.

Depending on its approved authority, an agent may:

• Interpret a request or operational event
• Determine which approved capability should be used
• Build or adapt a limited execution plan
• Call APIs, services or tools
• Maintain task state across multiple steps
• Evaluate intermediate results
• Ask for missing information
• Request human approval
• Retry, stop, escalate or select a permitted fallback
• Complete a defined business outcome

The defining characteristic is not that the system uses an LLM. It is that the system has some discretion over what action to take, which capability to invoke or how to advance the work.

That discretion creates value—but it also creates authority and risk.

Assistants, Workflows and Agents Are Not the Same

The terms assistant, automation and agent are frequently used as though they were interchangeable. They are not.

System type	Primary behavior	Who controls the sequence?	Typical authority
Assistant	Answers, drafts, summarizes or recommends	User	Usually read-only or advisory
Deterministic workflow	Executes predefined steps and rules	Application code or workflow definition	Explicit and predictable
AI-assisted workflow	Uses AI inside one or more predefined steps	Application code with bounded AI decisions	Limited to the workflow contract
Agent	Selects capabilities or adapts execution within a goal and policy boundary	Agent within approved constraints	Variable and potentially broader

An LLM call inside a workflow does not automatically make the system an agent. A chatbot that only retrieves information is not necessarily an agent. A workflow engine that follows a fixed sequence is automation, even if one step uses AI.

This distinction matters because each pattern requires a different level of control. Calling every AI-enabled application an agent creates confusion about authority, risk and production requirements.

Why Agents Are Pillar 6

Enterprise AI Architecture uses six pillars as a construction sequence:

1. AI Strategy
2. Work Definition
3. Capability Realization
4. AI Core Applications
5. Interfaces
6. Agents

Each earlier pillar answers a question that must be resolved before bounded autonomy can be introduced safely.

Pillar 1: AI Strategy—Why Should Autonomy Exist Here?

Strategy defines the business outcome, acceptable risk, prohibited uses and limits of automation.

Before approving an agent, the organization should know:

• What outcome requires adaptive execution
• Why deterministic automation is insufficient
• What business value autonomy is expected to create
• Which decisions must remain human
• Which failures would be unacceptable
• What cost and risk the organization will tolerate

An agent without a strategic reason is usually technology searching for authority.

Pillar 2: Work Definition—What Work Is the Agent Orchestrating?

The workflow, decisions, unit tasks, exceptions and ownership must be understood before an agent is allowed to navigate them.

If the organization cannot explain the work to experienced people, it cannot safely delegate that work to an agent.

Work definition identifies:

• The trigger and desired outcome
• Required information
• Decision points
• Business rules
• Exception paths
• Human responsibilities
• Escalation conditions
• Completion criteria

An undefined workflow does not become intelligent when an agent runs it. It becomes less predictable.

Pillar 3: Capability Realization—Are the Executable Units Stable?

Agents should call contract-defined capabilities rather than manipulate enterprise systems through vague instructions.

A capability should define:

• Purpose
• Inputs and outputs
• Validation rules
• Required identity and permissions
• Data boundaries
• Failure behavior
• Cost and latency expectations
• Evaluation status
• Human-review requirements

Capabilities should be testable independently from the agent. If a capability is unreliable when called directly, adding an agent will not stabilize it.

Pillar 4: AI Core Applications—Should the Capability Be Shared?

Some capabilities become reusable enterprise services: document intelligence, forecasting, classification, recommendation, anomaly detection or governed knowledge retrieval.

Centralized AI Core Applications provide agents with approved, monitored and versioned intelligence. This reduces the temptation for every agent team to build its own uncontrolled model connections, retrieval pipelines and business logic.

Pillar 5: Interfaces—How Will People Exercise Authority?

Interfaces define how users provide goals, review plans, supply missing information, approve actions, correct results and understand system status.

The interface should expose the agent’s capabilities and limits without becoming the owner of the business logic.

Safe agent interfaces make clear:

• What the agent is doing
• Which actions require approval
• Which data and systems it can access
• What has already been completed
• Where uncertainty or failure occurred
• How a user can pause, correct or stop execution

Pillar 6: Agents—Is Bounded Autonomy Now Justified?

Only after the earlier layers are stable should the organization decide whether adaptive orchestration creates enough additional value to justify its additional risk.

Pillar 6 does not assume the answer is yes.

The most mature architecture is not the one with the most agents. It is the one that uses the least autonomy required to produce the desired outcome.

The Agents-Last Principle

Agents last is a construction-order principle with five implications.

1. Use the Simplest Execution Pattern That Works

If a deterministic workflow can perform the work reliably, use it. If AI is only needed for one classification or extraction step, isolate AI inside that step. If a human should choose the next action, build an assistant.

Use an agent when the work genuinely requires bounded adaptation, capability selection or planning that cannot be justified as a fixed workflow.

2. Separate Reasoning From Authority

An agent may recommend an action without having permission to execute it. It may construct a plan without being authorized to approve it.

The ability to reason about an action and the authority to perform that action should be separate architectural decisions.

3. Give Agents Capabilities, Not Unrestricted System Access

Agents should operate through an approved capability catalog. Each capability should enforce its own authentication, authorization, validation, logging and policy controls.

The agent chooses among allowed capabilities. It does not receive an all-purpose credential and direct access to every underlying database or application.

4. Increase Autonomy Progressively

Begin with recommendation, observation and human approval. Expand autonomy only when production evidence shows that quality, security, cost and exception handling remain acceptable.

5. Preserve Human Accountability

The enterprise remains responsible for actions performed by its agents. Accountability cannot be assigned to a model.

Every agent requires a business owner, technical owner, risk classification, approval policy and intervention authority.

A Progressive Autonomy Model

Autonomy should be treated as a controlled progression, not a binary switch.

Level	Agent authority	Human role	Appropriate use
0. Advisory	Generate information or recommendations	User decides and acts	High-risk or poorly understood work
1. Proposed action	Select a capability and propose parameters	User approves every action	Early validation of agent decisions
2. Approved execution	Execute one approved action	User approves consequential steps	Bounded tasks with clear contracts
3. Bounded orchestration	Execute multiple approved capabilities within a defined workflow	Human reviews exceptions and selected checkpoints	Stable processes with known failure modes
4. Supervised autonomy	Respond to approved events and complete bounded outcomes	Human monitors, handles escalations and can intervene	Mature, observable, lower-risk operations

Higher autonomy is not automatically better. The appropriate level depends on consequence, reversibility, data sensitivity, quality evidence and organizational risk tolerance.

Multi-agent coordination should not be treated as the default next level. It adds communication, state, attribution, evaluation and failure-propagation complexity. It should be introduced only when separate agent roles solve a demonstrated problem better than one orchestrator using validated capabilities.

Reference Architecture for an Enterprise AI Agent

A production agent is not just a prompt connected to tools. A complete agent architecture normally includes several distinct components.

Trigger or User Interface

The work may begin with a user request, application event, message, schedule or operational condition. The trigger must be authenticated, validated and associated with an approved purpose.

Agent Identity and User Context

The system must know which identity is acting, whether authority is delegated from a user and which tenant, department, role or data boundary applies.

An agent should not silently inherit every permission held by its developer, service account or sponsoring user.

Goal and Task State

The agent needs a bounded representation of the desired outcome, current progress, completed actions, remaining work and stop conditions.

Task state should be distinguishable from long-term memory. Not every interaction should become durable memory.

Planner or Orchestrator

The planning component determines which permitted capability should be used or which approved step should occur next.

Plans should be limited in depth, duration, cost and capability scope. Open-ended planning creates open-ended risk.

Capability Registry

The registry identifies which capabilities exist and the contracts, owners, permissions, environments, risk levels, versions and approval status associated with them.

Tool-discovery protocols can help an agent locate capabilities. They do not replace enterprise inventory, authorization or governance.

Policy and Authorization Layer

Every proposed action should be evaluated against identity, role, data classification, risk, environment and current task context.

Authorization must be enforced by trusted application and platform controls—not by asking the model whether an action seems permitted.

Execution Router

The execution router calls the approved implementation: C# application logic, ML.NET, an LLM, Azure AI service, enterprise API, workflow service or human-review queue.

The agent requests an approved capability. The router determines how that capability is executed and governed.

Memory and Context

Memory may include task state, approved preferences, prior outcomes or other retained context. It requires explicit decisions about:

• Purpose
• Source
• Accuracy
• Retention
• User visibility
• Correction
• Deletion
• Data classification
• Cross-user or cross-task isolation

Memory is not automatically beneficial. Incorrect or stale memory can repeatedly distort future actions.

Human Approval and Escalation

The system must know which actions require approval, which failures require escalation and who has authority to intervene.

Approval should present enough context for a real decision: proposed action, affected systems, important inputs, expected result and potential consequence.

Observability and Evaluation

The organization should be able to reconstruct:

• The initiating identity and request
• The active model, prompt and policy versions
• The plan or selected next step
• Capabilities considered and selected
• Tool inputs and outputs
• Authorization decisions
• Human approvals and overrides
• Retries, loops and failures
• Final outcome
• Latency and cost

Without this trace, the enterprise cannot reliably investigate why an agent acted.

Intervention and Kill Switches

Operators need mechanisms to:

• Pause new agent runs
• Stop an active task
• Disable one capability
• Revoke an identity or credential
• Reduce the permitted autonomy level
• Isolate an environment
• Roll back a configuration
• Route work to a human process

A kill switch that has never been tested is a diagram, not a control.

Capability Whitelisting

The safest default is explicit capability whitelisting.

An agent may use only capabilities that are approved for:

• That agent
• That identity or user role
• That environment
• That business purpose
• That data classification
• That autonomy level

The whitelist should also limit parameter ranges, transaction values, affected records, rate, spending and time.

For example, an IT support agent might be allowed to:

• Classify a support request
• Recommend a routing queue
• Retrieve an approved knowledge article
• Validate required ticket fields
• Create a draft ticket

It should not automatically receive authority to reset executive credentials, disable production services or run arbitrary PowerShell because those actions are technically possible.

Human Approval Should Follow Consequence

Not every action requires the same review.

Approval policy should consider:

• Reversibility
• Financial impact
• Legal or regulatory consequence
• Effect on customers or employees
• Data sensitivity
• Confidence and evaluation evidence
• Novelty of the situation
• Scope of affected records or systems

Low-risk, reversible actions may be automated after validation. High-impact or irreversible actions may always require a human decision.

Human-in-the-loop should not mean that a person mindlessly clicks Approve on every step. Approval must be placed where human judgment actually changes risk.

Agent Evaluation Must Measure the Complete Outcome

Evaluating an agent requires more than judging the final wording of a model response.

Useful measures include:

• End-to-end task completion rate
• Correct capability selection
• Correct parameter construction
• Policy-compliant behavior
• Unauthorized actions attempted and blocked
• Human approval and rejection rates
• Human corrections and overrides
• Escalation accuracy
• Tool and dependency failure rates
• Retry and loop frequency
• Average steps per completed outcome
• Latency
• Cost per completed business outcome
• Recovery from partial failure
• User trust and adoption

Evaluation datasets should include normal work, ambiguous requests, incomplete information, edge cases, prohibited actions and adversarial inputs.

An agent that succeeds only when every tool responds perfectly and every request is clear is not production-ready.

Major Enterprise Agent Risks

Excessive Authority

Broad credentials can turn one compromised or misdirected agent into a path across multiple enterprise systems.

Compounding Errors

A small error early in a multi-step plan can distort every later step. The final result may look coherent even though the execution path was wrong.

Prompt Injection and Tool Manipulation

Retrieved documents, websites, messages or tool responses may contain instructions designed to redirect agent behavior or expose data.

Runaway Loops and Cost

Agents may retry, replan or call expensive capabilities repeatedly. Limit steps, elapsed time, tokens, transactions and spending.

Stale or Incorrect Memory

Persistent context may preserve outdated facts, incorrect assumptions or data that should no longer be retained.

Ambiguous Accountability

Agent actions may cross business, application, data and security ownership boundaries. Accountability must be assigned before deployment.

Hidden Operational Dependency

Organizations may allow critical work to depend on a model, provider, tool or prompt configuration without a tested fallback.

Multi-Agent Failure Propagation

When agents delegate to other agents, errors, permissions and context can propagate across boundaries that are difficult to observe and evaluate.

These risks do not make agents unusable. They make architecture and progressive autonomy necessary.

The Agent Readiness Gate

Before an AI system advances from interface-driven execution to agentic orchestration, verify that:

• The business outcome and reason for autonomy are documented.
• A deterministic workflow or simpler assistant is insufficient.
• The work, decision points and exception paths are understood.
• Required capabilities have explicit contracts.
• Capabilities pass independent quality, security and performance tests.
• Agent identity and delegated authority are defined.
• The permitted capability whitelist is documented.
• Authorization is enforced outside the model.
• Human-review and escalation rules are approved.
• Step, time, cost and transaction limits exist.
• Memory purpose, retention and isolation are defined.
• End-to-end agent evaluations meet approved thresholds.
• Observability can reconstruct the complete execution path.
• Operators can pause, contain and disable the agent.
• A fallback process exists.
• Business, technical, security and operational owners accept responsibility.

If these conditions are not met, the architecture is not ready for greater autonomy.

Microsoft-Centric Agent Implementation

The EAA agent pattern is technology-independent, but it fits naturally into Microsoft-centric enterprise environments.

Depending on the use case, an implementation may use:

• C# and .NET for capability contracts, orchestration services and policy enforcement
• ASP.NET Core for secured capability APIs
• Microsoft Entra ID for user, workload and agent identities
• Azure API Management for controlled API exposure
• Azure Key Vault for managed secrets
• Azure Service Bus for asynchronous work, queues and backpressure
• Azure OpenAI and other approved models for bounded reasoning tasks
• Semantic Kernel or approved agent frameworks where adaptive orchestration is justified
• ML.NET and ONNX for deterministic local prediction capabilities
• SQL Server or Azure SQL for governed task state and operational records
• Application Insights and Azure Monitor for traces, metrics and alerts
• Microsoft Defender and Sentinel for threat detection and investigation
• Microsoft Purview for data governance and compliance
• Azure DevOps or GitHub for versioning, evaluation gates and controlled releases

The important architectural decision is not which agent framework is fashionable. It is where identity, capability contracts, policy enforcement, observability and operational control reside.

Frameworks will change. Enterprise responsibilities will not.

What Agents Should Not Own

Agents should not become the hidden owner of:

• Core business rules
• Authorization policy
• Regulatory interpretation
• Enterprise data-access decisions
• Unbounded code execution
• Production credentials
• Final accountability
• Undocumented cross-system integrations

These responsibilities belong in governed enterprise components and accountable human structures.

The agent may interpret context, recommend a path and orchestrate approved capabilities. It should not replace the architecture that makes those actions safe.

Who Pillar 6 Is For

The Agents pillar is designed for:

• CIOs and CTOs considering autonomous AI systems
• Enterprise and solution architects
• AI, application and platform engineering leaders
• C# and .NET development teams
• Security, identity, compliance and governance teams
• Operations, SRE and support organizations
• Business owners delegating work to AI-enabled systems
• Government and regulated enterprises

It is especially important for organizations moving from assistants and isolated AI capabilities toward cross-application execution.

Agents Are the Capstone, Not the Foundation

Agents can create substantial value when work requires bounded adaptation across stable enterprise capabilities. They can reduce coordination effort, respond to events, manage exceptions and complete multi-step outcomes.

But agents multiply whatever architecture already exists.

If strategy is unclear, they pursue the wrong outcome. If work is undefined, they automate confusion. If capabilities are unstable, they orchestrate failure. If permissions are broad, they expand the blast radius. If observability is weak, they make accountability harder.

That is why agents come last.

Strategy before work. Work before capabilities. Capabilities before interfaces. Guardrails before autonomy. Agents last.

Next Steps

• Explore Enterprise AI Architecture
• Explore Enterprise AI Strategy | Pillar 1
• Explore Work Definition | Pillar 2
• Explore Capability Realization | Pillar 3
• Explore AI Core Applications | Pillar 4
• Explore the AI Engineering Discipline and Delivery Lifecycle
• Explore Enterprise AI Governance

Frequently Asked Questions