Lesson 1: Draw the Agent and What It Talks To

Training overview · Lesson 1 of 11 · Next: Say what data moves

Goal

An agent is one Agent Service. Its tool calls and the content coming back to it are separate flows.

After this lesson you can draw the shape of an agentic system: which element is the agent, what hosts it, and which flows go in and out.

What you start from

An empty model: create a new model in the Browser.

Click the + button at the top right of the content area and choose the model icon, New model (see The Browser's plus button). A model named "New Model" is created at once and its settings open: rename it, then click the diagram button at the bottom right of the dialog to open the data flow editor.

The recipe step

Step 0: Draw the agent

One Agent Service per agent, or per group of agents with the same tools, model and context sources. A runtime product (a harness, an agent server or a platform) is its own element. Draw an Agent Runtime boundary only around two or more agents when no container holds exactly their process space. Never draw below the agent: a tool call is a flow, and what it calls (an MCP server, an API, a shell, a harness) is an element. A hand-off from one agent to another is an Agent Tool Call, and its result a Context Ingress back, drawn directly between the two agents.

Why: Every agent pattern is about one agent. A tool drawn as its own agent splits one agent's facts across elements that cannot add up.

Ask:

Which agents does the system run, and which of them share the same tools, model and context sources?
What hosts each agent: a harness, an agent server, a platform, or nothing (a standalone service)?
Which agents hand work to another agent, and which agent holds the tools that act?

Classes: Agent Service, Agent Harness, Agent Server, Agent Runtime, Agent Code Execution Sandbox.

What the analysis reads here:

An agent: Agent Service.
A remote agent you reach over A2A: Remote A2A Agent.
A harness that runs an agent and approves its actions: Agent Harness.
A boundary around agents that share one process space: Agent Runtime.
A sandbox the agent runs code in: Agent Code Execution Sandbox.
An agent platform that hosts agents: AnythingLLM, Dify, Flowise, Langflow, LibreChat, LobeHub, MaxKB, n8n, Open WebUI, OpenClaw, RAGFlow.
Something that runs code or tools for an agent: Agent Harness, Agent Server, AnythingLLM, Dify, Flowise, Langflow, LibreChat, LobeHub, MaxKB, Open WebUI, OpenClaw, RAGFlow, n8n.
An executor that can read files in the agent's space: Agent Harness.
An MCP server: Local MCP Server, Remote MCP Server.

In the worked system the answers are simple. There is one agent, the support copilot. Nothing hosts it: it runs as a standalone service in its own container, so there is no harness to draw.

Steps

Draw every element and flow below. Do not add data items yet, and give no zone to anything outside the support network: they come in lessons 2 and 3. The support network itself is Internal from the start.

Add the boundary Support network (class Network Segment, zone Internal).
Add the boundary Copilot container (class Container), inside Support network.
Add Customer (class End User), outside every boundary.
Add Ticket system (class Application Service), inside Support network.
Add Staff console (class Agent Chat Frontend), inside Support network.
Add Support copilot (class Agent Service), inside Copilot container.
Add CRM (class Third-Party Service), outside every boundary.
Add Hosted model (class Hosted LLM API), outside every boundary.
Draw New ticket (class HTTP/S Request) from Customer to Ticket system.
Draw Context Ingress: ticket (class Context Ingress) from Ticket system to Support copilot.
Draw CRM lookup (class Agent Tool Call) from Support copilot to CRM.
Draw Context Ingress: customer records (class Context Ingress) from CRM to Support copilot.
Draw Post reply (class Agent Tool Call) from Support copilot to Ticket system.
Draw Reply e-mail (class HTTP/S Request) from Ticket system to Customer.
Draw Answer to staff (class HTTP/S Request) from Support copilot to Staff console.
Draw Inference Request / Response (class Inference Request / Response) from Support copilot to Hosted model.

Look at the flows between the copilot and the CRM. CRM lookup goes from the copilot to the CRM: it is the tool call. Context Ingress: customer records comes back from the CRM to the copilot: it is the content the agent reads. The same holds for the ticket: the ticket system hands the ticket to the copilot as a Context Ingress, and the copilot's Post reply tool call goes the other way.

When the drawing is complete, create a Threat Patterns analysis, open it with View results and click Generate (see Run Threat Patterns on a lesson model).

What you should see

Findings: 0 systemic findings: 0 Confirmed · 0 Not ruled out.

Facts to establish: 8 questions.

Facts that could raise a finding:

Draw the data items on Context Ingress: customer records
Draw the data items on Context Ingress: ticket
Set the attribute Consequential Tools Present (consequential_tools_present, in Human Oversight) or Code Execution Tools Present (code_execution_tools_present, in Application Security) on Support copilot
Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console
Draw the outbound flows of Support copilot, or answer Network Egress Default-Deny Allowlist (network_egress_default_deny_allowlist, in Network & Connectivity) on Support copilot
Draw the runtime boundary or the Agent Tool Call that ties Support copilot to its harness
Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
Every drawn route from Ticket system ends inside; assert its outbound flows complete if nothing else leaves it

Model gaps: 1 of 1 agents have no hosting harness drawn, so their W cannot be read from one (on Support copilot)

There is no finding. All the questions sit under Facts that could raise a finding, on the Facts to establish tab. The model gap names the copilot.

What changed and why

Nothing is found because nothing is known yet. A finding needs at least two of its required legs present. The drawing shows the shape, but it says nothing about content, who is outside, or what the agent's tools can do. Every leg is still undetermined, and an undetermined leg is never read as "no".

The questions tell you what to state next. Read them as a to-do list:

Draw the data items on Context Ingress asks what the copilot reads. Lesson 2 answers it.
The questions about outbound flows ask whether anything the copilot sends can reach an outsider. Two of them say that every drawn route from the CRM, and from the ticket system, ends inside. That is only as true as the zones, and every destination still reads as Internal: the ticket system and the staff console are in the support network, and the customer and the CRM sit outside every boundary, which reads as Internal. The reply e-mail does reach an outsider, the customer, so do not assert any outbound flows complete here. Lesson 3 settles these questions by marking who is outside, not by drawing more flows.
Set the attribute Consequential Tools Present (consequential_tools_present, in Human Oversight) or Code Execution Tools Present (code_execution_tools_present, in Application Security) asks what the copilot's tools can do. Lesson 5 answers it.
Draw the runtime boundary or the Agent Tool Call that ties Support copilot to its harness, and the model gap with it, ask how the copilot's actions get approved.

Some questions are for later. Not every question can be answered in the lesson that raises it, and some stay open to the end. Lesson 8 shows why answering a fact you do not know is never the way to clear a question.

Do not draw a harness that does not exist. The copilot is a standalone service. It has no harness, so there is nothing to tie it to. Leave the question open. In lesson 5 you answer the copilot's own approval fact instead, and both the question and the model gap go away.

Exercise: Tools are not agents

On a scratch copy (import L1-solution.zip and rename it), draw the copilot's CRM lookup, its ticket reply and its console answer as three Agent Services, each with its own flows. Generate again.

This is the wrong shape: tools are not agents. Look at Facts to establish:

Each new agent gets its own questions. The questions about tools, the harness and outbound flows now come once for every agent you drew, each naming that agent.
Each one counts in the model gaps. The model gap about agents with no hosting harness drawn now counts all four agents, and the line beneath it names them.
None of them adds up to the copilot. One "agent" reads customer records but cannot post; another posts but never reads a ticket. The facts about one agent are split across elements that the analysis reads separately, so no single element holds every leg a finding needs.

Stop at the agent: its tools are flows, not elements.

Delete the copy when you are done.

Lesson 2: Say what data moves. You classify the ticket text and the customer records and attach them to the flows that carry them.