Skip to main content
The M9TZ Agent Blueprint is a reusable architecture pattern for deploying AI agents inside an organisation. The central idea is straightforward: each department gets its own agent runtime, scoped to that department’s documented operating procedures. Agents do not share state. They communicate through defined JSON message interfaces. The infrastructure is built up one department at a time, validated at each stage before expanding. The blueprint is a concept and an architecture, not a product. This site documents the full pattern — what an agent is, how it is structured, how departments connect, and how legacy systems attach. Applying the blueprint to a specific organisation’s systems and workflows is the paid consulting work. For a clear explanation of what is documented here versus what an engagement covers, see Scope & Boundaries.

​
What the blueprint covers

Agent definition

An agent in this system is process-bound and SOP-driven — scoped to one department, executing documented procedures, and escalating to a human when a case falls outside its defined scope.

Staged rollout model

Departments are brought online sequentially. Each phase validates before the next begins. You start with one department on one VM and expand only when the foundation is solid.

Structured inter-department messaging

Departments coordinate through defined JSON message interfaces rather than direct calls or shared databases. Input formats, output formats, and routing rules are agreed before any two runtimes connect.

Adapter patterns for external systems

ERP systems, CRM platforms, and legacy tools attach through purpose-built adapters at defined input and output points. The agent runtimes do not change when an external system is added or replaced.

​
Who this is for

The blueprint is relevant to people designing or evaluating department-level AI automation in organisations where consistency, auditability, and controlled authority matter more than general-purpose AI flexibility.

Process designers and architects

You are responsible for how work flows between departments. The blueprint gives you a pattern for where agents fit, how they communicate, and how the system scales without becoming unmanageable.

Teams evaluating AI for specific workflows

You have a specific, high-volume workflow you want to automate. The blueprint shows how to scope that automation to a single department, define its SOPs, and validate it before connecting anything else.

Technical leads overseeing implementation

You are assessing feasibility and integration complexity. The blueprint covers runtime structure, message contracts, ERP/CRM adapter patterns, and the staged rollout model in enough detail to make that assessment.

Operations and compliance stakeholders

You need automation that produces consistent, traceable outcomes — not open-ended AI reasoning. The SOP-driven model is designed around auditability and controlled authority from the ground up.

​
What the staged model means in practice

A staged rollout is not just a project management preference — it is a structural property of the blueprint. Each department agent is independently deployable, independently testable, and independently maintainable. Connecting departments through message interfaces rather than direct calls means:
  • A problem in one department’s agent does not propagate to others
  • A new department can be added without modifying existing runtimes
  • An external system (your ERP, your CRM) can be replaced by updating its adapter, not by rebuilding the agents that consume its data
The Quickstart walks through what the first deployment step looks like in practice. The department playbooks show how the pattern applies to four common department types.

​
What this site does not cover

The documentation describes the pattern at a level of detail sufficient to understand it, evaluate it, and prepare for an implementation. It does not cover:
  • The specific procedures your departments should follow (those are your SOPs, not the blueprint’s)
  • The specific tools, platforms, or credentials used in any real deployment (those are engagement-specific)
  • Configuration of real systems or step-by-step build instructions for a live environment
Consulting engagements cover the scoping, design, and implementation work of applying the blueprint to a specific organisation. See the Consulting Process for how that works.

​
Where to go next

What is an agent?

The foundational definition: what an agent is, what it is composed of, and why the SOP-driven model matters for process-critical workflows.

Quickstart

The first practical step: one department, one VM, one validated agent runtime. What to define first and what to check before moving on.

Agent structure

How an agent is constructed — the three-layer model, the components at each layer, and how they fit together in a running deployment.

Consulting process

How engagements are scoped and structured — phases, deliverables, responsibilities, and what both sides commit to.