AI Agents vs Agentic AI: Architecture, Autonomy, and Real-World Engineering
Artificial intelligence is moving beyond systems that simply generate responses. Modern AI applications can coordinate tools, maintain execution state, evaluate results, and carry out multi-step tasks. But an AI agent and an agentic AI system are not necessarily the same architectural concept.
Understanding the distinction matters when designing reliable enterprise applications. The engineering challenge is not just making a model more capable; it is deciding how much autonomy to grant, which operations to permit, when humans must intervene, and how execution can be observed and controlled.
The terms AI agent and agentic AI are often used interchangeably. They are closely related, and their definitions vary across vendors and research communities. However, a useful engineering distinction separates the individual acting component from the broader application architecture and behavior that supports goal-directed execution.
An AI agent can be understood as a software component that receives a task, uses available context, selects actions, and works toward an objective. Agentic AI describes systems exhibiting goal-directed, adaptive behavior through planning, tool use, feedback, and controlled execution. Such systems may contain one agent, several agents, or a combination of agents and deterministic services.
From Individual Agents to Agentic Systems
AI Agent
A bounded software actor that interprets instructions, selects permitted actions, and works toward a defined objective.
Agentic AI System
An application that coordinates reasoning, actions, feedback, policies, and state to pursue objectives over multiple steps.
What Changes When AI Becomes Agentic?
Consider a network operations request: “Investigate why application traffic is experiencing intermittent packet loss.” A conventional language-model interface might describe likely causes and suggest diagnostic commands. An appropriately equipped agent could instead request telemetry, inspect interface counters, compare observations, and recommend the next investigation step.
A production agentic application adds another layer of engineering discipline. It must control which telemetry is accessible, enforce read-only investigation permissions, record tool results, handle unavailable services, and require approval before potentially disruptive changes.
A simplified conceptual flow. Real systems may repeat steps, branch, request human approval, or terminate when safety or execution limits are reached.
Why This Distinction Matters to Engineers
Agentic AI introduces architectural decisions familiar to network, cloud, security, and distributed-systems engineers. Every tool call crosses a trust boundary. Every external dependency can fail. Every long-running task requires state, timeout handling, and termination conditions. Every autonomous action must have an appropriate authorization model.
The practical question is therefore not simply whether an application uses AI agents. It is which decisions the system can make, which actions it can execute, how its behavior is constrained, and how operators regain control when something goes wrong.
What You Will Learn
This guide progresses from individual agent responsibilities to autonomy models, enterprise deployment boundaries, and practical architecture selection.
Engineering Perspective
Throughout the article, we will examine agentic AI using practical engineering principles: separation of responsibilities, least privilege, observable execution, explicit failure handling, and bounded autonomy.
Interactive examples will focus on autonomy decisions, responsibility boundaries, approval gates, and architecture trade-offs, complementing rather than duplicating our existing Agentic AI Architecture guide.
Explore the Architecture
Nine connected engineering chapters. Follow the journey from individual AI agents to adaptive systems, enterprise deployment, governance, and architecture selection. Select any node to jump directly to that section.
AI Agents vs Agentic AI: Understanding the Core Differences
The distinction between an AI agent and an agentic AI system is best understood through engineering boundaries. An agent is an acting component. Agentic AI describes goal-directed, adaptive system behavior supported by runtime controls, tools, state, and execution policies.
AI terminology is evolving rapidly. Different vendors use AI agent, AI assistant, and agentic AI in overlapping ways. There is no single universally enforced architectural definition that separates them. However, a component-versus-system distinction is useful when designing production applications.
An AI agent is typically a software actor that interprets a task, selects permitted operations, and uses available context to pursue a goal. It may operate as an isolated service, an embedded application component, or a worker controlled by an orchestrator.
Agentic AI refers to AI-enabled systems capable of pursuing objectives through multiple decisions and actions, using feedback to adjust execution. These systems may contain a single agent or multiple cooperating agents, together with conventional services and deterministic workflow logic.
1.1 The Component and the System
The most useful way to distinguish these concepts is to examine their responsibility boundaries. An individual agent can decide which permitted tool to use next, but a production application must also manage authentication, authorization, workflow state, retries, logging, and human approval.
The AI Agent
Agent
The agent's immediate responsibility is choosing actions that advance its assigned objective. Its available tools, context, and execution permissions define what it can actually do.
The Agentic AI Application
Runtime
The wider system coordinates agents and services, enforces permissions, records execution history, handles failures, and manages the transition from a requested goal to a verified outcome.
1.2 A Technical Comparison
The table below describes a useful design distinction rather than two mutually exclusive product categories. In practice, a sophisticated agent may include several capabilities shown at the system level, while an agentic platform may delegate them to separate services.
| Dimension | AI Agent | Agentic AI System |
|---|---|---|
| Primary focus | Completing an assigned task | Managing goal-directed execution across an application |
| Scope | Individual actor or worker | End-to-end workflow and supporting services |
| Decision-making | Selects actions within available context and permissions | Coordinates decisions, control gates, and execution boundaries |
| Tools | Invokes assigned tools or requests actions | Provides tool integration, credentials, authorization, and execution handling |
| State | May maintain local task context | May maintain durable workflow state, history, and checkpoints |
| Autonomy | Bounded by its configured responsibilities | Defines system-wide autonomy and human oversight |
| Failure handling | May retry, report failure, or request assistance | Coordinates retries, escalation, cancellation, and recovery |
| Observability | Produces local decisions and tool records | Correlates traces, metrics, policy events, and outcomes |
| Deployment | Can be embedded or deployed as a service | May span multiple services, agents, APIs, and infrastructure components |
1.3 Where Responsibility Changes
In a production design, the most important question is not whether the application has an agent. It is which component owns each responsibility. Clear boundaries make agentic systems easier to test, secure, monitor, and recover.
Decision Boundary
What may the agent decide independently, and which decisions must be delegated to deterministic controls?
Execution Boundary
Which actions can actually be executed, under which identity, and with what resource restrictions?
State Boundary
Where are task state, observations, checkpoints, and previous results retained?
Control Boundary
Who can approve, interrupt, retry, or terminate execution when conditions change?
1.4 Real-World Engineering Example
Consider a network operations team investigating intermittent packet loss across a data centre leaf-spine fabric. The operator asks: "Determine whether congestion is contributing to packet loss on the affected network path."
One Investigation — Two Architectural Scopes
Individual AI Agent
The agent receives the investigation request and uses its authorized read-only telemetry tools to retrieve interface counters and queue statistics. It evaluates the observations and reports whether they support a congestion hypothesis. Its responsibility ends at the assigned diagnostic boundary.
Agentic AI System
The surrounding application authenticates the operator, supplies authorized tools, tracks the investigation, correlates evidence, handles unavailable telemetry, and stores an audit trail. If a proposed remediation could disrupt traffic, the system routes that action through a human approval process.
Both implementations may use the same underlying language model. The difference lies in the architectural responsibilities around it. A model does not inherently possess access to live network telemetry, administrative privileges, or durable workflow state. Those capabilities must be explicitly provided and governed by the application.
The same distinction applies to cloud operations, security investigations, software development, customer support, and enterprise automation. As the number of tools, dependencies, and possible actions grows, the importance of explicit system boundaries increases.
1.5 Why More Agents Does Not Mean More Agentic
A common misconception is that an application becomes agentic simply by adding more agents. Multiple agents can be useful when tasks benefit from specialization, parallel execution, or independent review. But a single well-designed agent can exhibit sophisticated goal-directed behavior, while a collection of agents can still operate through a rigid, predetermined sequence.
Agent count is therefore an architectural choice, not a measurement of autonomy. Engineers should evaluate the degree of decision-making, adaptability, tool access, feedback handling, and operational control rather than relying on the number of cooperating components.
Section 01 — Engineering Takeaway
Think of an AI agent as an acting component with defined responsibilities. Think of agentic AI as goal-directed system behavior enabled by agents, tools, runtime controls, state, and feedback. The two concepts overlap, but separating component responsibilities from system responsibilities creates clearer, safer, and more maintainable architectures.
From AI Responses to Autonomous Systems
Not every AI application is an autonomous agent. Explore how execution architecture changes when a model gains tools, decision loops, and the ability to coordinate multiple actions toward a goal.
Execution Architecture
Prompt / ResponseArchitecture Profile
ReadySelect Run Execution to follow the request through the architecture.
Engineering Insight
Anatomy of an AI Agent: Model, Instructions, Context, Tools, and Execution Responsibilities
An AI agent is not simply a language model with a new label. It is a software component that combines a decision mechanism with task instructions, contextual information, permitted capabilities, and an execution interface. Understanding these boundaries is essential before designing larger agentic systems.
Modern AI agents are commonly implemented using large language models, but the model is only one part of the component. The surrounding software determines what information the agent receives, which tools it can request, how its outputs are interpreted, and whether an action is actually permitted to execute.
A useful engineering model separates the agent into six responsibilities: decision-making, instructions, task context, capability access, execution handling, and output contracts. These responsibilities may be implemented within one process or distributed across supporting services.
2.1 The Internal Structure of an AI Agent
The following diagram presents the agent as a bounded software component. Its internal decision mechanism is supported by instructions and context, while tool adapters and output validation connect it to the surrounding application.
Instructions
Role, objectives, constraints, and expected behavior.
Task Context
Current request, relevant data, and observations.
Tool Interface
Declared capabilities and structured action requests.
Output Contract
Structured results, evidence, status, and escalation.
Conceptual responsibility model. Authentication, policy enforcement, durable state, and tool execution may be owned by the surrounding runtime.
2.2 The Decision Mechanism
The decision mechanism interprets the current task and available context to produce a response or select a possible next action. In an LLM-based agent, this commonly involves model inference over instructions, observations, and tool descriptions.
The model can suggest a diagnostic step, identify a relevant tool, or produce structured arguments for a tool request. However, it does not automatically know whether those arguments are valid, whether the target resource exists, or whether the requesting identity has permission to perform the action.
This separation is particularly important for infrastructure engineering. An agent may propose checking an interface or changing a routing policy, but the execution layer must distinguish read-only inspection from operations that could affect production traffic.
2.3 Instructions and Task Context
Agent instructions define the purpose and boundaries of the component. For example, a network investigation agent may be instructed to gather evidence, explain findings, and recommend remediation without making configuration changes.
Task context supplies the information required for a specific request. This may include the affected device, incident identifier, topology metadata, permitted diagnostic scope, and previously collected observations. Context is not necessarily persistent memory; it can be temporary information assembled for one execution.
Good agent design keeps instructions separate from untrusted observations. A log entry, retrieved document, or tool response should be treated as data rather than as a new authority capable of overriding system policy.
2.4 Tool Interfaces and Execution Ownership
Tools extend an agent beyond text generation. A tool might retrieve network telemetry, query an inventory service, inspect a cloud resource, or create a structured incident report. The tool interface describes what operations are available and which arguments they accept.
A well-designed execution adapter validates arguments, enforces access controls, invokes the actual service, and returns a structured result. The agent then uses that result as evidence for subsequent decisions.
Tool descriptions and model prompts can guide behavior, but they must not be the only enforcement mechanism. Authorization should be performed by trusted application components using the relevant user, service, or workload identity.
2.5 Three Essential Agent Contracts
Input Contract
Defines the accepted task, required parameters, relevant context, and execution scope. Clear input contracts reduce ambiguity and improve testing.
Capability Contract
Defines which tools and actions the agent can request, what arguments are valid, and which permissions apply.
Output Contract
Defines the expected result format, evidence references, execution status, uncertainty, and escalation requirements.
2.6 Responsibility Ownership in Practice
A useful design exercise is to assign each capability to the component that should own it. The agent can make contextual decisions, but critical security and operational controls should not depend on model compliance alone.
| Responsibility | Typical Owner | Engineering Requirement |
|---|---|---|
| Task interpretation | Agent decision mechanism | Understand objective and identify missing context |
| Action proposal | Agent decision mechanism | Select an available action and construct arguments |
| Argument validation | Trusted runtime or tool adapter | Reject malformed or unsupported requests |
| Authentication | Application identity infrastructure | Establish the requesting principal |
| Authorization | Trusted policy enforcement point | Permit or deny actions against resources |
| External execution | Tool adapter or backend service | Perform the operation and report actual results |
| Result interpretation | Agent decision mechanism | Evaluate observations and communicate uncertainty |
| Audit and telemetry | Application runtime and observability services | Record decisions, tool calls, outcomes, and policy events |
2.7 Network Engineering Example: A Diagnostic Agent
Imagine an agent assigned to investigate a BGP route that has disappeared from a routing table. Its responsibility is to gather diagnostic evidence, not to modify routing policy.
A Bounded Read-Only Troubleshooting Agent
Task Definition
Investigate why prefix 10.20.30.0/24 is absent from the expected routing table on router R1.
Permitted Tools
Read BGP neighbor state, inspect received routes, retrieve local routing information, and query relevant policy metadata.
Restricted Operations
No configuration writes, BGP session resets, route injection, or policy changes. Remediation requires a separate authorized workflow.
Diagnostic Report
Return observations, evidence references, possible causes, confidence limitations, and recommended next checks.
This design creates a useful operational boundary. The agent can inspect the network and assist an engineer without receiving privileges that allow it to disrupt production routing.
If the investigation identifies a likely policy error, the agent can propose a change for review. The approval and execution of that change belong to a separate, trusted control process.
2.8 What an Agent Should Not Own
Some responsibilities should remain outside the model's decision authority. Examples include granting itself permissions, bypassing approval requirements, altering audit records, or declaring an external operation successful without verification.
Keeping these functions in deterministic application components improves reliability and makes the system easier to inspect. It also allows the same agent to operate safely across different environments with different authorization rules.
Section 02 — Engineering Takeaway
A production AI agent combines a decision mechanism with explicit instructions, task context, capability interfaces, and output contracts. The agent may select actions, but trusted software must validate requests, enforce permissions, execute operations, and verify results. Clear responsibility boundaries are the foundation of safe, maintainable agentic applications.
Inside an AI Agent: Architecture Explorer
Explore the internal components of a tool-enabled AI agent. Select any component to inspect its engineering responsibility, enable or disable optional capabilities, and trace a simulated BGP troubleshooting request through the architecture.
Interactive Component Map
Component Inspector
Agent Orchestrator
Architecture Configuration
Run the request to observe internal component interactions.
Engineering Insight
The language model provides reasoning, but the surrounding runtime provides controlled execution. An agent architecture must define which tools exist, which actions are permitted, how observations are processed and when execution stops.
What Makes a System Agentic? Goals, Adaptability, Feedback, and Execution Boundaries
Agentic behavior is not defined by the number of AI models or agents in an application. It emerges when a system can pursue an objective through context-dependent decisions, permitted actions, and feedback-driven adaptation. The engineering challenge is to provide those capabilities without surrendering operational control.
Many applications now use language models to summarize information, classify requests, or generate recommendations. These functions can be valuable, but they do not necessarily make the application agentic. A system that always follows the same predefined sequence may remain a deterministic workflow even when an LLM participates in individual steps.
A more agentic design delegates some decision-making to an AI-enabled component. The system may select between available actions, gather additional evidence when information is missing, adjust its approach after a failed operation, or stop when a defined objective has been satisfied.
3.1 Five Characteristics of Agentic Behavior
A useful engineering model examines five related characteristics: goal orientation, decision authority, environmental observation, adaptability, and bounded execution. These characteristics form a spectrum rather than a rigid certification checklist.
Goal Orientation
Works toward an intended outcome
Decision Authority
Selects among permitted actions
Observation
Uses evidence from its environment
Behavior
Adaptability
Changes approach using feedback
Bounded Execution
Operates within explicit constraints
Operational Evidence
Supports verification and review
A conceptual capability model. Observability and policy enforcement are essential production controls, not proof of autonomy by themselves.
3.2 Goal Orientation Versus Fixed Instructions
Traditional automation generally defines both the objective and the sequence of operations. A script might collect interface counters, evaluate a fixed threshold, and generate an alert. The execution path is determined by the programmer.
A goal-oriented agent may instead receive an objective such as "Determine whether congestion is contributing to packet loss." It can then choose among authorized diagnostic operations based on the available evidence.
The distinction is not that automation cannot contain conditional logic. Conventional programs can be highly adaptive. The agentic difference is that some selection of actions is delegated to an AI decision mechanism rather than fully encoded as a predetermined control path.
3.3 Decision Authority Is the Defining Boundary
Decision authority describes what the application allows an agent to determine without asking a human or following a fixed instruction for every step.
An agent might be permitted to select diagnostic tools, determine which observation to collect next, and decide when enough evidence exists to prepare a report. It may not be permitted to modify firewall rules, restart routing sessions, or deploy production configuration.
These boundaries should be enforced by trusted software rather than relying on natural-language instructions alone.
What Can It Decide?
The set of choices delegated to the AI component, such as diagnostic order, information requests, or next-step selection.
What Can It Execute?
The operations authorized by the application, identity system, and resource-specific policy.
When Must It Stop?
Termination rules covering successful completion, failure, uncertainty, budget exhaustion, and mandatory human escalation.
3.4 Feedback and Adaptation
Feedback enables an agent to adjust its decisions based on observed outcomes. If a telemetry service returns an error, the agent may choose an approved alternative data source or report that the investigation cannot continue.
If interface counters show no significant discards, an agent might examine another plausible failure domain rather than repeating the same query. The system can adapt its investigation while preserving the original objective.
Adaptation should not be confused with unlimited retrying. A reliable application needs timeouts, maximum action counts, retry budgets, and explicit conditions for stopping or escalating.
3.5 Automation, LLM Applications, and Agentic AI
These approaches are not mutually exclusive. A production architecture may combine deterministic workflows, LLM-based interpretation, and agent-directed investigation. The right approach depends on the task's variability, risk, and operational requirements.
| Dimension | Deterministic Automation | LLM Application | Agentic AI Application |
|---|---|---|---|
| Execution path | Defined by programmed logic | Often follows a fixed request-response path | May select actions dynamically within constraints |
| Decision mechanism | Rules, algorithms, and explicit conditions | Model inference for a bounded task | Model-assisted selection across multiple permitted steps |
| Tool access | Directly programmed integrations | Optional application integrations | Typically uses tools to observe or act |
| Adaptation | Limited to implemented logic | May adapt the generated response | May change the execution approach based on feedback |
| State | Defined application variables and storage | Often request or conversation context | May maintain evolving task and workflow state |
| Best fit | Stable, repeatable operations | Generation, summarization, and interpretation | Variable multi-step tasks requiring contextual decisions |
3.6 Bounded Autonomy Is an Engineering Requirement
Greater autonomy increases the importance of control. An agent that can select diagnostic queries creates less operational risk than an agent permitted to modify production infrastructure.
Engineers should separate decision autonomy from execution authority. A system may allow an agent to recommend a configuration change while reserving actual deployment for a human-approved automation pipeline.
This design preserves the benefits of AI-assisted investigation without granting unrestricted administrative capabilities.
3.7 Network Engineering Example: Adaptive Investigation
Consider a network operations request involving intermittent application latency between two data centre services. The objective is to identify plausible contributing factors using authorized telemetry.
Three Approaches to the Same Investigation
Fixed Automation
Collect predefined counters, compare them with configured thresholds, and generate a report using programmed decision rules.
LLM-Assisted Analysis
Analyze supplied logs and metrics, summarize possible causes, and suggest further checks without independently controlling the investigation.
Agentic Investigation
Select authorized telemetry queries, interpret observations, pursue relevant diagnostic branches, and stop with an evidence-based report or escalation request.
The agentic approach is not automatically the best option. If the investigation is completely predictable, deterministic automation may be simpler, faster, and easier to validate. Agentic behavior becomes more useful when the appropriate next step depends on incomplete or changing evidence.
3.8 Measuring Agentic Capability
Engineers should avoid treating autonomy as a binary label. A system may have substantial freedom to choose diagnostic queries but no authority to execute changes. Another system may run a fixed deployment workflow with powerful credentials but very little delegated decision-making.
A practical assessment should examine which decisions are delegated, how much task context the system can use, how it responds to unexpected observations, and whether its actions remain constrained and auditable.
Section 03 — Engineering Takeaway
Agentic behavior emerges when an AI-enabled system can pursue goals through delegated decisions, environmental observations, and feedback-driven adaptation. The number of agents is not the defining factor. The most important engineering decision is how to balance adaptive behavior with explicit authorization, termination, and human oversight.
Agent Planning & Reasoning Loop Visualiser
An agent must do more than execute a fixed sequence. Explore how it creates a plan, collects evidence, evaluates its hypothesis and replans when observations contradict its initial assumptions.
Reasoning & Planning Cycle
READYActive Agent Hypothesis
Decision Trace
Select Run Investigation to begin.
Investigation Event Timeline
No events recorded yet.
Engineering Insight
Effective agent planning requires an observation-driven control loop. A reliable system must distinguish between a proposed hypothesis, evidence supporting that hypothesis, and a verified diagnosis.
Levels of Autonomy and Human Oversight: Designing Safe Decision and Approval Boundaries
Autonomy is not a binary property. An AI system may be allowed to recommend actions, select diagnostic tools, execute low-risk operations, or manage longer workflows. Each increase in authority changes the security, reliability, and governance requirements of the application.
A common misconception is that the most advanced agentic AI system is the one requiring the least human involvement. In enterprise engineering, the objective is different: assign enough autonomy to complete useful work while preserving appropriate control over risk.
A network investigation agent may independently collect telemetry and prepare a diagnostic report. The same agent should not automatically receive permission to restart routing sessions, modify firewall rules, or deploy production changes.
Designing this separation requires engineers to distinguish between the ability to make a decision and the authority to execute the resulting action.
4.1 A Five-Level Autonomy Framework
The following framework provides a practical way to discuss autonomy during architecture reviews. These levels are illustrative engineering categories rather than a universal industry standard.
Human Directed
The system provides information while humans select and execute actions.
Recommendation
AI proposes actions, but humans determine what happens next.
Bounded Action
AI selects and performs pre-authorized, low-risk operations.
Approval-Gated
AI manages a workflow, but sensitive operations require explicit approval.
Policy-Constrained
AI can complete broader workflows autonomously within enforced limits.
Greater delegation does not imply greater suitability. Approval gates can exist at any autonomy level.
4.2 Human-in-the-Loop and Human-on-the-Loop
Human oversight can be implemented in several ways. In a human-in-the-loop design, execution pauses until an authorized person approves a particular action.
In a human-on-the-loop design, the system operates within predefined limits while humans monitor its behavior and retain the ability to intervene or stop execution.
Human-out-of-the-loop execution may be appropriate for tightly bounded, low-risk operations, but still requires enforceable policies, monitoring, and recovery mechanisms.
4.3 The Approval Boundary Architecture
A robust approval system does more than ask a user to click a confirmation button. It binds authorization to a specific proposed operation, target resource, parameters, and execution context.
Approval does not replace authorization. The execution service must independently validate the approved action before performing it.
4.4 What Must Be Included in an Approval Request?
A meaningful approval request should describe the operation precisely enough for an engineer to understand its potential impact. Generic requests such as "Allow the agent to fix the network" are too broad for sensitive infrastructure operations.
Action and Target
Identify the exact operation, affected resource, and relevant parameters.
Evidence and Impact
Present the diagnostic evidence, expected outcome, and potential service impact.
Approval Scope
Bind the approval to the specific action, authorized identity, and validity period.
Verification and Recovery
Define post-action checks, rollback conditions, and audit requirements.
4.5 Autonomy Controls by Operation Type
Different actions require different levels of control. A read-only telemetry query is not equivalent to changing production routing policy, even when both are requested by the same agent.
| Operation | Typical Risk | Illustrative Control | Human Involvement |
|---|---|---|---|
| Read interface counters | Low, subject to data sensitivity | Read-only authorization and audit | Usually not required per query |
| Retrieve routing state | Low to moderate | Scoped device and command permissions | Usually not required per query |
| Create incident report | Low to moderate | Output validation and evidence references | Review may be appropriate |
| Modify monitoring thresholds | Moderate | Change validation and scoped authorization | May require approval |
| Restart BGP session | Potentially high | Impact assessment and change controls | Normally explicit approval |
| Deploy routing policy | Potentially high | Review, prechecks, staged deployment, rollback | Normally explicit approval |
| Change security rules | Potentially high | Least privilege, policy validation, audit | Normally explicit approval |
4.6 Why Approval Must Be Enforced Outside the Model
Natural-language instructions can tell an agent to request approval before performing sensitive operations. However, those instructions are not sufficient as a security boundary.
A trusted execution service should reject unauthorized operations regardless of what the model requests. Approval decisions should be associated with authenticated identities and recorded in an auditable form.
Engineers must also consider time-of-check versus time-of-use problems. If the target configuration changes after approval, the system may need to invalidate the approval and request a new review.
4.7 Network Engineering Scenario: BGP Remediation
Consider an agent investigating a missing BGP route. The investigation identifies evidence suggesting that an outbound route-map is filtering a required prefix.
Separating Investigation, Approval, and Execution
Agent Investigation
The agent collects BGP neighbor state, advertised routes, and policy information. It prepares an evidence-based diagnosis and proposed remediation.
Human Approval
An authorized engineer reviews the proposed route-map modification, validates expected routing impact, and approves a specific change request.
Controlled Execution
A trusted automation service validates the approval, performs prechecks, applies the change, verifies routing behavior, and records the outcome.
The agent may have considerable freedom to investigate and recommend a solution without possessing direct permission to change production routing. This separation reduces the consequences of an incorrect diagnosis or an unexpected model-generated action.
4.8 Emergency Stops, Budgets, and Escalation
Approval gates are only one part of autonomy control. Production systems should also support cancellation, maximum execution duration, tool-call budgets, retry limits, and escalation when required evidence is unavailable.
Human intervention must be operationally meaningful. An operator should be able to identify the active workflow, inspect its current state, and prevent further actions. Cancellation cannot always reverse operations already committed, so recovery planning remains essential.
Section 04 — Engineering Takeaway
Safe agentic AI does not require eliminating human involvement. It requires assigning appropriate decision authority, enforcing execution permissions, and placing approval boundaries around sensitive operations. The strongest designs combine bounded autonomy, trusted policy enforcement, auditable approvals, operational stop controls, and verified outcomes.
MCP Tool Calling & Execution Gateway
Follow a model-proposed tool call through an MCP client, server and external network API. Experiment with tool permissions, schema validation and simulated execution failures to understand the boundary between AI reasoning and authorised action.
MCP Communication Architecture
READYTool Request Builder
Configure a request and execute the simulated tool call.
Protocol & Execution Timeline
No protocol events recorded.
Engineering Insight
MCP standardises how host applications communicate with external context and tool providers. It does not automatically make a tool safe. Hosts and servers still need appropriate permissions, input validation, approval policies and auditing.
Single-Agent vs Agentic Workflows: Complexity, Coordination, and Architectural Trade-offs
Not every AI application requires a complex orchestration platform. A single agent may be sufficient for a bounded task, while longer-running processes may benefit from workflow state, explicit control gates, deterministic services, and coordinated execution. The correct architecture depends on the task—not the number of agents.
Agentic AI systems are sometimes described as networks of specialized agents that communicate and collaborate. Such architectures can be useful, but they are not a prerequisite for agentic behavior. A single agent can select tools, evaluate observations, and adapt its approach to a task.
Conversely, a workflow can coordinate several AI components without granting them much decision autonomy. A fixed pipeline that invokes three models in sequence is not necessarily more agentic than one agent operating independently.
5.1 The Single-Agent Architecture
A single-agent design gives one acting component responsibility for a bounded objective. It receives context, selects permitted actions, interprets results, and returns an outcome to the calling application.
This approach works well when the task has a manageable scope, limited dependencies, and a relatively small number of tools. Examples include retrieving operational data, summarizing an incident, or conducting a focused diagnostic investigation.
5.2 The Structured Agentic Workflow
A structured workflow introduces explicit coordination around the AI component. The application may manage task state, invoke deterministic services, enforce approval gates, and preserve progress across multiple steps.
The workflow may contain one agent or several. The important distinction is that execution is managed by an application architecture rather than relying on one component to own every responsibility.
Single-Agent Design
Managed Agentic Workflow
Conceptual architecture comparison. A single-agent implementation can also use external policy, state, and observability services.
5.3 When a Single Agent Is Enough
A single agent is often the best starting point when one component can understand the task, access the required tools, and produce a verifiable result without extensive coordination.
Its advantages include simpler deployment, fewer communication boundaries, reduced orchestration overhead, and easier debugging. These benefits matter particularly during early development and testing.
5.4 When Workflow Orchestration Adds Value
Orchestration becomes more valuable when a task spans several systems, requires human approvals, or must survive process restarts and temporary failures.
For example, an enterprise incident workflow might collect telemetry, create an investigation record, request an authorized review, invoke a change-management system, and verify the resulting network state.
These responsibilities benefit from explicit state transitions and durable records, regardless of whether the workflow uses one agent or many.
Coordination
Multiple services and dependencies need clear ownership, sequencing, and integration contracts.
Durable Execution
Long-running tasks may require checkpoints, persisted state, retries, and recovery after interruptions.
Governance
Sensitive operations need enforceable policy, human approvals, audit trails, and controlled execution boundaries.
5.5 Technical Architecture Comparison
| Dimension | Single-Agent Architecture | Managed Agentic Workflow |
|---|---|---|
| Primary scope | Bounded task handled by one acting component | End-to-end execution across defined workflow stages |
| Coordination | Usually limited to the agent and its tools | Explicit coordination between agents, services, and controls |
| State management | May use local or external task state | Often uses durable workflow state and checkpoints |
| Failure recovery | May retry or return failure to the caller | Can support stage-level retries, escalation, and resumption |
| Human approval | Can be integrated into agent tool execution | Often implemented as an explicit workflow stage |
| Observability | Agent and tool-level traces | Correlated traces across workflow stages and services |
| Operational complexity | Typically lower | Typically higher due to coordination and state |
| Best fit | Focused investigations and bounded assistance | Multi-stage, long-running, or governed enterprise processes |
5.6 Complexity Is Not Free
Every additional component introduces potential failure modes. Distributed workflows may encounter unavailable services, inconsistent state, duplicate requests, delayed approvals, and partial execution.
Engineers must consider idempotency, timeout behavior, retry policies, state consistency, and the consequences of actions that cannot be rolled back.
A workflow that performs an external operation successfully but fails before recording the result can be particularly difficult to recover. Retrying without checking the operation's actual outcome may create unintended duplicate effects.
5.7 Network Engineering Example: Incident Investigation
Consider an incident involving intermittent connectivity between an application server and a database service. The investigation may require checking routing state, firewall policy, interface counters, and service health.
Choosing the Appropriate Execution Architecture
Single-Agent Investigation
One agent uses approved read-only tools to inspect relevant network state, compare observations, and prepare a diagnostic report. The task ends when the report is produced or the agent reaches its execution limits.
Managed Incident Workflow
The application creates an incident record, coordinates telemetry collection, invokes an AI diagnostic component, preserves evidence, requests approval for remediation, and verifies the outcome after an authorized change.
Both approaches can provide value. The single-agent implementation may be sufficient for investigation and reporting. The managed workflow becomes more appropriate when the business process extends into approvals, execution, verification, and recovery.
5.8 Four Principles for Selecting the Architecture
Start Small
Use one agent until a specific requirement justifies more components.
Separate Control
Keep policy, identity, and critical execution controls outside the model.
Design for Failure
Define retries, timeouts, checkpoints, and recovery behavior.
Measure Outcomes
Evaluate task success, latency, cost, operational risk, and maintainability.
5.9 Single-Agent Does Not Mean Single-Service
A final distinction is important: an application can contain one AI agent while still relying on multiple backend services. Identity providers, telemetry APIs, policy engines, databases, and observability systems may all participate in the architecture.
The number of AI agents should not be confused with the number of application components. A well-engineered single-agent system can be distributed, secure, and operationally sophisticated without becoming a multi-agent architecture.
Section 05 — Engineering Takeaway
Single-agent and managed agentic workflows are complementary architectural patterns. Use a single agent for bounded tasks with manageable dependencies. Introduce orchestration when durable state, approvals, coordination, or recovery requirements justify it. Architectural quality is determined by reliability, security, and measurable outcomes— not by the number of agents deployed.
Agent Memory & RAG Lifecycle Explorer
Explore how an AI agent retrieves knowledge, allocates limited context, handles persistent memory and determines whether its answer is supported by trustworthy evidence.
Memory & Retrieval Pipeline
READYRetrieved Knowledge Candidates
Context Window Allocation
Generated Answer Assessment
Run retrieval to evaluate the available evidence.
Engineering Insight
Retrieval relevance is not the same as factual reliability. A production RAG system should evaluate source authority, freshness, access permissions and whether the selected evidence actually supports the generated answer.
Deterministic Automation vs Adaptive Agents: Understanding Fixed Workflows and AI-Driven Decisions
Traditional automation and agentic AI solve different engineering problems. Deterministic systems execute programmed logic, while adaptive agents can select actions based on context and feedback. Production systems often benefit from combining both approaches.
Deterministic automation has been fundamental to infrastructure engineering for decades. Network configuration management, monitoring systems, CI/CD pipelines, and cloud provisioning tools execute operations according to defined rules and control logic.
AI agents introduce a different capability: selecting among permitted actions when the appropriate next step depends on incomplete or changing information. This can be useful for investigation, analysis, and complex decision support.
However, adaptive behavior is not automatically superior to deterministic execution. For stable and repeatable operations, conventional software often provides stronger predictability, simpler testing, and clearer failure handling.
6.1 Deterministic Execution
A deterministic workflow follows explicit control logic. Given the same relevant inputs and system state, the program is designed to make the same decisions. External dependencies, timing, and environmental changes may still affect its observed results.
For example, a network automation script may retrieve interface counters, compare them against configured thresholds, and create an alert when a condition is satisfied. The decision criteria are defined in code.
6.2 Adaptive Agent Execution
An adaptive agent can select which operation to perform next based on observations. Rather than following a completely predefined diagnostic sequence, it may choose among authorized tools and revise its investigation strategy.
This flexibility is valuable when a problem has multiple plausible causes or when the next useful observation cannot be determined in advance.
Deterministic Automation
Execution decisions are encoded in application logic.
Adaptive Agent
Action selection may change in response to observations.
6.3 Where Adaptive Decisions Add Value
The main advantage of adaptive agents is not that they can execute commands. Conventional software already performs that function reliably. Their value lies in selecting useful actions when the appropriate sequence depends on context that is difficult to encode exhaustively.
Ambiguous Problems
Multiple plausible explanations require contextual investigation rather than a single fixed decision path.
Changing Evidence
New observations may alter which diagnostic operation is most useful next.
Variable Task Structure
Different requests may need different tools, information sources, and execution steps.
6.4 Technical Comparison
| Dimension | Deterministic Automation | Adaptive Agent |
|---|---|---|
| Decision logic | Explicitly programmed rules and algorithms | Model-assisted contextual action selection |
| Execution path | Defined by implemented control logic | May vary based on observations |
| Repeatability | Generally high under controlled conditions | May vary across executions |
| Testing | Unit tests, integration tests, and state-based assertions | Scenario evaluation, tool-call validation, and outcome testing |
| Failure handling | Programmed retries and recovery procedures | May propose alternative actions within enforced limits |
| Operational control | Directly enforced by application logic | Requires trusted enforcement around model-selected actions |
| Best fit | Stable, repeatable, high-assurance processes | Variable tasks requiring contextual judgment |
6.5 The Hybrid Architecture
A particularly useful enterprise design combines adaptive decision-making with deterministic execution controls. The agent investigates the task and proposes an action, while trusted application services determine whether that action is allowed.
The execution service validates the request, applies policy, performs the operation, and returns a verifiable result. The agent may then interpret that result and determine whether additional work is needed.
Adaptive Decisions, Controlled Execution
Agent Decision
Interpret the task and propose an authorized operation.
Policy Validation
Check identity, permissions, arguments, and operational limits.
Trusted Execution
Perform the permitted operation through controlled services.
Result Verification
Confirm the outcome, record evidence, and report status.
6.6 Handling Unexpected Failures
Adaptive systems must handle failures without creating uncontrolled execution loops. If a telemetry service is unavailable, the agent may choose an approved alternative source or report that the investigation cannot continue.
The runtime should enforce maximum retries, execution duration, tool-call budgets, and escalation rules. The agent should not be able to bypass these controls simply by generating another request.
For operations that change external state, retries require particular care. Before repeating an action, the application should determine whether the previous attempt already succeeded.
6.7 Network Engineering Example: BGP Troubleshooting
Consider a missing BGP prefix. A deterministic diagnostic script may check neighbor state, inspect a predefined route table, and report the result.
An adaptive agent can examine the initial observations and choose additional checks, such as received-route state, policy filtering, or route selection evidence.
Fixed Diagnostic Logic vs Adaptive Investigation
Deterministic Diagnostic
Run predefined checks against BGP session status and route tables. Evaluate programmed conditions and produce a structured result. Unexpected scenarios require additional programmed logic.
Adaptive Diagnostic Agent
Start with the missing prefix and available topology context. Select relevant read-only checks, interpret each observation, and pursue plausible causes within a controlled diagnostic scope.
The two approaches can work together. A deterministic service may collect and validate routing information, while the agent decides which diagnostic question to investigate next.
6.8 Engineering Selection Criteria
The correct architecture depends on the variability of the task, required assurance, operational risk, and cost of unexpected behavior.
If a workflow can be specified completely and tested reliably, deterministic automation is often the preferable solution. When a task requires contextual exploration across multiple possible paths, bounded agentic behavior may provide additional value.
Section 06 — Engineering Takeaway
Deterministic automation and adaptive agents are complementary technologies. Use conventional software for predictable operations, policy enforcement, and verified execution. Use adaptive agents where contextual decisions and changing evidence justify flexibility. The strongest enterprise designs combine both approaches through explicit control boundaries.
Multi-Agent Coordination & Delegation Lab
Investigate a network incident using specialised AI agents. Compare sequential and parallel orchestration, inject failures, and observe how task dependencies and shared evidence affect the final diagnosis.
Multi-Agent Execution Architecture
READYOrchestration Metrics
Select Run Investigation to start delegation.
Agent Coordination Timeline
No agent events recorded.
Engineering Insight
Multi-agent architectures introduce coordination costs, shared-state consistency requirements, task dependencies and failure propagation. Parallel execution can reduce latency only when tasks can safely run independently.
Agentic AI in Enterprise Architecture: Deployment Boundaries, Service Integration, and Operational Ownership
Moving from an AI prototype to a production enterprise application requires more than deploying a model and connecting tools. Engineers must define where the agent runs, which services it can access, how workflow state is managed, and which teams own security, reliability, and operational support.
Agentic AI applications increasingly interact with existing enterprise systems: cloud platforms, monitoring services, databases, network controllers, service-management tools, and internal APIs. These integrations introduce architectural requirements that extend well beyond model inference.
A production design must address identity, authorization, service connectivity, data boundaries, observability, deployment isolation, and failure recovery. The agent should operate as a governed application component rather than an unrestricted operator with access to enterprise infrastructure.
7.1 The Enterprise Agentic AI Deployment Model
A practical enterprise architecture separates user-facing applications, agent execution services, policy enforcement, and backend integrations. Each layer has distinct operational responsibilities.
Enterprise Application
User requests, task initiation, progress, and results
Identity and Access
Authentication, service identity, and authorization context
Application Gateway
Request validation, routing, quotas, and admission controls
Network and Cloud APIs
Controllers, telemetry, and infrastructure state
Enterprise Data Services
Inventory, documents, and operational records
Change and Incident Systems
Tickets, approvals, and controlled operations
Conceptual architecture. Components may be deployed together or separately, depending on scale and security requirements. Every backend operation remains subject to its own authorization controls.
7.2 Deployment Boundaries and Runtime Isolation
The agent runtime may execute in a container, virtual machine, managed application service, or another controlled compute environment. The correct deployment model depends on organizational requirements for scaling, isolation, availability, and operational support.
Agent execution should be separated from privileged infrastructure operations wherever practical. The runtime can request an action through a tool adapter, while a trusted backend service validates permissions and performs the operation using an appropriately scoped identity.
This approach reduces the consequences of incorrect model-generated requests and limits the exposure of administrative credentials.
7.3 Five Enterprise Ownership Domains
Enterprise deployments benefit from explicit ownership across the application lifecycle. These responsibilities may be shared between teams, but they should never be left undefined.
Application
User experience, task contracts, APIs, and business requirements.
AI Engineering
Agent behavior, model selection, evaluation, and tool-use quality.
Platform
Compute, deployment, scaling, state storage, and runtime reliability.
Security
Identity, authorization, data protection, policy, and audit controls.
Operations
Monitoring, incident response, service ownership, and recovery.
7.4 Integration with Existing Enterprise Services
Agents should not bypass established enterprise APIs or operational control systems. Where possible, integrations should reuse existing authentication, authorization, audit, and change-management mechanisms.
For example, an agent that investigates a network incident might query an inventory API, retrieve telemetry through a monitoring platform, and create an incident record through an IT service management system.
Each integration should expose a bounded capability with validated inputs and structured outputs. A generic unrestricted command-execution interface creates substantially greater risk than a narrowly scoped diagnostic API.
7.5 Enterprise Responsibility Matrix
| Capability | Typical Owner | Production Requirement |
|---|---|---|
| Agent behavior | AI application team | Versioned instructions, evaluations, and tool contracts |
| Model access | AI platform or application team | Approved models, quotas, and data-handling controls |
| Runtime hosting | Platform engineering | Isolation, deployment automation, scaling, and availability |
| Identity and permissions | Security and IAM teams | Least privilege, credential lifecycle, and policy enforcement |
| Tool integrations | Application and service owners | Authenticated APIs, validation, and operational contracts |
| Workflow state | Application and platform teams | Durability, consistency, retention, and recovery |
| Observability | Application and operations teams | Correlated traces, metrics, audit records, and alerts |
| Incident response | Operations and service owners | Runbooks, escalation, rollback, and service restoration |
7.6 Reliability and Failure Isolation
Enterprise applications must assume that model endpoints, backend APIs, databases, and external services can become unavailable. The architecture should define how the workflow behaves when any dependency fails.
Timeouts, bounded retries, circuit breakers, durable checkpoints, and explicit error states help prevent an isolated failure from becoming an uncontrolled execution loop.
Systems that perform external state changes should use idempotency controls where supported and verify whether an operation succeeded before retrying it.
7.7 Network Operations Deployment Example
Consider an enterprise deploying an AI-assisted network troubleshooting service. Engineers submit investigation requests through a web application. The agent accesses approved network telemetry and produces evidence-based diagnostic reports.
Deploying a Controlled Network Investigation Service
Application Boundary
The web application authenticates engineers, records investigation requests, and presents diagnostic results. User identity and task scope are passed to the backend.
Agent Runtime
The agent interprets the request, selects approved read-only tools, and evaluates observations. Workflow state and tool activity are recorded for operational review.
Infrastructure Services
Backend adapters query monitoring platforms, network controllers, and inventory systems. Privileged changes remain outside the diagnostic agent's execution authority.
The application can scale its user interface, agent execution workers, and backend integration services independently when needed. It can also apply different security policies to diagnostic reads and production changes.
7.8 Cloud, On-Premises, and Hybrid Deployment
Agentic applications are not inherently tied to a particular cloud provider. They can operate on-premises, in public cloud environments, or across hybrid architectures.
Deployment decisions should consider data residency, network connectivity, model availability, service latency, cost, and the location of protected enterprise resources.
For example, an agent application may run in a cloud environment while a controlled integration service operates inside a private network. The integration boundary can expose approved diagnostic capabilities without making internal management interfaces directly accessible to the model runtime.
7.9 Production Readiness and Operational Ownership
Before deployment, engineering teams should establish service-level objectives, operational monitoring, incident procedures, model and prompt versioning, evaluation criteria, and change controls.
Agentic behavior introduces additional operational questions: whether the agent selected an appropriate tool, whether the evidence supports its conclusion, and whether the final outcome satisfied the original task.
These questions require application-level observability rather than relying only on infrastructure CPU, memory, and network metrics.
Section 07 — Engineering Takeaway
Enterprise agentic AI is an application architecture problem, not simply a model integration problem. Production systems require clear deployment boundaries, authenticated service integrations, durable workflow state, trusted authorization, observability, and explicit operational ownership. The agent provides adaptive decision-making within an enterprise platform that remains responsible for security, reliability, and controlled execution.
Agent-to-Service Network Path Explorer
Trace how an AI agent communicates with model endpoints, tool services and external network APIs. Inject latency, connectivity failures and timeouts to distinguish application failures from underlying network problems.
Agentic AI Service Network
READYNetwork Telemetry
Select Trace Request to begin.
Request Path & Network Events
No network events recorded.
Engineering Insight
An AI agent may appear to fail because a remote dependency is slow or unreachable. Troubleshooting requires correlating application traces with network latency, transport failures, timeouts and service availability.
Security, Governance, and Operational Risk: Controlling Agentic AI in Production
Agentic AI introduces new operational risks because AI components may select tools, retrieve sensitive information, and initiate actions. Secure engineering requires more than protecting the model: it requires enforceable authorization, trusted execution boundaries, observability, and governance across the entire application.
Traditional enterprise applications already require identity management, secure APIs, data protection, and operational monitoring. Agentic AI inherits these requirements while introducing additional uncertainty around model-generated decisions and tool requests.
An agent may interpret untrusted documents, logs, search results, or tool responses as part of its task. It may also select actions dynamically rather than following a fully predefined execution path.
These characteristics make security boundaries especially important. A production system must distinguish between information the model may consider and instructions the application is actually authorized to follow.
8.1 How Agentic AI Changes the Threat Model
In a conventional application, many operations follow predefined program logic. In an agentic application, the AI component may select from a set of available tools based on contextual information.
This creates a new trust challenge: untrusted content can influence the model's proposed actions. If the surrounding application exposes excessive permissions, a manipulated agent may attempt operations outside the user's intended task.
The primary security concern is therefore not simply whether the model produces incorrect text. It is whether an incorrect or manipulated decision can cause an unauthorized external effect.
8.2 Five Layers of Agentic AI Security
A defense-in-depth architecture applies controls at multiple boundaries. No single prompt, model safeguard, or tool description should be expected to provide complete protection.
Identity and Authentication
Establish the user, workload, and service identities involved.
Authorization and Least Privilege
Restrict resources, tools, and actions to permitted scope.
Tool and Execution Validation
Validate arguments, enforce policies, and reject unsafe requests.
Data Protection and Isolation
Control sensitive data, external destinations, and execution environments.
Monitoring, Audit, and Response
Record actions, detect abnormal behavior, and support intervention.
Conceptual security architecture. Controls operate together rather than as a single sequential security checkpoint.
8.3 Prompt Injection and Untrusted Information
Prompt injection occurs when attacker-controlled or otherwise untrusted content attempts to redirect an AI system away from its authorized instructions.
For example, a diagnostic agent may retrieve a network incident document containing text that instructs the model to ignore its existing rules or send information to an external destination.
The document should remain task data, not become a source of authority. Strong designs restrict the agent's available capabilities and validate all requested actions through trusted services.
8.4 Six Important Operational Threats
Prompt Injection
Untrusted content attempts to redirect the agent's decisions or tool requests.
Excessive Permissions
An agent has broader resource access or execution authority than its task requires.
Tool Misuse
Incorrect or manipulated arguments trigger unintended operations against backend systems.
Data Exfiltration
Sensitive information is disclosed through unauthorized outputs, tools, or destinations.
Cascading Failures
Repeated or dependent agent actions amplify an initial error across services.
Insufficient Auditability
Missing execution records make it difficult to reconstruct decisions and outcomes.
8.5 Threats and Engineering Controls
| Threat | Potential Impact | Recommended Control |
|---|---|---|
| Prompt injection | Unauthorized action requests or manipulated conclusions | Treat retrieved content as untrusted; restrict tool capabilities and enforce independent authorization |
| Privilege escalation | Access to resources outside the intended task scope | Least-privilege identities, resource-scoped policies, and server-side checks |
| Unsafe tool execution | Unintended infrastructure changes or service disruption | Typed tool contracts, argument validation, approval gates, and trusted execution adapters |
| Sensitive data leakage | Exposure of credentials, internal records, or protected business information | Data minimization, access controls, output filtering, and destination restrictions |
| Runaway execution | Excessive tool calls, cost escalation, or repeated external effects | Timeouts, execution budgets, bounded retries, and cancellation controls |
| Unverified remediation | Incorrect assumptions about production state | Independent post-action verification, evidence capture, and escalation |
| Missing audit trail | Inability to investigate incidents or establish accountability | Correlated workflow logs, immutable or tamper-evident records, and retention policy |
8.6 Governance Is More Than Model Safety
Enterprise AI governance must address the entire application lifecycle: design, testing, deployment, operation, and retirement.
Teams should define acceptable use cases, data classifications, autonomy limits, evaluation requirements, service ownership, and incident-response procedures.
Governance also requires accountability. If an agent initiates a tool request, the organization must be able to determine which application, user context, policy, and service identity were involved.
Design Review
Define intended tasks, permitted capabilities, trust boundaries, and risk classification.
Pre-Deployment Evaluation
Test agent behavior, tool boundaries, prompt-injection resistance, and failure scenarios.
Production Monitoring
Monitor task outcomes, tool requests, policy denials, unusual activity, and resource consumption.
Incident Response
Support containment, execution cancellation, credential revocation, investigation, and recovery.
8.7 Security Scenario: A Manipulated Network Investigation
Consider an AI network investigation agent assigned to diagnose intermittent connectivity between two application environments.
The agent retrieves operational notes from an internal document repository. One document contains malicious instructions disguised as troubleshooting guidance, attempting to persuade the agent to export internal network configuration information.
Preventing an Agent from Crossing Its Authorized Security Boundary
Threat Entry
The agent encounters attacker-controlled text embedded in a retrieved document. The text attempts to redirect the investigation toward unauthorized data export.
Security Boundary
The application treats the document as untrusted data. Tool adapters enforce read-only access and reject unauthorized external destinations or unsupported operations.
Controlled Outcome
The agent continues within its permitted diagnostic scope or escalates when necessary. Suspicious requests and policy denials are recorded for investigation.
The important architectural lesson is that a model may still be influenced by malicious content. Security should not depend on the model always recognizing an injection attempt.
Instead, the surrounding application must ensure that unauthorized requests cannot be executed, even when the model proposes them.
8.8 Observability and Incident Investigation
Agentic systems require observability at both infrastructure and application levels. CPU, memory, and API availability metrics are necessary but insufficient.
Engineers should also record workflow identifiers, agent and model versions, tool requests, policy decisions, execution results, and relevant evidence references.
Sensitive prompts, retrieved documents, and tool outputs should not automatically be logged in full. Audit design must balance investigative usefulness with privacy, data minimization, and retention requirements.
8.9 Managing Operational Risk Over Time
Agent behavior can change when models, instructions, tools, or supporting services are updated. These changes should be evaluated before production rollout.
A controlled deployment process can include regression evaluations, staged releases, permission reviews, monitoring thresholds, and rollback procedures.
Organizations should also reassess whether an agent still needs its assigned capabilities. Permissions granted for an earlier workflow should not automatically remain available indefinitely.
Section 08 — Engineering Takeaway
Agentic AI changes the enterprise risk model because model-generated decisions can influence real systems. Production security requires defense-in-depth: authenticated identities, least-privilege tools, independent authorization, controlled execution, data protection, operational monitoring, and auditable outcomes. The objective is not to eliminate adaptive behavior, but to ensure that autonomy remains bounded by enforceable engineering controls.
Agent Trust Boundary & Approval Lab
Explore how untrusted content can influence an AI agent. Configure independent security controls, inject attacks, and observe whether a proposed action is blocked, escalated for approval or permitted.
AI Agent Trust Architecture
READYSecurity Control Configuration
Select Simulate Attack to inspect the security boundary.
Security Event & Decision Timeline
No security events recorded.
Engineering Insight
Security controls must operate independently of the language model's reasoning. Untrusted text must not gain authority simply because it appears in a retrieved document, tool response or agent context.
Choosing the Right AI Architecture: An Engineering Decision Framework for Agents, Workflows, and Agentic Systems
The most effective AI architecture is not necessarily the most autonomous or complex. Engineers must evaluate task variability, decision requirements, execution risk, reliability, and operational cost before choosing between conventional automation, LLM applications, single agents, and orchestrated agentic systems.
The previous sections have established several important distinctions. An AI agent is a bounded application component capable of interpreting tasks and potentially selecting actions. Agentic behavior describes the degree to which a system can pursue objectives through adaptive decisions and feedback.
Neither concept automatically requires a multi-agent architecture. A single agent can behave agentically, while a system containing several AI components may still follow a fixed deterministic workflow.
The engineering challenge is to determine which capabilities are actually required and implement them with the smallest reasonable operational footprint.
9.1 Five Architectural Options
Enterprise engineers can evaluate five common architectural patterns. These patterns are not mutually exclusive: a production application may combine several of them.
These are architectural alternatives, not mandatory maturity stages. More components do not necessarily produce better outcomes.
9.2 Start with the Nature of the Task
Before selecting a technology, engineers should determine whether the task can be specified as a stable sequence of operations.
If the required behavior is predictable and can be implemented through conventional rules, deterministic automation is often the strongest option.
If the task primarily requires language understanding, document analysis, or content generation, a conventional LLM application may be sufficient.
Agentic capabilities become more relevant when the system must select among different possible actions based on changing evidence.
9.3 Six Engineering Selection Criteria
Task Variability
How often does the appropriate execution path change between requests or observations?
Decision Complexity
Does the task require contextual judgment that is difficult to encode completely?
Operational Risk
What happens if the system chooses an incorrect action or produces an incorrect conclusion?
Execution Duration
Does the process require durable state, checkpoints, approvals, or recovery after interruptions?
Integration Scope
How many systems, tools, and service boundaries must participate?
Measurable Value
Does added AI autonomy improve accuracy, task completion, time, or operational cost?
9.4 Architecture Selection Matrix
The following comparison provides a practical starting point for engineering design reviews. Actual suitability depends on implementation and task requirements.
| Architecture | Primary Strength | Typical Limitation | Suitable Example |
|---|---|---|---|
| Deterministic Automation | Predictable execution and explicit control logic | New scenarios may require additional programmed logic | Configuration validation, scheduled checks, and threshold monitoring |
| LLM Application | Natural-language interpretation and generation | Does not inherently manage autonomous multi-step execution | Incident summarization, documentation analysis, and knowledge assistance |
| Single AI Agent | Contextual decisions and bounded tool use | Complex coordination may exceed a simple execution model | Focused network troubleshooting investigation |
| Managed Agentic Workflow | Explicit orchestration, durable state, and governance | Greater implementation and operational complexity | Incident investigation through approval, remediation, and verification |
| Multi-Agent System | Specialized components can address distinct subtasks or domains | Coordination overhead, inconsistent outputs, and difficult debugging | Complex investigations requiring specialized security, network, and application analysis |
9.5 Why More Autonomy Is Not Always Better
Increasing autonomy may reduce the need for human intervention, but it also increases the importance of authorization, monitoring, evaluation, and recovery.
An agent that can select read-only diagnostic queries presents a different risk profile from an agent authorized to deploy production configuration.
Engineers should therefore increase autonomy incrementally, validating the behavior of each additional capability before granting broader execution authority.
9.6 Network Engineering Case Study
Consider an organization that wants to improve its response to intermittent BGP connectivity incidents.
The initial requirement is to collect routing state and summarize likely causes. Later, the organization may want adaptive investigation and controlled remediation.
Selecting Architecture Based on Actual Requirements
Initial Requirement
Collect BGP neighbor state, route tables, and configured policy information. Deterministic APIs and structured reporting may be sufficient.
Adaptive Investigation
Introduce a bounded agent that selects diagnostic queries based on observed routing evidence. Keep all tool access read-only and authorized.
Enterprise Workflow
Add durable incident records, approval gates, controlled remediation, and independent post-change verification.
The architecture evolves because the requirements change, not because the organization must progress through predefined AI maturity stages.
Even at the most advanced stage, deterministic services remain responsible for trusted execution, authorization, and state verification.
9.7 Architecture Design Checklist
Before implementing an AI agent or agentic workflow, engineers should be able to answer the following design questions.
Is the intended task and successful outcome clearly specified?
Is AI-based action selection necessary or measurably useful?
Are available tools, permissions, and resource scopes explicit?
Does trusted software validate and authorize external operations?
Are timeouts, retries, checkpoints, and escalation paths defined?
Can engineers reconstruct tool requests, policy decisions, and outcomes?
Are untrusted content, sensitive data, and privilege boundaries addressed?
Are quality, latency, cost, and task completion evaluated against a simpler baseline?
9.8 The Future of Enterprise Agentic AI
As agentic AI capabilities develop, enterprise systems are likely to support increasingly sophisticated task execution and integration patterns.
However, the fundamental engineering requirements remain familiar: clear interfaces, bounded authority, reliable services, secure identities, observable execution, and recoverable failures.
The most successful architectures will combine the adaptability of AI decision-making with the predictability and assurance of conventional software.
The Right Architecture Is the One That Solves the Problem Reliably
AI agents and agentic AI are related but distinct concepts. An agent is an application component that can interpret tasks and potentially select actions. Agentic behavior describes how a system pursues objectives through delegated decisions, observations, and adaptation.
Neither requires unrestricted autonomy or a large multi-agent platform. Enterprise engineering is about selecting the appropriate level of intelligence, coordination, and execution authority for each task.
Design for the outcome. Delegate decisions carefully. Keep execution controlled. Verify everything that matters.
Agent Failure Diagnosis Lab
An autonomous network troubleshooting agent has failed. Investigate distributed traces, inspect diagnostic evidence and identify the root cause before submitting your diagnosis. Can you distinguish the symptom from the actual failure?
Distributed Execution Trace
INVESTIGATINGInvestigation Toolkit
Select an investigation check to reveal evidence.
Inspect the evidence and select the most likely root cause.
Engineering Insight
Production agentic systems need observability across model calls, retrieval, tools, runtime policy and external services. A successful investigation correlates trace spans, structured logs and dependency evidence before identifying the failure domain. The final diagnosis should be supported by evidence, not inferred from a single error message.
- Azure AI Networking Architecture - November 12, 2026
- AI Agents vs Agentic AI - November 12, 2026
- Agentic AI Architecture - November 11, 2026