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

# How a Consulting Engagement Proceeds

> A conceptual overview of how an M9TZ Agent Blueprint consulting engagement is structured — from initial conversation through implementation and handoff.

Every consulting engagement is scoped individually before any design or build work begins. There are no fixed packages applied uniformly — the engagement is shaped by your organisation's situation. What this page describes is how that process unfolds conceptually. The specifics of any given engagement are determined during [Discovery](/blueprint/discovery).

<Note>
  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](/consulting/scope-and-boundaries) for a precise description of what is covered by the documentation and what requires a consulting engagement.
</Note>

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

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

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

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

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

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

***

## What each phase produces

<CardGroup cols={2}>
  <Card title="Discovery Summary" icon="file-lines">
    A written record of your workflows, goals, constraints, and open questions captured during the discovery phase. This is the foundation for everything that follows.
  </Card>

  <Card title="Scoping analysis" icon="list-check">
    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.
  </Card>

  <Card title="Agent Design Document" icon="file-code">
    A detailed specification of the agent's triggers, logic, integration points, and escalation paths. Approved in writing by both sides before build begins.
  </Card>

  <Card title="Working implementation" icon="flask">
    A fully built and tested agent running in a staging environment, reviewed by your team before moving to production.
  </Card>

  <Card title="Production deployment" icon="server">
    The agent deployed and verified in your production environment, with an initial monitoring period to confirm stable operation.
  </Card>

  <Card title="Handoff package" icon="flag-checkered">
    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.
  </Card>
</CardGroup>

***

## Responsibilities

A good engagement is a working partnership. The phases above only run smoothly when both sides hold up their end.

<Tabs>
  <Tab title="Your 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
  </Tab>

  <Tab title="Our responsibilities">
    * **Scope accurately** — the Discovery phase is how we avoid committing to work we do not fully understand; we raise open questions before the proposal, not after
    * **Communicate blockers early** — if something threatens the timeline or the agreed scope, we raise it as soon as it is visible
    * **Document everything** — every decision, every integration point, every edge case is written down so your team is not dependent on us after handoff
    * **Build for independence** — the agent and its documentation are structured so your team can operate and maintain the system without requiring ongoing consulting support
  </Tab>
</Tabs>

***

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

<CardGroup cols={2}>
  <Card title="Scoping" icon="ruler" href="/consulting/scoping">
    What goes into determining the scope of an engagement — departments, complexity, existing systems, integration needs.
  </Card>

  <Card title="Scope & Boundaries" icon="circle-half-stroke" href="/consulting/scope-and-boundaries">
    The precise line between what this documentation covers for free and what requires a consulting engagement.
  </Card>
</CardGroup>
