The M9TZ Agent Blueprint — the architecture, the staged model, the integration patterns — is fully documented on this site and free to read and adopt. What a consulting engagement provides is the application of that architecture to your specific organisation. See Scope & Boundaries for a precise description of what is covered by the documentation and what requires a consulting engagement.
How an engagement proceeds
Engagements follow a consistent sequence of phases. Each phase produces a written output that informs the next, so both sides remain aligned and nothing moves forward until there is explicit agreement.1
Discovery conversation
The engagement begins with a structured conversation about your organisation — what departments are involved, what processes are targeted for automation, what existing systems are in use, and where the constraints lie. This is not a sales call; it is the first piece of actual work. The output is a Discovery Summary: a written record of what was learned, what was assumed, and what remains open.
2
Scoping and proposal
Based on the Discovery Summary, the engagement scope is defined in writing — which departments, which workflows, which integration points, and what the build covers. This scoping analysis forms the basis of an individually tailored proposal. No proposal is issued before scoping is complete, and no build work begins before the proposal is agreed.
3
Design
The agreed scope is translated into a detailed Agent Design Document covering the agent’s triggers, decision logic, integration points, escalation paths, and operating boundaries. Both sides review and approve this document before any implementation begins. Changes requested after approval are handled as formal scope changes.
4
Implementation
The agent is built against the approved design in a staging environment. You are given access to observe its behaviour before it moves to production. The implementation phase is complete when both sides agree the agent behaves as specified.
5
Deployment and handoff
The agent is deployed to your production environment and monitored through an initial operating period. At handoff, all code, configuration, credentials, and documentation are transferred to you. The goal is that your team can operate the agent independently after handoff — not that continued engagement is required.
What each phase produces
Discovery Summary
A written record of your workflows, goals, constraints, and open questions captured during the discovery phase. This is the foundation for everything that follows.
Scoping analysis
A structured assessment of the departments involved, the complexity of the work, the integration requirements, and the shape of the engagement — produced before any proposal is made.
Agent Design Document
A detailed specification of the agent’s triggers, logic, integration points, and escalation paths. Approved in writing by both sides before build begins.
Working implementation
A fully built and tested agent running in a staging environment, reviewed by your team before moving to production.
Production deployment
The agent deployed and verified in your production environment, with an initial monitoring period to confirm stable operation.
Handoff package
All documentation, code, credentials, and configuration transferred to your team — structured so the agent can be understood, managed, and maintained without ongoing dependence on the consulting engagement.
Responsibilities
A good engagement is a working partnership. The phases above only run smoothly when both sides hold up their end.- Your responsibilities
- Our responsibilities
- Participate in Discovery — make the right people available so workflows, systems, and constraints can be understood accurately
- Review design outputs — read and approve the Agent Design Document before build begins; the design cannot be locked until you have confirmed it reflects your intent
- Authorise integrations — provide the credentials and permissions the agent needs to connect to your systems
- Give timely feedback — respond to milestone reviews so the engagement does not stall waiting for approvals
- Test in staging — exercise the agent against realistic cases before approving the move to production
Scope changes
The engagement is agreed before build begins, and changes to that agreement are handled formally — not informally absorbed or silently deferred. If something changes after the design is approved — a new integration requirement, a different trigger, a workflow branch that was not in scope — that is a scope change. It is raised in writing, assessed for its effect on the engagement, and agreed before any additional work proceeds. Neither side is obligated to absorb unplanned work; both sides benefit from clarity about what is and is not included.Scoping
What goes into determining the scope of an engagement — departments, complexity, existing systems, integration needs.
Scope & Boundaries
The precise line between what this documentation covers for free and what requires a consulting engagement.