Skip to main content
The M9TZ Agent Blueprint is an architecture pattern for deploying AI agents inside an organisation. Each department gets its own agent runtime, scoped to that department’s documented procedures. Agents communicate through structured JSON messages rather than sharing internal state. The system is built up in stages — one department at a time — so each phase is validated before the next is added. This site documents the full blueprint: what an agent is, how it is structured, how departments connect, how legacy systems attach, and how the staged rollout model works. Reading and applying the documentation is free. Paid consulting covers the work of mapping the blueprint to your specific systems and running the implementation.

What is an agent?

How the blueprint defines an agent: process-bound, SOP-driven, and scoped to one department or function.

Quickstart

Set up your first department runtime on VM-1 — one department, one agent, one validated foundation.

Agent structure

The building blocks of every agent: role definition, input sources, SOP logic, escalation rules, and outbound interfaces.

Department playbooks

Worked examples showing how the blueprint pattern applies to four common department types.

​
How the blueprint works

The architecture follows a staged rollout. You do not connect everything at once.
1

Start with one department

Choose the department with the clearest, most repetitive workload. Document its procedures as SOPs. Deploy one agent runtime on a dedicated machine (VM-1). Define the input format it expects and the output format it produces.
2

Validate before expanding

Run the first agent against real inputs. Review the outputs manually before any downstream system consumes them. Confirm the SOP coverage, fix gaps, and establish that the common case is handled correctly and exceptions are surfaced rather than silently dropped.
3

Add a second department

Once VM-1 is stable, bring up VM-2 using the same pattern. Define the second department’s SOPs, input, and output independently. At this stage the two runtimes are still isolated — they do not yet exchange messages.
4

Connect departments through structured messages

Link the runtimes through a shared message channel or queue. The output of one department becomes the input of another. The interface contract — field names, data types, expected values — is agreed before either side connects.
5

Attach adapters for external systems

Once the inter-department messaging is stable, connect your existing systems: ERP adapters, CRM connectors, legacy system bridges. These attach at the defined input and output points without changing the agent runtimes themselves.

​
Department playbooks

The playbooks show how the blueprint pattern applies to four common department types. Each one covers role definition, SOPs, input and output interfaces, escalation rules, and integration points. Use them as references when mapping the blueprint to your own departments.

Customer-facing department

Inbound communication handling: classification, resolution, escalation, and outbound interfaces for a customer-facing function.

Sales / pipeline department

Inbound interest qualification: scoring logic, routing criteria, outbound messaging, and handoff rules for a pipeline function.

Back-office / accounting department

Financial document processing: validation, approval routing, audit trail, and ERP integration for an accounting function.

Operations / logistics department

Threshold monitoring, inter-department coordination, and exception escalation for an operations or logistics function.
New here? Start with What is an agent? for the foundational definition, then read the Quickstart to see what the first deployment step looks like in practice.