Skip to main content
These are the questions that come up most often when organisations are evaluating the blueprint or considering a consulting engagement. If something is not covered here, start a discovery conversation and ask directly.
Yes. The entire M9TZ Agent Blueprint — the architecture, the staged communication model, the integration patterns, the department and role structure — is documented on this site and free to read, understand, and adopt. There is no registration, no paywall, and no licence required to use the concepts described here.What the documentation cannot provide is the application of that architecture to your specific organisation. That is what a consulting engagement covers. See Scope & Boundaries for a precise description of where the line sits.
Consulting work is paid. That includes:
  • Organisational analysis — systematically mapping your departments, processes, people, and existing systems against the blueprint structure
  • Designing the agent for your specific workflows and constraints
  • Building real integrations to your existing systems
  • Managing the staged rollout in your environment
  • Ongoing support and maintenance after deployment
The blueprint tells you how a well-structured agent system is designed. The consulting engagement is what turns that understanding into a working system in your organisation. There is no published pricing on this site — scope varies enough between organisations that a meaningful figure requires understanding your specific situation first.
Scope is determined during the Discovery phase — a structured conversation that examines your organisation’s departments and processes, the workflows targeted for automation, the existing systems that need integration, and the state of your current process documentation.The output of Discovery is a written scoping analysis that forms the basis of an individually tailored proposal. No proposal is issued and no build work begins before scope is agreed in writing by both sides.See the Scoping page for a detailed breakdown of what the scoping process examines.
Yes. The blueprint is technically reproducible by anyone with the relevant skills. The documentation gives a complete picture of the architecture, the staged build approach, the integration patterns, and the department structure. A technically capable team can read this documentation and build from it without engaging us.What the consulting engagement provides — and what the documentation cannot substitute for — is the work of applying the blueprint to your specific organisation: capturing your actual processes, mapping your departments onto the structure, building integrations to your existing systems, and managing the rollout. That work requires direct engagement with your team and cannot be done from documentation alone.
No. The Discovery conversation is conducted in plain language — you describe your business workflows, your team structure, and your existing systems as you would to any consultant. There is no requirement to understand the technical implementation.Your role is to provide accurate information about how your organisation works. The technical translation of that information into an agent design is what the consulting engagement handles.
Duration depends on scope — specifically the number of departments involved, the complexity of the workflows, the condition of the systems that need integration, and how quickly your team can participate in reviews and approvals. There are no standard timelines published on this site because meaningful estimates require understanding your specific situation first.A Discovery conversation is the fastest way to arrive at a realistic picture of what an engagement would involve and how long it would take.
The blueprint uses an adapter pattern that separates the agent’s internal logic from the external systems it connects to. In principle, any system with a documented interface can be integrated using this pattern. The integration effort depends on the quality and completeness of that interface, not on whether a particular product is on a supported list.Integration feasibility for your specific systems is assessed during Discovery. If a system presents unusual constraints — a legacy architecture, a proprietary interface, limited documentation — that is identified early and reflected in the scope, not discovered mid-build.
Yes — all automated systems can produce incorrect outputs. The blueprint addresses this through design rather than by avoiding automation:
  • Defined scope boundaries — the agent operates within an explicitly bounded set of actions; requests outside that boundary are escalated rather than acted on
  • Human escalation paths — the agent is designed to recognise when it should stop and hand off to a person, rather than proceeding under uncertainty
  • Confidence thresholds — for decision points where the agent is not sufficiently confident, it flags for review rather than acting
These are design principles applied to every agent built under the blueprint. The specific thresholds and escalation conditions are defined during the design phase based on the risk profile of each workflow.
You do. At handoff, all code, configuration, documentation, and credentials are transferred to you. The engagement is structured so your team can operate and maintain the system independently after handoff — continued consulting engagement is not required for the agent to keep running.Data processed by the agent moves between your systems according to those systems’ own data handling policies. The agent does not route data through consulting infrastructure.
Yes. The blueprint is designed with expansion in mind. Agents built in an initial engagement can be structured so that later additions — new triggers, additional workflow branches, coordination with agents in other departments — connect cleanly rather than requiring a rebuild.If expansion is a likely direction, raising it during Discovery means the initial design can accommodate it. The scope of a follow-on engagement is determined the same way as the first: through a Discovery conversation before any design or build work begins.
The first step is a discovery conversation — a structured discussion where we learn about your organisation, the workflows you want to automate, and the systems involved. This conversation is where scope begins to take shape.There is no obligation following the discovery conversation. If the scoping analysis and proposal that follow make sense for your situation, the engagement proceeds. If not, you leave with a clearer understanding of what an implementation would involve.Start a discovery conversation →

Scope & Boundaries

A precise description of what is documented freely on this site and what requires a consulting engagement.

Engagement model

How an engagement proceeds from the first conversation through implementation and handoff.