> ## Documentation Index > Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt > Use this file to discover all available pages before exploring further. # Agent Workflows: How an Agent Executes an SOP > Understand what an agent workflow is, how we document and approve it before building, and what it takes to update one after your agent goes live. A workflow is the complete, documented sequence of steps your agent follows from the moment an input arrives to the moment the process is complete. Think of it as a written SOP — one that the agent executes faithfully, in the order you approve, without skipping steps or improvising. Every agent we build is backed by one or more documented workflows that you review and sign off before any build work begins. A workflow is not a reasoning chain or an open-ended decision process. It is a defined procedure with a fixed starting point, a set of ordered steps, explicit branch conditions, and documented escalation points. If a situation arises that the workflow does not cover, the agent does not guess — it escalates. See [Scope & Boundaries](/consulting/scoping) for how we define the right scope before documenting any workflow. ## Workflow structure Every workflow is made up of the same set of structural elements. Understanding these helps you review a draft workflow and identify anything that does not match how your business actually operates. The condition that starts the workflow. This maps directly to one of the agent's configured input sources — a new item in a shared inbox, a file placed in a watched folder, a form submission, a scheduled time, or an event from a connected system. A workflow has exactly one trigger. If the same procedure should run from multiple input types, each input is configured as a separate trigger pointing to the same workflow. The ordered sequence of actions the agent takes after the trigger fires. Each step is documented explicitly: what the agent does, which system it reads from or writes to, and what it produces. Steps may be sequential, conditional, or involve a lookup before proceeding. No step is implicit. If the agent needs to read a record before acting, that read is its own documented step. If it needs to wait for a response, the wait condition and timeout are written into the step. Points in the workflow where the agent evaluates a condition and follows one of two or more defined paths. The condition, the options, and the action taken for each outcome are all specified before build begins. Conditions are based on data the agent has retrieved or received — not on open-ended assessment. For example: "if the submitted value is above the defined threshold, follow path A; if at or below, follow path B." Steps where the agent is required to stop and hand the item to a human. Escalation points are triggered by the conditions defined in the agent's [escalation rules](/agent-structure/components) — authority thresholds, complaint severity flags, unrecognised input types, or mandatory sign-off requirements. When an escalation fires, the agent packages the current state of the item — what it received, what steps it completed, what condition triggered the escalation — and routes it to the designated person or queue with that context intact. The final step that marks the workflow as done. This may be a system write (updating a status field, closing a record), an outbound message (sending a confirmation, filing a report), or a file output (placing a completed document in a designated folder). Every workflow has exactly one defined completion state for each path through it. ## Workflow patterns Most real workflows combine more than one of these fundamental patterns. Knowing the pattern helps you communicate what you need during the design phase. **Step 1 → Step 2 → Step 3** Steps execute in a fixed sequence. Used when the process is identical every time and no decisions are required. *Example: receive submission → validate required fields → create record → send acknowledgement → end* **If condition X → follow path A; otherwise → follow path B** The agent evaluates a defined condition and takes different actions depending on the result. Used when different inputs should produce different outputs. *Example: if the item meets the approval criteria → log as approved and notify requester; if it does not → escalate to Department A manager* **Repeat until condition met or limit reached** The agent repeats a step at a defined interval until a condition is satisfied or a maximum attempt count is reached. Used for polling an external system or waiting on a response. *Example: check whether a delivery confirmation has been received every four hours — escalate after three unsuccessful checks* **Run step A and step B simultaneously** Two or more steps execute at the same time, then the workflow continues once both are complete. Used to reduce elapsed time when steps do not depend on each other. *Example: write the new record to the job management system and send the acknowledgement email at the same time* ## How workflows are documented During the design phase, every workflow is documented in two formats so that both technical and non-technical stakeholders can review and approve it clearly. A plain-language description walks through each step in simple prose — no jargon, no code. It describes what the agent does, which system it reads from or writes to at each step, what conditions it evaluates, and what happens at each escalation point. This is the primary format you will use for design reviews. You do not need to read a diagram to approve a workflow — the written description tells you everything that matters. **Example (Department A inbound enquiry workflow):** > When a new message arrives in the Department A shared inbox, the agent reads the message and checks whether the subject and content match a recognised enquiry type. If the message matches a known type, the agent looks up the relevant record in the job management system, drafts a standard acknowledgement using the current record status, and sends the reply. It then logs the interaction against the record and marks the step complete. If the message does not match any known enquiry type, the agent holds it in the review queue and sends a notification to the Department A team lead, with the original message and a note that it could not be classified. A visual flowchart accompanies every plain-language description. It uses a simple, standardised format — rectangles for process steps, diamonds for branch conditions, double-bordered rectangles for escalation points — so you can trace any path through the workflow at a glance. Flowcharts are particularly useful for: * Spotting edge cases that the written description might obscure * Reviewing conditional branches side by side * Communicating the workflow to team members who did not attend the design session Workflow diagrams are delivered as shareable documents your whole team can view and comment on without needing a specific tool. ## Review and approval You formally approve every workflow before build begins. Here is how that process works. After your discovery workshop, we deliver a draft workflow document covering all planned agent behaviours — plain-language descriptions and diagrams for each workflow in scope. You have five business days to review the draft with your team. You can leave comments directly on the shared document or raise questions via your preferred channel. We walk through the workflows together on a 45-minute call. This is the right moment to catch edge cases, adjust branch conditions, add escalation rules you did not think of during discovery, or correct any step that does not reflect how the process actually runs. Once you are satisfied, you confirm approval in writing. This sign-off locks the scope for the build phase and starts the clock on your delivery timeline. Changes requested after sign-off may affect your delivery timeline. Minor adjustments are usually absorbed, but structural changes — adding a new branch, changing the trigger type, adding a new escalation condition, connecting a new system — are treated as change requests and scoped separately. ## Updating workflows after launch Your processes will change, and your agent's workflows should change with them. Not every update is the same — some take minutes, others require a structured rebuild. These changes update values or settings within an existing workflow structure without altering its logic. * Updating the text in a standard acknowledgement or notification message * Adjusting a threshold value used in a branch condition (for example, raising an approval limit) * Adding or removing a team member from an escalation routing destination * Changing the schedule of a timed trigger * Updating the folder path or inbox address used as an input source These changes alter how the workflow behaves — adding a new condition, inserting a step, or changing the order of actions. * Adding a new conditional branch (for example, handling a new enquiry type differently) * Inserting a new step into an existing flow (for example, adding a lookup before a step that previously acted without one) * Adding a new escalation rule or changing the conditions that trigger an existing one * Adding a loop or retry mechanism that did not previously exist These changes are significant enough that we treat them as a mini-project — with a new scoping call, updated documentation, and a fresh sign-off process. * Adding an entirely new trigger type or input source * Connecting a new system that requires authorisation and testing * Merging two separate workflows into one combined process * Re-architecting the workflow to cover a new business process that falls outside the existing role definition ## Example workflow: Department A inbound triage Here is a complete example of the level of detail we document for every agent. This pattern is common across department-facing agents that handle a shared inbox or submission queue. ``` WORKFLOW: Department A inbound triage TRIGGER: New message received in Department A shared inbox STEP 1 — Read and classify inbound message - Extract: sender, subject, body text - Check against defined enquiry type list → IF classified: proceed to Step 2 → IF unclassified: proceed to Step 5 (escalation path) STEP 2 — Look up existing record [LOOKUP] - Query job management system using sender email → IF record found: retrieve current status and last activity date → IF no record found: create new draft record (status: pending) STEP 3 — Draft and send acknowledgement [PARALLEL] 3a. Generate acknowledgement using standard template for the matched enquiry type - Personalise with: sender name, enquiry type, current record status - Send reply from Department A shared inbox 3b. Log interaction against the record - Write: timestamp, enquiry type, action taken STEP 4 — Mark step complete - Update record status to "acknowledged" - END (standard path) STEP 5 — Escalation path [UNCLASSIFIED INPUT] - Hold message in review queue (do not reply) - Send notification to Department A team lead - Include: original message, sender, reason for escalation ("enquiry type not recognised") - END (escalation path) ``` This workflow uses a conditional branch at Step 1, a lookup at Step 2, and parallel execution at Step 3. The escalation path at Step 5 is an example of an unrecognised-input escalation rule in practice — the agent holds the item rather than acting on incomplete information. ## Next steps Understand the individual building blocks — input sources, SOP logic, escalation rules, and outbound interfaces — that each workflow step depends on. See how workflow steps connect to the job management systems, shared inboxes, and other platforms your business already runs on.