> ## 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 Components: The Building Blocks of an SOP-Driven Agent
> Learn the five building blocks of every agent we design — role definition, input sources, SOP logic, escalation rules, and outbound interfaces — and how each shapes what your agent does.
An agent is not a single piece of software — it is an assembly of distinct, purposeful components. Each component has a defined job, and together they form a process-bound service that follows your procedures exactly the same way every time. When we design your agent during the discovery and build phases, we make deliberate decisions about how each component should behave for your specific business. Knowing what these components are helps you give better input during design reviews and identify where to focus when something needs to change.
## The five core components
### What the agent is responsible for
A role definition is the written specification of what an agent is responsible for — and, just as importantly, what it is not. It sets the scope of authority before the first line of build work begins.
Every role definition answers three questions:
| Question | Example answer |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **What process does this agent own?** | Handling all inbound enquiries received at the Department A shared inbox during business hours |
| **What decisions can it make without escalation?** | Send a standard acknowledgement, log a new record, route to the correct team queue |
| **What must it always refer to a human?** | Any request involving a refund, a complaint rated severe, or a query outside its defined subject area |
The role definition is the first document produced during the design phase. Everything else — input sources, SOP logic, escalation rules — is built on top of it.
A focused role definition is the single strongest predictor of a successful agent. Agents that are given one clear responsibility are faster to build, easier to test, and simpler to hand off to your team. See [Scope & Boundaries](/consulting/scoping) for guidance on how to define the right scope before build begins.
### What the agent monitors
Input sources are the channels and data feeds the agent observes continuously. When a new item arrives on a monitored source, the agent wakes up and begins processing it. Without a matched input, the agent stays idle.
| Input source type | How it works | Example |
| ------------------- | ------------------------------------------------------------------ | --------------------------------------------------------- |
| **Shared inbox** | Agent reads new messages in a designated email address | All messages to `department-a@example.com` |
| **Shared folder** | Agent detects when a new file is placed in a watched directory | A new invoice PDF dropped into the finance folder on VM-1 |
| **Form submission** | Agent receives structured data when a web form is completed | A supplier submits a delivery confirmation form |
| **Event stream** | Agent listens to a feed of system events from a connected platform | A new record created in the job management system |
| **Scheduled time** | Agent activates at a defined interval to run a routine task | Every weekday at 08:00, review open items in the queue |
| **Inbound message** | Agent reads messages sent to a dedicated chat channel | A message posted to the Department A internal channel |
One agent can monitor multiple input sources. For example, the same agent can watch both a shared inbox and a scheduled trigger, applying the same SOP logic regardless of which source fired. Each additional source is tested individually before go-live.
### The steps the agent follows
SOP logic is the procedural core of the agent — the ordered set of steps it executes once an input arrives. This is not open-ended reasoning; it is a documented procedure that the agent follows faithfully, in the sequence you approve.
SOP logic can include:
Steps that always execute in a fixed order, one after another. Used when the process is the same every time the input arrives.
*Example: receive form → validate required fields → create record → send acknowledgement*
Decision points where the agent evaluates a condition and takes different paths depending on the result. The conditions and their outcomes are defined by you during the design phase.
*Example: if the submitted amount exceeds the approval threshold → escalate to manager; if below threshold → approve automatically and log*
Steps where the agent retrieves information from a connected system before proceeding. The agent does not guess — it reads the authoritative source and acts on what it finds.
*Example: before sending a reply, look up the existing record in the job management system to confirm current status*
Steps that repeat at a defined interval until a condition is met or a maximum attempt count is reached. Used when the agent must wait for a response or a state change in an external system.
*Example: check whether a delivery confirmation has been received every four hours — stop after three attempts and escalate if not received*
Every SOP logic sequence is documented in plain language and reviewed by you before build begins. See [Workflows](/agent-structure/workflows) for how these steps are assembled into a full process.
### When the agent hands off to a human
Escalation rules define the conditions under which the agent stops processing and routes the item to a person. They are hard constraints — the agent will always escalate when a rule is met, regardless of what it might otherwise be capable of doing.
Escalation rules are not optional. Every agent we build ships with a baseline set. You can add more, but you cannot remove the baseline rules entirely. These rules are what keep authority boundaries intact.
**Common escalation triggers:**
| Rule | What it prevents | Example |
| ---------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Authority threshold** | Agent acts beyond its defined decision authority | Any request involving a value above the approved limit is referred to the authorising manager |
| **Complaint severity** | Agent handles a dispute it is not authorised to resolve | Any submission rated as a formal complaint is routed to Department A's complaints handler immediately |
| **Unrecognised input** | Agent applies the wrong SOP to an unknown case | Any item that does not match a defined input type is held in a review queue for a human to classify |
| **Mandatory human sign-off** | Agent takes irreversible action without authorisation | Steps involving deletion, financial commitment, or external communication on sensitive matters require explicit sign-off before proceeding |
| **System unavailability** | Agent proceeds with incomplete data | If a required lookup system is unreachable, the agent holds the item and notifies the responsible team |
During the design phase, we work through your specific processes to define escalation rules that reflect your authority structure and risk tolerance.
### How the agent sends results onward
Outbound interfaces are the channels through which the agent delivers its outputs — whether that is a message to a person, an update written to a system, or a file placed in a designated location.
The agent creates or updates a record in a connected platform — for example, logging a completed step, updating a status field, or adding a note to an existing record.
**Used for:** keeping connected systems current without manual data entry
The agent sends a formatted message to a person or team — via email, a shared inbox, or an internal channel — carrying the output, summary, or action request it has prepared.
**Used for:** acknowledgements, approval requests, exception notifications
The agent places a file — a compiled report, a formatted document, a processed record — into a designated folder or sends it as an attachment.
**Used for:** report delivery, document handoff, archival outputs
When an escalation rule fires, the agent routes the item — with its current context and a plain-language summary — to the correct person, queue, or team.
**Used for:** handoffs to human reviewers, approval workflows, exception handling
All outbound actions are logged with a timestamp and the SOP step that produced them. This gives you a complete audit trail of what the agent did, when, and why. See [ERP & Legacy Systems](/agent-structure/integrations) for how write actions connect to your existing platforms.
## How the components work together
In a live agent, all five components operate as a coordinated system. The **role definition** sets the boundaries. **Input sources** provide the trigger. **SOP logic** executes the procedure step by step. **Escalation rules** enforce authority limits throughout. **Outbound interfaces** deliver the results.
No component is optional — removing any one of them produces an agent without a defined purpose, without a way to start, without a procedure to follow, without limits, or without a way to deliver its outputs.
During your design review, you will receive a component map for your agent — a one-page summary showing exactly which input sources, SOP steps, escalation rules, and outbound interfaces are configured. This document is your reference for the life of the agent and the starting point for any future change request.
## Next steps
See how these components are assembled into a step-by-step SOP that drives your agent's behaviour from trigger to output.
Learn how input sources and outbound interfaces connect to the platforms and systems your business already runs on.