> ## 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.

# M9TZ Agent Blueprint

> A reusable architecture for department-based, SOP-driven AI agents. One agent per department, one VM per runtime, structured JSON messaging between them.

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.

<CardGroup cols={2}>
  <Card title="What is an agent?" icon="robot" href="/what-is-an-agent">
    How the blueprint defines an agent: process-bound, SOP-driven, and scoped to one department or function.
  </Card>

  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Set up your first department runtime on VM-1 — one department, one agent, one validated foundation.
  </Card>

  <Card title="Agent structure" icon="sitemap" href="/agent-structure/overview">
    The building blocks of every agent: role definition, input sources, SOP logic, escalation rules, and outbound interfaces.
  </Card>

  <Card title="Department playbooks" icon="book-open" href="/playbooks/customer-support">
    Worked examples showing how the blueprint pattern applies to four common department types.
  </Card>
</CardGroup>

## How the blueprint works

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.

<CardGroup cols={2}>
  <Card title="Customer-facing department" icon="envelope-open-text" href="/playbooks/customer-support">
    Inbound communication handling: classification, resolution, escalation, and outbound interfaces for a customer-facing function.
  </Card>

  <Card title="Sales / pipeline department" icon="filter" href="/playbooks/lead-generation">
    Inbound interest qualification: scoring logic, routing criteria, outbound messaging, and handoff rules for a pipeline function.
  </Card>

  <Card title="Back-office / accounting department" icon="receipt" href="/playbooks/operations">
    Financial document processing: validation, approval routing, audit trail, and ERP integration for an accounting function.
  </Card>

  <Card title="Operations / logistics department" icon="gears" href="/playbooks/scheduling">
    Threshold monitoring, inter-department coordination, and exception escalation for an operations or logistics function.
  </Card>
</CardGroup>

<Tip>
  New here? Start with [What is an agent?](/what-is-an-agent) for the foundational definition, then read the [Quickstart](/quickstart) to see what the first deployment step looks like in practice.
</Tip>