Enterprise Architecture in the Age of AI Agents

AI agents change enterprise architecture because they introduce a new kind of application participant: software that can interpret a goal, choose tools, sequence actions and adapt its execution path at runtime.

That does not remove the need for deterministic systems. It makes the boundaries around those systems more important.

An agent is not just another user interface

Traditional enterprise applications usually have a relatively predictable execution model. A user initiates a transaction, an API receives a defined request, or an event triggers a known workflow.

An agent can operate differently. It can decide which tool to call, whether more context is needed, how to decompose a task and which sequence of actions best satisfies a goal.

Microsoft's current architecture guidance describes agents as systems that use a language model to decide which actions and tools to use and how to sequence them. Microsoft Foundry Agent Service provides managed agent runtime, tools, identity and observability capabilities, while Microsoft Agent Framework provides a code-first programming model.

For enterprise architects, the important implication is that reasoning has entered the execution path.

That creates a new architectural responsibility: control the space in which the reasoning system is allowed to act.

The autonomy boundary

A useful agent architecture starts by defining its autonomy boundary.

That boundary answers questions such as:

• What decisions may the agent make independently?
• Which systems may it read?
• Which actions may it propose?
• Which actions may it execute?
• Which actions require approval?
• What transaction value or risk thresholds change the approval model?
• What happens when the agent is uncertain?
• What happens when a downstream system fails halfway through a multistep task?

The autonomy boundary is more useful than a generic label such as "human in the loop" because it can be applied per tool and per business action.

For example:

Read customer balance          -> autonomous
Explain overdue invoices       -> autonomous
Prepare collection activity    -> autonomous draft
Change credit limit            -> approval required
Post financial adjustment      -> restricted / deterministic process

The architecture should make those differences explicit.

Treat the agent as a principal

An agent should not be treated as invisible application logic.

It needs an identity model, ownership, lifecycle and an auditable relationship to the users or workloads that invoke it.

The identity question has at least three layers:

1. User identity: who requested the work?
2. Agent identity: which deployed agent is acting?
3. Tool identity: under which security context is the downstream action executed?

Microsoft Foundry supports agent identity and managed authentication patterns for downstream tool access. Copilot Studio also distinguishes user authentication from maker or agent-provided credentials for tools.

The architecture decision is not simply whether authentication exists. It is whether the downstream system can enforce the correct business authorization and preserve accountability.

An agent must not gain a broader data boundary simply because the model can reason about more information than the user can access.

Tools are the real control surface

Models generate intentions. Tools create effects.

That makes the tool catalogue one of the most important enterprise architecture assets in an agent solution.

A strong tool contract should define:

• business purpose
• input schema
• output schema
• required identity
• authorization policy
• side effects
• idempotency characteristics
• approval requirement
• timeout and retry behavior
• audit requirements
• data classification

This is why business-oriented tools are preferable to generic technical tools for high-value enterprise processes.

Compare:

update_record(table, key, fields)

with:

prepare_vendor_bank_account_change(vendor, proposedDetails)

The second contract is narrower, easier to govern and easier to connect to business controls.

MCP standardises connection, not governance

Model Context Protocol is useful because it standardises how agents discover and invoke external tools and contextual resources.

It does not decide whether a tool is appropriate for a business process, whether the user is authorised, whether an approval is required, or whether the action violates segregation of duties.

Those remain enterprise architecture responsibilities.

An MCP server should therefore be treated as a governed integration boundary, not as a shortcut around the API and security architecture.

Enterprise systems remain authoritative

An agent can reason about a process without becoming the system of record for that process.

Dynamics 365, Dataverse, line-of-business systems and enterprise data platforms should retain explicit ownership of business state.

For example, an agent may:

1. retrieve supplier and purchasing context
2. reason about a procurement exception
3. recommend an action
4. prepare a draft request
5. submit it through an approved tool

The resulting purchase requisition, workflow state and accounting consequences should still be governed by the transactional platform.

The agent orchestrates intent. The business system remains authoritative for the transaction.

Deterministic workflow still matters

Agentic execution should not replace deterministic workflow everywhere.

Deterministic automation is usually preferable when:

• the process path is known in advance
• rules are stable
• transaction consistency is critical
• the same input should reliably produce the same operational action
• audit requirements demand a fixed sequence
• failure recovery must be precisely controlled

Agentic execution becomes more valuable when:

• the task needs interpretation
• inputs are unstructured
• the sequence cannot be fully known at design time
• multiple information sources must be evaluated
• tool selection depends on context
• exceptions are frequent enough that fixed workflow becomes brittle

A mature architecture will normally contain both.

The agent should orchestrate, not absorb every responsibility

A common architecture mistake is to place too much logic in prompts or agent instructions.

Business rules that require deterministic enforcement should remain in governed services or applications.

For example:

Agent instruction:
"Do not approve discounts above 20%."

is weaker than:

Agent
  -> request_discount(...)
  -> Policy/API layer
  -> deterministic discount authority check
  -> approval workflow if required

Instructions shape agent behavior. They should not be the only enforcement mechanism for material business controls.

Knowledge and transaction access are different concerns

Retrieval architecture and action architecture should be separated conceptually.

An agent might use enterprise knowledge to understand:

• policies
• product documentation
• implementation guidance
• contracts
• operating procedures

It might use transactional tools to:

• retrieve an order
• create a case
• prepare a journal
• submit a workflow request

These have different freshness, security, audit and failure characteristics.

A retrieval result is context for reasoning. A transaction changes enterprise state.

The architecture should not treat them as equivalent forms of "data access."

Observability must cover decisions and effects

Traditional application monitoring often focuses on requests, exceptions and performance.

Agent observability also needs to answer:

• What goal was the agent trying to achieve?
• Which tools were available?
• Which tools did it select?
• What arguments were validated?
• Which identity was used?
• Was approval requested?
• What downstream transaction was created?
• Did the agent retry or choose an alternative path?
• What was the final business outcome?

Microsoft Foundry provides agent tracing and observability capabilities, but enterprise monitoring still needs correlation with downstream APIs, integration services and business transactions.

The operational unit is not only the model invocation. It is the complete business action chain.

Multi-agent is an architecture choice, not a maturity level

A multi-agent design is not automatically more advanced or more scalable than a single-agent design.

Adding agents introduces:

• additional orchestration
• more identity boundaries
• more prompts and instructions to version
• additional failure modes
• more complex tracing
• potentially higher latency and cost

Use specialised agents when there is a clear separation of responsibility, context, security boundary or lifecycle.

Do not decompose a solution into multiple agents merely because the platform supports it.

Architecture ownership changes

Agentic systems cross several traditional delivery boundaries.

A production design normally needs explicit ownership across:

• business process
• enterprise application
• data
• integration
• identity and security
• AI model/runtime
• tool catalogue
• prompt/instruction lifecycle
• observability
• responsible AI controls
• release management

This is why agent initiatives can fail when treated only as an AI development exercise.

The difficult questions often sit outside the model itself.

A practical reference model

A useful enterprise agent architecture can be viewed as seven layers:

1. Experience / Trigger
        |
2. Agent Runtime and Instructions
        |
3. Policy and Autonomy Controls
        |
4. Tool / MCP Boundary
        |
5. Enterprise APIs and Integration
        |
6. Systems of Record and Data Platforms
        |
7. Audit, Observability and Governance

Identity cuts through every layer.

The model is deliberately platform-neutral. A particular implementation might use Copilot Studio, Microsoft Foundry Agent Service, Microsoft Agent Framework, Azure integration services, Power Platform or custom application components. The architecture responsibilities remain even when a platform implements several of them for you.

Dynamics 365 implications

For Dynamics 365 programmes, agents should be treated as new consumers of ERP capabilities rather than an excuse to bypass established interfaces.

The design should still distinguish:

• standard Dynamics 365 functionality
• configuration
• extensions
• supported service endpoints
• business events
• Power Platform capabilities
• external integration services
• agent tools

An AI agent should normally operate through a controlled capability boundary that respects Dynamics 365 security and business logic.

The question is not "Can the agent call Dynamics 365?"

The better question is:

Which business capabilities should be exposed, under which identity, with which controls, and what should remain deterministic inside the transactional platform?

Architecture principles for agentic enterprise systems

1. Define autonomy explicitly. Do not use a single autonomy setting for every tool.
2. Make tools business-oriented. Generic technical access expands the risk surface.
3. Preserve system ownership. Reasoning does not transfer transaction authority to the model.
4. Enforce material controls outside prompts. Use deterministic policy and application controls.
5. Separate retrieval from action. They have different architecture characteristics.
6. Design identity end to end. User, agent and downstream tool context all matter.
7. Make approval proportional to impact. Not every read needs approval, not every write should be autonomous.
8. Trace the business outcome. Model telemetry alone is not sufficient.
9. Use multi-agent only when responsibility genuinely separates. Complexity should earn its place.
10. Treat agents as governed software products. They need ownership, versioning, testing and retirement.

What changes for enterprise architecture

Agents do not make enterprise architecture obsolete.

They expose weaknesses in architectures where ownership, APIs, identity and controls were already ambiguous.

A well-designed agent can make enterprise systems easier to use because it can reason across those boundaries. But it should do so through boundaries that are more explicit, not less.

That is the architectural shift: from designing only deterministic application flows to designing controlled spaces in which software can reason and act.

Microsoft references

• Microsoft Foundry Agent Service overview
• Agent identity concepts in Microsoft Foundry
• Azure Architecture Center AI technology overview
• Copilot Studio security and governance
• Configure user authentication for Copilot Studio tools
• Using MCP tools with Microsoft Agent Framework