Enterprise Agent Components and Data Flows

Welcome back. In the previous lesson, you separated model errors, safety failures, privacy failures, and security attacks. To investigate any of those events, a team needs more than a description of “what the AI did”: it needs a map of which component received what information, made which decision, called which system, and recorded which evidence.

This final lesson in the first module turns the concepts so far into an enterprise-agent diagram. You will learn to represent the core components of an agentic system and label the data flows between them. The goal is not a vendor-specific deployment drawing; it is a clear logical diagram that makes an agent’s authority, data access, and operational path understandable.

---

From “an agent” to an architecture

An enterprise agent is rarely one model connected directly to a chat box. It is a system containing a user-facing application, application logic, an agent runtime, a model, information sources, tools that can affect business systems, state storage, and operational oversight.

The IBM conceptual architecture below offers a useful first view. A user interacts with an AI application, which hands work to an orchestration layer. That layer coordinates agents and models; agents use tools; tools retrieve from or update enterprise and external systems.

Two distinctions will keep your diagrams accurate:

1. A component is a system element with a responsibility, such as an orchestrator, retrieval service, tool gateway, or audit log.
2. A data flow states what crosses from one component to another, such as “authenticated task context,” “retrieved passages,” “tool result,” or “approval decision.”

Do not draw a line merely because two boxes are related. Label it with the information or request that actually moves. That label is what turns a presentation graphic into an architecture artifact useful for security and operations.

The minimum set of boxes

For a representative enterprise agent, begin with these logical roles:

Component	Responsibility	Typical information it handles
User interface	Presents results and accepts requests, approvals, and feedback	User request, displayed response, approval selection
Application API or backend	Connects the interface to the runtime and enforces application-level rules	Authenticated request, session context, rate limits
Identity service	Authenticates the requester and supplies identity attributes	User identity, roles, session claims
Agent orchestrator	Maintains task state and decides which controlled step happens next	Task context, plans, tool proposals, results, policy decisions
LLM	Interprets language, generates drafts, and proposes reasoning or tool use	Instructions, retrieved context, proposed response or action
Retrieval service	Finds task-relevant information in approved knowledge sources	Search query, permitted passages, citations
Tool gateway or integration layer	Converts an approved agent request into a controlled call to an external system	Tool request, authorized parameters, tool result
Enterprise sources and systems	Hold records or perform real business actions	Documents, records, transaction results
State, memory, and audit storage	Preserves useful context and evidence of activity	Conversation state, workflow status, tool-call record, approval record
Policy and approval service	Applies deterministic rules and, where needed, requests human authorization	Authorization request, allow/deny decision, approval requirement
Telemetry and monitoring	Supports troubleshooting, detection, and accountability	Events, errors, timings, identifiers, security-relevant records

This is a logical model. One product can implement several roles, and one role may be distributed across several services. For example, an agent platform may combine orchestration, conversation history, tool invocation, and model access. That does not mean the responsibilities have disappeared; it means they are implemented behind a managed-service boundary.

---

A diagram must distinguish reasoning from authority

The most important design choice in an enterprise-agent diagram is separating the part that produces probabilistic suggestions from the part that grants authority.

The LLM may produce a useful answer, a proposed sequence of steps, or a suggestion to call a tool. But a model response should not itself constitute permission to alter a record, disclose a restricted document, or send an external communication. Those decisions belong in explicit policy, authorization, and approval components.

This connects directly to the preceding lesson. If a model incorrectly proposes an action, that is a model error. If a system accepts the proposal without checking the requester’s rights or the action’s limits, the architecture has made the error operationally significant.

A clear diagram therefore shows at least four distinct flows around an action:

• the model’s proposal;
• the orchestrator’s authorization request;
• the policy component’s decision;
• the tool gateway’s approved tool call.

This separation also makes it possible to find the evidence later: the proposal, policy outcome, actual tool request, tool result, and final response should be attributable to the same task or session.

Read flows and write flows are not equivalent

A diagram should reveal whether a tool merely reads information or can change something.

A retrieval service usually performs a read operation: it searches approved document collections and returns selected passages. A tool connected to a procurement, ticketing, HR, or customer system might read records, create a draft, update a record, or execute a transaction. Those operations carry very different consequences.

Use specific labels whenever possible:

• “Search query” and “authorized passages” are retrieval flows.
• “Create purchase-order draft” is an action request.
• “Purchase-order identifier and status” is a tool result.
• “Allow,” “deny,” or “approval required” is a policy decision.

Avoid vague labels such as “data” or “AI request.” They conceal whether the flow contains sensitive context, executable authority, a business record, or merely a user-visible response.

---

Build a representative enterprise-agent diagram

Consider an internal procurement assistant. An employee asks it to prepare a purchase-order draft for an approved supplier. The assistant needs policy documents and supplier information. It may create a draft in the procurement system, but it cannot submit a purchase order without authorization and, where required, a human approval.

The following is a logical diagram of that system. The grouped areas organize responsibility; they are not yet a formal network or trust-boundary diagram.

Trace one request through the diagram

A stakeholder should be able to reconstruct the workflow from the diagram alone. For the procurement example, the request proceeds as follows:

1. The employee submits a natural-language request through the user interface.
2. The application backend verifies the session and associates the request with the authenticated user.
3. The backend sends task context to the orchestrator, which obtains any relevant prior workflow state.
4. The orchestrator asks the model to interpret the request using instructions and the available context.
5. The orchestrator retrieves relevant procurement policy or supplier information from approved knowledge sources.
6. The model may propose a response or a tool call, but the orchestrator submits the proposed operation to the policy and approval service.
7. If the request is permitted, the orchestrator calls the tool gateway, which interacts with the procurement system.
8. The tool result returns to the orchestrator. The system stores state and records material events, decisions, and results for audit and monitoring.
9. The application returns a user-facing result, such as “Draft purchase order created; manager approval is required before submission.”

Notice three things that the diagram makes explicit:

• The LLM is not the whole agent. It is one component inside an orchestrated system.
• Retrieval and tool use differ. One obtains context; the other may interact with a system of record.
• A response can be produced even when no action occurs. A policy decision may deny an action or require a human approval while still allowing the agent to explain the result to the user.

---

Mapping the logical diagram to a production architecture

The logical diagram above is deliberately vendor-neutral. A production implementation adds details about networking, storage, identity, monitoring, and system isolation.

Microsoft’s reference architecture gives a concrete example. Its workflow includes a chat UI, an application tier, an agent service, a language model, search-based grounding, tools, conversation persistence, private connectivity, and controlled external access. The product names are less important than the separation of responsibilities and the recorded workflow.

A production diagram may add controls such as:

• a web application firewall at the public entry point;
• private connections between internal services;
• restricted outbound connectivity for external APIs;
• a secrets-management service;
• separate databases for operational state and long-term knowledge;
• monitoring systems that correlate application, model, and tool events.

Those details matter, but add them only after the logical workflow is comprehensible. Otherwise, the essential question—who can cause which system to do what with which data?—gets buried beneath infrastructure symbols.

A practical diagramming method

When creating a diagram for a new agent, use this order:

1. State the actor and outcome. Define who initiates the task and what business outcome the agent is intended to produce.
2. Place the user-facing boundary. Draw the user, interface, application backend, and identity system.
3. Draw the agent runtime. Include the orchestrator, model, policy or approval service, and task state.
4. Add each information source separately from action systems. A document repository, a search index, and a transaction system should not collapse into one generic “database” box.
5. Label each request and return flow. Use concrete descriptions of the data or authority transferred.
6. Show evidence flows. Include state persistence and audit or telemetry records, especially for tool calls and approvals.
7. Review the authority path. Make it visible where a model proposal becomes an authorized operation, or where it is stopped.

A good diagram does not need every implementation detail. It needs enough detail to expose the system’s capabilities, data access, decision points, and observable evidence.

---

Common diagramming mistakes

Treating the UI as the agent

A chat window is an interaction surface, not the reasoning, policy, retrieval, or tool-execution system behind it. If the UI is the only visible component, the diagram cannot explain how the agent obtained its answer or who controlled an action.

Combining model, orchestration, and policy into one box

This obscures an essential accountability distinction. The model generates probabilistic content; the orchestrator manages workflow; the policy layer makes deterministic permission or approval decisions. A managed platform may host all three, but your logical diagram should preserve their roles.

Drawing one generic “database”

Enterprise agents commonly use distinct kinds of data stores:

• a knowledge source for retrieval;
• conversation or workflow state for continuity;
• a system of record for business transactions;
• an audit repository for evidence.

Combining them hides meaningful differences in purpose, access, retention, and consequence.

Showing tool use without the system of record

A “calendar tool” or “ERP tool” box says little about impact. The diagram should also show the underlying calendar, ERP, ticketing, messaging, or document system. That is where data is read, changed, or disclosed.

Omitting negative decisions

An approval or policy component is not decorative. It can permit, deny, constrain, or pause an operation. Showing only successful tool calls implies that the agent always has authority to act, which is often untrue and unsafe.

Confusing a logical architecture with a deployment topology

A logical diagram answers what responsibilities and flows exist. A deployment diagram answers where the components run and how they are connected. You will eventually need both, but they should not be forced into one unreadable picture.

---

Key takeaways

A representative enterprise-agent diagram should make the agent system legible as a set of interacting responsibilities:

• The user interface and application backend receive requests and establish the requester’s context.
• The orchestrator manages state and workflow, while the LLM proposes interpretations, responses, or actions.
• Retrieval supplies authorized context; tools interact with systems outside the runtime.
• A separate policy and approval layer determines whether an action may proceed.
• Memory, audit, and telemetry preserve continuity and evidence.
• Every connection should be labelled with the request, context, result, decision, or record that moves across it.

Most importantly, a useful agent diagram separates probabilistic reasoning from authorized action. That separation will be central throughout the security portions of this course.

You have now completed the conceptual foundation for how agentic systems work. The next module develops the practical technical literacy needed to inspect and safely run small agent demonstrations, beginning with the purpose of variables, functions, conditionals, and loops in a short Python script.