Skip to main content
Discovery tells us what to build. Design tells us exactly how to build it. In this phase, we take everything learned during the discovery workshop and translate it into a concrete, reviewable specification — the Agent Design Document — that your team approves before a single line of code is written.

​
From generic blueprint to your structure

The M9TZ Agent Blueprint provides a generic, department-based template: a model architecture covering how departments are separated, how roles and SOPs are defined within each department, how agents interface with each other, and how the system as a whole is structured. This template is fully documented on this site and is the same starting point for every engagement. The design phase is where that generic template becomes a structure that reflects your actual company — your departments, your roles, your existing systems, and the way decisions actually flow through your organisation. That translation is not a self-service exercise. It happens through a consulting conversation: we map what we learned during discovery onto the template, identify where the generic structure fits cleanly and where it needs to be adapted, and produce an agent design that mirrors the real shape of your business rather than a hypothetical one. Adapting the blueprint template to a real organisational structure — choosing which departments get agents, defining the SOPs that match your actual processes, scoping the interfaces to the systems your teams already use — is the core of the paid engagement. The template gives both sides a common language and a proven starting point; the consulting conversation is what makes it yours.

​
The Agent Design Document

The Agent Design Document is the blueprint for your agent. It captures every meaningful decision about how the agent behaves, so there are no surprises during build.

Agent Name & Trigger

What the agent is called, what event kicks it off (an inbound email, a form submission, a scheduled time), and under what conditions it activates.

Workflow Diagram

A step-by-step visual map of everything the agent does from trigger to completion, including branches for edge cases.

Tool List

Every external system the agent connects to — your CRM, inbox, helpdesk, database, or API — and what actions it takes in each.

Guardrails

Rules that constrain the agent’s behaviour: what it’s never allowed to do, what requires a human in the loop, and how it handles ambiguous situations.

Handoff Rules

The exact conditions under which the agent escalates to a human team member, and how that handoff is communicated.

Success Metrics

The measurable outcomes used to evaluate whether the agent is performing as intended post-launch.
Agent Name: Support Triage AssistantTrigger: Inbound email received at support@yourcompany.comWorkflow Summary:
  1. Agent reads the incoming email and classifies it into one of five categories: billing, technical issue, feature request, general enquiry, or other.
  2. For billing and technical issue categories, the agent checks the sender’s account status in the CRM.
  3. If the account is active and the issue matches a known resolution in the knowledge base, the agent drafts a response and queues it for 15-minute human review before sending.
  4. If the issue is unrecognised or the account is flagged, the agent creates a ticket in the helpdesk and notifies the on-call team member via your team messaging tool.
  5. All other categories receive an automated acknowledgement and are added to the weekly digest for human review.
Tools Connected: Your email system, your CRM, your ticketing system, your team messaging tool, Knowledge BaseGuardrails:
  • The agent never issues refunds or account credits autonomously.
  • The agent never sends an external reply without a human review step for billing-related threads.
  • If confidence in classification is below 80%, the agent defaults to the human review queue.
Handoff Rules: Escalate to human if: (a) the customer has replied more than twice without resolution, (b) the email contains legal or regulatory language, or (c) the account is marked as enterprise tier.Success Metrics: Average first-response time reduced from 6 hours to under 30 minutes; human review queue volume reduced by 40% within 60 days of launch.

​
How Design Review Works

Once we deliver the Agent Design Document, the review process is collaborative and iterative.
1

Receive the document

We share the Agent Design Document with your team via a shared document link. It’s written in plain language — no technical background required to review it.
2

Leave comments and questions

Use inline comments to flag anything that doesn’t match your expectations: a workflow step that’s wrong, a guardrail that’s too restrictive, or a tool that’s missing.
3

We revise and respond

We address every comment, update the document, and explain any decisions that have constraints behind them (technical limits, cost implications, etc.).
4

Repeat until you're satisfied

The review cycle repeats as many times as needed. Most designs are approved after one or two rounds.
5

Formal sign-off

You give explicit written approval — this is the gate that opens the build phase.

​
Decisions That Require Your Input

Some design choices can only be made by you. We’ll prompt you for these during review, but it helps to think about them in advance.
You decide the exact language the agent uses when communicating with customers or colleagues. We’ll propose draft copy, but the final wording is yours. Consider: is the tone formal or conversational? Does it match your brand voice?

​
Common Design Decisions to Think Through

  • Reply immediately or queue for review? Immediate replies are faster but carry more risk. Queued replies give you a safety net while you build confidence in the agent.
  • Handle refunds or only flag them? Most teams start with flagging and move to autonomous handling once the agent has a track record.
  • What tone should the agent use? The agent’s voice is part of your brand. A mismatch between how your team speaks and how the agent speaks will be noticeable to customers.

​
Design Sign-Off

Formal design approval is your last opportunity to make large scope changes without additional cost. Once build begins, changes to workflow logic, tool integrations, or trigger types are treated as change requests and may affect your timeline and budget.
Sign-off doesn’t mean the agent is locked forever — it means the agreed design is what gets built. After launch, you can always request changes through the Handoff phase process. Once design is approved, we move into the Build phase.