Agentic AI and Intelligent Enterprise Architecture

This chapter examines how AI systems move from generating responses to planning and carrying out multi-step tasks through tools, services, and workflows. It focuses on the architectural controls needed to make agentic systems useful, bounded, observable, and accountable in enterprise environments.

Why this chapter matters

Introduction

Generative AI has expanded the ways people interact with enterprise systems. Employees can ask questions in natural language, summarize information, generate content, and explore complex topics without navigating every underlying application. Yet many business processes require more than a response. They involve multiple steps, decisions, system interactions, validations, and follow-up actions.

Agentic AI extends generative AI applications toward these tasks. An AI agent can interpret a goal, determine a sequence of steps, use tools, observe the results, and adapt its approach within defined boundaries. Rather than responding only with text, an agent may retrieve information, call an API, prepare a document, initiate a workflow, or coordinate with other agents and services.

This shift has significant architectural implications. A system that can act introduces different risks from one that only provides information. It must operate with appropriate identity, authorization, tool permissions, transaction controls, monitoring, and human oversight. Its behavior must be constrained by business policy and technical safeguards, not simply by instructions in a prompt.

Agentic architecture also depends on the enterprise data capabilities developed throughout this book. Agents need access to trusted data, governed data products, semantic context, knowledge retrieval, and reliable integration services. They must understand the boundaries of the tasks they are permitted to perform and the systems that remain authoritative for business decisions and records.

The objective is not to make every process autonomous. Some tasks are suitable for bounded automation, while others require human judgment, formal approval, or deterministic business logic. Enterprise architects must distinguish between these cases and design the appropriate level of autonomy.

This chapter examines the foundations of agentic AI, its architecture patterns, tool integration, orchestration, security, governance, evaluation, and operating model. It uses Meridian Financial Group, a fictional organization, to illustrate how agentic capabilities can be introduced within a regulated enterprise.

15.1 From Generative AI Applications to Agentic Systems

A conventional generative AI application typically follows a relatively defined interaction pattern. A user submits a request, the application constructs a prompt, the model generates a response, and the application returns that response. Retrieval, validation, and other services may be included, but the overall flow is generally controlled by the application.

An agentic system introduces a more dynamic process. It may interpret a goal, select an action, invoke a tool, inspect the result, and determine what to do next. The sequence may vary depending on the information returned or the state of the task.

For example, an employee may ask an assistant to prepare a summary of a supplier’s current status. A conventional application might retrieve documents and generate a summary. An agentic application might identify the supplier, retrieve current records from an approved service, search for relevant contracts, check whether required information is missing, and prepare a draft summary with references. If permitted, it might then submit the draft for review.

The distinction is not simply that an agent uses tools. Many conventional applications call APIs. The defining architectural feature is that the system uses model-driven reasoning or planning to select and sequence actions toward a goal, while observing intermediate results.

The term agentic AI covers a range of designs. Some systems use a model to select among a small number of predefined actions. Others use planning loops, memory, specialized agents, or dynamic tool selection. These designs differ in complexity, reliability, and control requirements.

An enterprise should avoid treating “agent” as a single standardized technical category. It is more useful to describe the system in terms of its responsibilities, permitted actions, degree of autonomy, control points, and consequences of failure.

15.2 Defining an AI Agent

An AI agent is a software system that uses an AI model to interpret goals or inputs and determine actions within an environment. The environment may include APIs, enterprise applications, data platforms, workflow services, files, and other tools.

An agent generally has several capabilities. It receives an objective or task, uses context to interpret it, selects or proposes actions, invokes available tools, observes their results, and continues or concludes the task. Some agents also maintain task state or memory across interactions.

The model is only one part of the agent. The surrounding application provides identity, permissions, tool definitions, execution controls, state management, and monitoring. This distinction is important because a language model should not be treated as the system of record for authorization, transaction status, or business policy.

A useful enterprise definition describes an agent through its operating contract:

• Purpose: the business task the agent is designed to support.
• Scope: the information, processes, and systems within which it operates.
• Inputs: the user request, contextual data, and approved instructions.
• Tools: the services and actions it may invoke.
• Authority: the actions it may perform independently and those requiring approval.
• Constraints: business rules, security policies, and technical limits.
• Outcomes: the expected result and evidence required to demonstrate completion.
• Accountability: the human or organizational owner responsible for the agent’s behavior.

This contract helps prevent a broad goal such as “manage supplier onboarding” from becoming an undefined permission to perform every related action. The actual system may be authorized only to gather information, identify missing documents, and prepare a recommendation for a human reviewer.

15.3 The Agentic System Architecture

An enterprise agentic system usually contains more components than a model endpoint and a prompt. Its architecture must coordinate interaction, context, planning, tools, execution, control, and monitoring. The user interaction layer receives requests and presents progress, questions, and results. It may be embedded in an enterprise portal, collaboration platform, workflow application, or specialized interface.

The agent runtime manages the execution loop. It coordinates model calls, maintains task state, interprets tool requests, applies policies, and determines whether the task should continue, pause, or complete. The runtime should be designed so that the model proposes actions but the application enforces whether those actions are allowed.

The context layer provides the information needed for the task. This may include enterprise data products, knowledge retrieval, semantic models, user context, and relevant workflow state. Context should be scoped to the user and task, with access controls applied before restricted information is supplied to the model.

The tool layer exposes approved capabilities through APIs, functions, workflow services, or other interfaces. Tools should have clearly defined inputs, outputs, permissions, and error behavior. A tool that reads a customer record has a different risk profile from one that changes the record or initiates a financial transaction.

The policy and control layer enforces authorization, business constraints, approval requirements, and limits on execution. It may include deterministic rules, identity services, transaction controls, and human review. The observability layer records relevant events and supports monitoring, troubleshooting, audit, and evaluation. It should provide traceability across the user request, model decisions, tool invocations, results, approvals, and final outcome, subject to privacy and retention requirements.

These components may be implemented through a combination of platform services and application code. Their separation is an architectural concern: the enterprise must be able to understand and control what the agent can do, regardless of which model or orchestration framework is used.

15.4 Planning, Execution, and the Agent Loop

The agent loop is the repeated process through which an agent interprets a task, selects an action, observes the result, and determines the next step. The exact implementation varies, but a simplified sequence is:

1. Interpret the task and relevant context.
2. Determine whether additional information or an action is required.
3. Select an approved tool or response.
4. Submit the action through the runtime.
5. Receive and validate the result.
6. Continue, request clarification, seek approval, or complete the task.

The loop can support tasks that require adaptation. If a tool returns an error, the agent may choose a permitted alternative or explain that it cannot proceed. If a required attribute is missing, it may ask the user for clarification. If a policy requires approval, it should pause and route the task to the appropriate reviewer.

However, model-driven planning is not inherently reliable. A model may choose an inappropriate tool, misinterpret a result, repeat an action, or continue after the task should have stopped. The runtime should therefore enforce maximum steps, time limits, retry limits, tool allowlists, and other controls.

The system should also distinguish between a proposed action and an executed action. A model may generate a tool request, but the runtime should validate it before execution. The result returned by a tool should be treated as data from an external system, validated against the expected schema and interpreted within the task context.

For critical operations, deterministic workflows may be preferable to open-ended planning. The agent can help interpret the request or prepare information, while a workflow engine controls the sequence of required steps. This hybrid approach preserves flexibility where useful and predictable execution where necessary.

15.5 Tools, APIs, and Enterprise Integration

Tools give an agent the ability to interact with enterprise systems. They may support read operations, search, calculations, document creation, workflow initiation, or controlled updates. Tool design is therefore one of the most important aspects of agentic architecture.

A tool should represent a well-defined business capability rather than expose unrestricted access to an underlying system. For example, an agent may need a tool to retrieve a supplier’s approved onboarding status. It should not necessarily receive a general-purpose database connection or unrestricted access to the supplier management application.

Tool interfaces should use explicit schemas. Inputs should be validated, outputs should be predictable, and errors should be represented in a way that the runtime can handle safely. Tool descriptions should explain the capability and its constraints without encouraging the model to infer permissions that do not exist.

Read and write operations should be separated where possible. Read operations retrieve information; write operations change enterprise state. A write tool should have stronger authorization, validation, and audit requirements. High-impact actions may require approval, dual control, or a separate transaction service.

Idempotency is important when an action might be retried. If a tool creates a case or submits a payment instruction, repeated execution should not accidentally create duplicate business events. The architecture should use idempotency keys, transaction identifiers, or equivalent controls where appropriate.

Tool responses should identify whether an action succeeded, failed, or remains pending. The agent should not report completion simply because it issued a request. It should verify the authoritative result from the downstream system. Integration architecture remains relevant. Agents should use governed APIs, events, and workflow services rather than bypassing established integration controls. This helps preserve security, data quality, observability, and system ownership.

15.6 Agent Memory and Task State

Some agentic systems maintain information across steps or interactions. This is often described as memory, but the term can refer to several different capabilities.

Task state represents the current progress of a specific operation. It may include completed steps, pending approvals, tool results, and unresolved questions. It should be managed by the application or workflow runtime so that the system can recover from interruptions and avoid repeating completed actions.

Conversation context contains information needed to interpret the current interaction. It may include recent messages and references to earlier discussion. Its retention and use should be governed according to the application’s privacy and security requirements.

Persistent memory may retain information across sessions, such as user preferences or previously established context. This requires clear purpose, consent or other appropriate authority, retention rules, and mechanisms to correct or delete information. Persistent memory should not become an ungoverned store of sensitive enterprise data.

Enterprise knowledge is different from agent memory. Policies, product definitions, customer records, and other business facts should generally remain in governed source systems or approved knowledge services. An agent should retrieve such information when needed rather than treating its internal memory as authoritative.

The architecture should define what is stored, where it is stored, who can access it, how it is updated, and how it is deleted. It should also distinguish between verified facts, user-provided statements, model-generated summaries, and inferred information.

15.7 Single-Agent and Multi-Agent Architectures

A single-agent architecture uses one agent runtime to coordinate a task. It may have access to multiple tools and information sources, but one agent is responsible for the overall execution. This pattern is often easier to govern, monitor, and debug than a system with multiple cooperating agents.

A multi-agent architecture divides a task among specialized agents. One agent may interpret the request, another may retrieve information, and another may validate a result. A coordinating agent or workflow service manages the interaction among them.

Specialization can be useful when tasks have distinct knowledge or tool requirements. It can also create additional complexity. Each agent may introduce its own prompts, context, permissions, model calls, and failure modes. Coordination can increase latency and cost, and it may be difficult to determine which component is responsible for an incorrect result.

The use of multiple agents should therefore be justified by a clear architectural need. A set of deterministic services or workflow steps may provide the same separation of responsibilities with more predictable behavior. Multi-agent design is not inherently more capable or more scalable simply because it uses more agents.

If multiple agents are used, the architecture should define their roles, allowed interactions, shared state, communication format, and authority. Agents should not inherit unrestricted permissions from one another. A specialist that can retrieve confidential information should not automatically be able to initiate a business transaction.

15.8 Human-in-the-Loop and Levels of Autonomy

Enterprise agentic systems should be designed around the consequences of their actions. Some tasks can be performed automatically with low risk. Others require confirmation, approval, or human decision-making.

A useful way to think about autonomy is as a continuum rather than a binary distinction between manual and autonomous. At one end, the system provides information or recommendations but takes no action. It may then prepare a proposed action for user confirmation. In more automated designs, it can execute bounded actions under predefined rules. Higher levels of autonomy may involve coordinating multi-step processes, but should be introduced only where the organization can demonstrate adequate controls and accountability.

The appropriate level depends on factors such as reversibility, financial impact, customer impact, regulatory requirements, uncertainty, and the availability of reliable validation. A low-risk task such as drafting an internal summary may require fewer controls than changing a customer record or initiating a payment.

Human approval should be meaningful. The reviewer needs enough context to understand what is being approved, including the proposed action, supporting evidence, relevant constraints, and potential consequences. An approval interface that presents only a generic “Approve” button does not necessarily provide effective oversight.

The architecture should also define what happens when a human rejects an action, requests changes, or does not respond. It should preserve the decision and ensure that the agent does not bypass the approval requirement through an alternative tool or workflow.

Human oversight is not a substitute for technical controls. The system should still enforce permissions, validate inputs, prevent duplicate actions, and record outcomes. Human review is one layer in a broader control architecture.

15.9 Security, Identity, and Authorization

Agentic systems create a complex identity problem. A task may involve the requesting user, the agent application, the model service, a tool gateway, and one or more downstream systems. The architecture must define which identity is used for each action and how authority is propagated.

A broad service identity can simplify integration but may give the agent more access than the requesting user should have. Passing the user’s identity through every component may be more appropriate, but it requires reliable identity federation and authorization support. Some operations may require a combination of user authorization and application-level permissions.

The architecture should distinguish authentication from authorization. Authentication establishes which user or service is making a request. Authorization determines what that identity is allowed to do in the current context. The agent’s generated reasoning should not be treated as an authorization decision.

Least privilege should apply to tools and agents. Each component should have only the permissions required for its defined purpose. Tool access should be constrained by capability, resource, action, and context. A tool that can read customer information should not automatically be able to modify it.

Authorization should be checked at the point of execution, not only when the user begins the conversation. Permissions can change during a long-running task, and the downstream system remains responsible for enforcing its own controls.

The system should also protect secrets and credentials. Credentials should be managed through approved secret-management services and should not be exposed in prompts, logs, or model-visible context. Tool outputs should be screened for sensitive information before they are passed to other components.

15.10 Prompt Injection, Tool Misuse, and Untrusted Inputs

Agentic systems are exposed to instructions from several sources: users, retrieved documents, tool outputs, external content, and application configuration. These sources do not have equal authority. A malicious or misleading instruction embedded in retrieved content should not be allowed to override application policy or expand the agent’s permissions.

Prompt injection is particularly important when an agent can use tools. A retrieved document might contain instructions to send information to an external destination, disclose confidential records, or perform an unrelated action. If the agent treats the document as trusted instruction, it may attempt to misuse its tools.

The architecture should establish a clear separation between instructions and data. Application instructions define the agent’s role and constraints. User requests define the task within those constraints. Retrieved content and tool outputs provide information, but should not independently change the agent’s authority.

This separation should be reinforced through technical controls. Tool allowlists, schema validation, authorization checks, output filtering, restricted network access, and human approval can reduce the impact of unsafe behavior. The model should receive only the context and capabilities required for the task.

Tool misuse can also occur without malicious content. The model may misunderstand a tool description, use an incorrect parameter, or choose an action that is technically valid but inappropriate. Tools should therefore be designed with narrow capabilities and defensive validation.

Testing should include adversarial inputs, conflicting instructions, unexpected tool responses, and attempts to trigger actions outside the defined task. The objective is to assess the complete system, not just the model’s response to a prompt.

15.11 Reliability, Failure Handling, and Recovery

An agentic workflow can fail at multiple points. A model call may time out, a tool may be unavailable, an API may return unexpected data, a permission check may fail, or a human approval may remain pending. The architecture must make these conditions explicit and define safe recovery behavior.

Retries should be limited and appropriate to the operation. Retrying a read request may be harmless, while retrying a non-idempotent write could create duplicate actions. The runtime should understand whether a tool operation is safe to retry and should use idempotency mechanisms where necessary.

Long-running tasks require durable state. If a process is interrupted, the system should be able to determine which steps completed, which remain pending, and whether an action may already have occurred. It should not rely exclusively on conversational history to reconstruct business state.

Compensation may be required when a multi-step process partially completes. For example, if a workflow creates a case and then fails to attach a document, the system may need to retry the attachment, cancel the case, or route the task for human intervention. The appropriate response depends on the business process and should be designed explicitly.

Agents should have stopping conditions. These may include reaching the task objective, exhausting permitted steps, encountering insufficient evidence, receiving a policy denial, or requiring human judgment. Without defined stopping conditions, an agent may continue attempting variations of the same action.

The architecture should favor safe failure. If the system cannot establish whether an action succeeded, it should not claim success or blindly repeat the action. It should verify the result through the authoritative service or escalate the uncertainty.

15.12 Evaluation and Testing of Agentic Systems

Evaluating an agent requires more than assessing the quality of its generated text. The system must be evaluated on whether it understood the task, selected appropriate tools, used them correctly, respected authorization, handled errors, and achieved the intended outcome.

Task-level evaluation examines whether the agent completed the requested business objective. Tool-level evaluation examines whether the correct tools were selected and invoked with valid parameters. Control evaluation examines whether the system followed permissions, approval requirements, and policy constraints. Reliability evaluation examines whether it handled failures and interruptions safely.

Test scenarios should include routine tasks, ambiguous requests, incomplete information, conflicting evidence, denied permissions, unavailable tools, unexpected tool responses, and requests outside the agent’s scope. Tests should also examine whether the agent stops when it should. Evaluation should use realistic enterprise conditions. A demonstration with clean data and predictable tool responses may not reflect production behavior. Test environments should include representative data quality issues, latency, authorization boundaries, and failure conditions.

Human review is important for outcomes that require domain judgment. However, human evaluation should be supported by clear criteria. Reviewers should assess not only whether the final response appears reasonable, but whether the agent used appropriate evidence and followed the required process.

Regression testing is necessary whenever prompts, models, tools, policies, or workflows change. A change that improves task completion may also affect security or reliability. Evaluation should therefore cover multiple dimensions rather than optimizing a single success metric.

15.13 Observability, Auditability, and Accountability

Agentic systems need end-to-end observability because their behavior is distributed across model calls, tools, workflows, and human decisions. A final answer alone may not explain how the system reached its result or whether the required controls were applied.

A useful trace can include the initiating request, relevant identity and authorization context, agent and prompt versions, tool requests, tool results, approval events, errors, and final outcome. The exact level of detail should be determined by the use case, privacy requirements, and audit obligations.

Logging should be designed carefully. Prompts, tool outputs, and retrieved information may contain confidential or regulated content. The organization should define what is recorded, how sensitive fields are protected, how long records are retained, and which roles may access them.

Auditability also requires a clear distinction between model-generated content and authoritative system events. A model statement that a transaction was completed is not proof that the transaction occurred. The authoritative system should provide the result, and the agent should report it accurately.

Accountability must be assigned across the lifecycle. Business owners are responsible for the process and its outcomes; application owners are responsible for the system; platform teams provide shared capabilities; security and risk teams define relevant controls; and data owners govern the information used by the agent. These responsibilities should be documented rather than assumed.

15.14 Agentic AI and Enterprise Operating Models

Agentic AI introduces responsibilities that cross traditional organizational boundaries. AI engineering, data engineering, application teams, enterprise architecture, security, risk, legal, operations, and business process owners may all contribute to one solution.

A centralized team can provide shared agent runtimes, model access, tool gateways, evaluation frameworks, identity integration, and monitoring. Domain teams can then develop agents for specific business processes using approved capabilities. This model can reduce duplication while preserving domain accountability.

The operating model should define who can create an agent, approve its tools, classify its risk, release it to production, monitor its behavior, and retire it. It should also define how changes to models, prompts, tools, and source data are reviewed.

Reusable platform capabilities are especially important. If every team independently implements authorization, logging, retrieval, and approval handling, the enterprise may develop inconsistent controls. A shared platform can provide standard mechanisms while allowing domain-specific workflows and policies. However, centralization should not remove business ownership. A platform team cannot determine every business rule or decide whether a particular action is acceptable in a specific process. Domain owners must remain accountable for the tasks their agents perform.

The operating model should also address workforce impact and process redesign. An agent may change how work is distributed between employees, applications, and automated services. Organizations should define how exceptions are handled, how employees review agent work, and how process performance is measured.

Case study: Meridian Financial Group

15.15 Agentic AI at Meridian Financial Group

Meridian Financial Group is a fictional global financial services organization exploring agentic AI to support internal operations. Its first use case focuses on preparing an onboarding review package for a new corporate customer. The process requires information from customer systems, document repositories, product procedures, and internal control guidance.

Meridian does not begin with an autonomous agent authorized to approve onboarding. Instead, it defines a bounded assistant that can gather approved information, identify missing evidence, prepare a structured summary, and route the package to an authorized reviewer.

The agent runtime receives the employee’s request and establishes the task context. It identifies the relevant customer using an approved lookup service, retrieves authorized customer and onboarding information, and searches the governed knowledge repository for applicable procedures. Semantic metadata helps distinguish corporate customer concepts from related legal-entity and account concepts.

The agent has access to a limited set of tools. Read tools retrieve approved information. A document preparation tool creates a draft review package. A workflow tool submits the package for human review, but only after the required fields and evidence checks have been completed. The agent does not have a tool that independently approves the onboarding decision.

The runtime enforces user permissions and validates tool requests. If the employee lacks access to a customer record, the retrieval service does not return it. If required information is missing, the agent asks for clarification or identifies the gap. If a source is unavailable, the system reports that limitation rather than filling the gap with generated assumptions.

Meridian also introduces explicit approval controls. The reviewer sees the proposed summary, supporting source references, missing items, and any unresolved inconsistencies. The workflow records the reviewer’s decision in the authoritative process system. The agent reports the outcome only after verifying the workflow result.

During testing, Meridian identifies a potential duplicate-submission problem. A retry after a timeout could submit the same review package more than once. The team adds an idempotency mechanism and a status check so the agent can determine whether the original submission succeeded before attempting another action.

The organization tests the agent against scenarios involving incomplete documents, conflicting customer identifiers, denied access, unavailable services, and misleading instructions embedded in retrieved content. It also tests whether the agent stays within its defined scope and avoids presenting a draft as an approved decision.

Meridian establishes shared platform services for identity, tool execution, audit logging, evaluation, and human approval. The onboarding domain team owns the business process and the agent’s permitted tasks. The platform team operates the reusable runtime, while security and risk teams review the control design.

The resulting architecture uses agentic capabilities to coordinate work without transferring decision authority to the model. It demonstrates how an enterprise can introduce bounded autonomy while preserving established systems of record, human accountability, and process controls.

15.16 Practical Artifact: Enterprise Agentic AI Architecture Assessment

This assessment can be used during discovery, architecture review, or production readiness. It is intended to help teams make autonomy, authority, and operational responsibilities explicit.

The assessment should produce explicit decisions about the agent’s authority, its permitted tools, required approvals, and the conditions under which it must stop. These decisions should be reflected in both architecture documentation and executable controls.

Remember these

15.17 Key Takeaways

1. Agentic AI extends generative AI from producing responses toward coordinating actions across tools, services, and workflows. The degree of autonomy should be defined by task, risk, and business authority rather than by the label “agent.”
2. The agent is a system, not just a model. Its architecture includes a runtime, context services, tools, identity, authorization, policy enforcement, state management, observability, and human oversight.
3. Tools should expose narrow, governed business capabilities. Read and write operations should be distinguished, and high-impact actions should have appropriate validation, approval, and audit controls.
4. Model-driven planning provides flexibility but introduces uncertainty. Deterministic workflows, explicit stopping conditions, bounded execution, and safe failure handling are essential for predictable enterprise behavior.
5. Memory and task state require governance. Enterprise facts should remain in authoritative systems or governed knowledge services rather than becoming uncontrolled agent memory.
6. Multi-agent architectures can support specialization, but they also increase complexity, latency, cost, and coordination risk. They should be used when a clear need justifies the additional components.
7. Security must be enforced by the application and downstream systems. Prompts and model reasoning do not replace authentication, authorization, least privilege, transaction controls, or business policy.
8. Evaluation must cover task outcomes, tool selection, control adherence, reliability, and security. A plausible final response is not sufficient evidence that the agent performed the task correctly.
9. Enterprise agentic AI requires a cross-functional operating model. Shared platform capabilities should coexist with clear domain ownership and accountability for business outcomes.

Think about your own organization

Architect’s Reflection

An agent that can act changes the nature of an AI architecture. A generated answer can mislead; an executed action can also alter enterprise state, initiate a process, or affect a customer. The design must therefore make authority as explicit as capability.

The architect should resist the temptation to equate autonomy with sophistication. In many enterprise situations, the most appropriate system is one that gathers information, prepares a proposal, and routes it to a person or deterministic workflow. In other situations, bounded automation may be suitable. The decision depends on the task, consequences, controls, and evidence that the system behaves as intended.

The deeper architectural question is not how many tasks an agent can perform. It is whether the organization can explain what the agent is allowed to do, why it is allowed to do it, how each action is verified, and who remains accountable for the outcome.

As enterprises adopt agentic systems, the role of the data architect expands beyond enabling access to information. It includes helping ensure that agents operate with trusted context, governed interfaces, and a clear understanding of the enterprise boundaries within which they must work.