Skip to main content
An agent in the M9TZ Agent Blueprint is not a general-purpose chatbot. It is a software service that is bound to a single department or business function, executes predefined standard operating procedures (SOPs), and escalates to a human whenever a case falls outside its defined scope. Every decision the agent makes is traceable to a step in a documented procedure — not to open-ended reasoning.

​
Definition

An agent is:
  • Process-bound — scoped to one department or function (for example, the accounting function, the order-processing function, or a compliance-sensitive intake workflow). It does not act across boundaries it was not assigned.
  • SOP-driven — it follows a documented, version-controlled set of operating procedures. The procedures specify the exact steps, the decision criteria at each branch, the authority limits of the agent, and the conditions under which it must stop and hand off to a human.
  • Escalation-first when uncertain — when an input does not match any case covered by its SOPs, the agent does not improvise. It packages what it knows, surfaces the case to the appropriate human or escalation queue, and stops acting until a decision is made.

​
Why this design matters for process-critical workflows

General-purpose AI systems are optimised for breadth and creativity. That is useful for open-ended tasks. It is a liability for workflows where the organisation requires consistent, auditable outcomes — accounting reconciliation, order exception handling, compliance-gated approvals, and similar functions. The agent-as-SOP-executor model offers a different set of guarantees:
  • Predictability — given the same input, the agent follows the same procedure every time. There is no variance introduced by probabilistic improvisation.
  • Auditability — because every action traces back to a specific SOP step, you can reconstruct exactly what the agent did and why.
  • Controlled authority — the agent’s authority limits are declared in its role definition, not inferred at runtime. The agent knows what it can do, what it must escalate, and what it must never do.
  • Safe failure — when a case falls outside scope, the outcome is escalation, not a best-effort guess. Uncertainty surfaces rather than propagates.
For workflows where a wrong action carries regulatory, financial, or customer-relationship consequences, escalating rather than improvising is the correct default.

​
What an agent is composed of

Every agent in the blueprint has four generic parts regardless of the department it serves.

​
Role definition

The role definition establishes the agent’s identity within the system:
  • Assigned function — the department or business process the agent is responsible for (for example, “invoice processing for the accounting function” or “inbound order triage”).
  • Task list — the specific tasks the agent is authorised to perform, described at the level of granularity needed to write a testable SOP.
  • Authority limits — the actions the agent may take autonomously, the actions that require co-authorisation, and the actions that are categorically outside its scope.
  • Escalation rules — the conditions under which the agent must hand off a case, the format of the escalation message, and the channel or queue it routes to.

​
Inputs the agent watches

An agent monitors one or more defined input sources. The input type depends on the function:
  • A shared inbox (email or a message channel) used by a department
  • A file drop location or intake queue in a back-office or ERP system
  • A structured event feed from an upstream system (for example, a new record created in your order management system)
  • A scheduled trigger (the agent wakes at a defined interval to process queued work)
The set of inputs is declared in the agent’s configuration. The agent does not monitor sources it was not assigned.

​
The SOPs it executes

SOPs are the core of the agent. Each SOP is a numbered, branching procedure that specifies:
  1. The trigger condition — what input state or event causes this procedure to begin
  2. The steps in sequence — what the agent reads, extracts, computes, or looks up at each stage
  3. The decision branches — what criteria determine which path the agent takes
  4. The outputs or actions at each terminal step — what the agent writes, sends, or updates
  5. The escalation exits — at which points the agent must stop and hand off, and what information it must include in the handoff
SOPs are written before the agent is built and reviewed as part of the design process. An agent does not take actions that are not specified in at least one SOP.

​
Outbound messages and interfaces

After executing a procedure, the agent communicates results in one of two directions:
  • To other department agents — structured messages (typically JSON payloads) sent to a defined channel or queue, following the inter-agent messaging contract for the deployment. A downstream agent for a different function consumes these messages and acts on them within its own scope.
  • To humans — escalation notices, approval requests, status updates, or exception reports routed to the appropriate inbox, queue, or notification channel.
The format and routing of every outbound message type is declared in the agent’s role definition.

​
Modeling multiple roles within one department

A common design question is whether to create one agent per role within a department, or to consolidate multiple roles into a single agent runtime. The blueprint’s general principle: multiple roles within one department can be modeled as multiple SOPs handled by the same agent runtime rather than as separate deployed instances. The reasoning:
  • Roles within the same department share context (they access the same data, the same internal tools, and operate under the same authority domain). Keeping them in one runtime avoids duplicating that context and reduces the overhead of inter-agent coordination for work that is inherently intra-department.
  • Separation into distinct agent instances makes sense at department or function boundaries, where authority domains, tool access, and escalation paths differ materially. Within a single function, SOP separation inside one runtime achieves the same logical isolation at lower operational cost.
  • The SOP structure itself enforces the role boundary. Each SOP has its own trigger, its own authority limits, and its own escalation path. Splitting it into a separate instance does not add safety — it adds latency and coordination complexity.
This principle keeps the agent count proportional to the number of distinct departments or functions in scope, not to the number of sub-tasks within each one.

​
Relationship to the broader architecture

Agents are the unit of work in a staged, department-based architecture. Each agent:
  • Owns one domain of the overall business process
  • Communicates with other agents only through defined message interfaces (not by sharing internal state or calling each other directly)
  • Has a clear upstream (what triggers it) and a clear downstream (what it produces or whom it notifies)
The result is a system where each department’s automation is independently understandable, independently testable, and independently maintainable — while the departments still coordinate as a connected whole through the message layer.
The Introduction page covers the overall staged architecture and how department agents fit together. This page covers what a single agent is and how it is defined. For the components that make up an agent at implementation level, see Agent Structure.