> ## 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.
# Design Phase: From Discovery to an Approved Agent Blueprint
> Learn what the Agent Design Document contains, how the collaborative review process works, and which decisions only you can make before build begins.
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.
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.
A step-by-step visual map of everything the agent does from trigger to completion, including branches for edge cases.
Every external system the agent connects to — your CRM, inbox, helpdesk, database, or API — and what actions it takes in each.
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.
The exact conditions under which the agent escalates to a human team member, and how that handoff is communicated.
The measurable outcomes used to evaluate whether the agent is performing as intended post-launch.
**Agent Name:** Support Triage Assistant
**Trigger:** Inbound email received at [support@yourcompany.com](mailto:support@yourcompany.com)
**Workflow 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 Base
**Guardrails:**
* 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.
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.
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.
We address every comment, update the document, and explain any decisions that have constraints behind them (technical limits, cost implications, etc.).
The review cycle repeats as many times as needed. Most designs are approved after one or two rounds.
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?
For every action the agent can take, you choose whether it acts immediately or waits for a human to confirm. A lower-stakes action (tagging a contact) might be fully automatic. A higher-stakes action (sending a refund) might require approval.
You set the conditions under which the agent hands off to a human. These could be based on customer tier, sentiment score, dollar amount, number of retries, or any other signal that matters to your business.
You decide what the agent is explicitly not allowed to handle. Clear scope boundaries reduce risk and make the agent easier to trust.
### 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](/blueprint/handoff) process.
Once design is approved, we move into the [Build phase](/blueprint/build).