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

# Build Phase: How We Construct and Test Your AI Agent

> Understand what our team builds during the agent build phase, what we need from you, how staging works, and what can affect your timeline and scope.

With an approved design in hand, our engineering team gets to work. The build phase is the most technically intensive part of the process — and the one that requires the least from you day-to-day. You don't need any technical skills to participate. Your role is to stay available for the specific questions and authorisations that only you can provide.

## What Our Team Does During Build

Building your agent involves more than writing code. Every layer of the system needs to be constructed, connected, and verified before it reaches you.

<Steps>
  <Step title="Implement the agent logic">
    Our engineers translate the approved workflow diagram into working code — each step, branch, and decision point in the design becomes a functioning part of the agent.
  </Step>

  <Step title="Connect your tools and integrations">
    We wire up every tool on the approved tool list: your CRM, inbox, helpdesk, database, or any API in the design. Each connection is tested independently before the full workflow runs.
  </Step>

  <Step title="Configure guardrails">
    The constraints and rules defined in the design are implemented and tested specifically for edge cases — the scenarios where guardrails matter most.
  </Step>

  <Step title="Run the internal test suite">
    Before you see the agent, we run a structured set of tests covering expected inputs, edge cases, error handling, and escalation paths. The agent doesn't move to staging until it passes.
  </Step>
</Steps>

## Your Role During Build

You won't be heads-down in the build, but there are moments where we'll need you to act. Delays in these areas are the most common cause of extended timelines.

<CardGroup cols={3}>
  <Card title="Authorise Integrations" icon="key">
    Some tools — such as your CRM, your inbox, or your messaging platform — require you to provide credentials or grant access permissions. We'll give you clear, step-by-step instructions when this comes up.
  </Card>

  <Card title="Provide Sample Data" icon="database">
    Real examples from your business make testing far more reliable than synthetic data. We may ask for anonymised email threads, form submissions, or CRM records to use in our test suite.
  </Card>

  <Card title="Clarify Edge Cases" icon="circle-question">
    Build surfaces questions the design didn't anticipate. When they come up, we'll flag them clearly — usually a short async message — so you can give a quick decision and we can keep moving.
  </Card>
</CardGroup>

<Tip>
  Designate one person on your team as the build-phase point of contact. A single decision-maker means faster responses and fewer mixed signals when edge-case questions come up.
</Tip>

## The Staging Environment

Before we hand anything over for your review, we deploy the agent to a **staging environment** — a sandboxed version of your production setup.

<Note>
  The staging environment is fully isolated. It connects to test versions of your tools (or read-only connections where test environments aren't available), so you can interact with the agent freely without any risk to live data, real customers, or production systems.
</Note>

During staging, you'll receive a link where you can:

* Trigger the agent yourself using real or sample inputs
* Step through each part of the workflow and verify it matches the approved design
* Test escalation and handoff scenarios
* Flag anything that doesn't feel right before it goes anywhere near production

We'll walk through staging together on a shared call. If anything needs adjusting, we address it before moving to the [Deploy phase](/blueprint/deploy).

## Build Timeline

<CardGroup cols={2}>
  <Card title="Standard Build" icon="gauge">
    **2–3 weeks** for agents with a single trigger, a linear workflow, and 2–4 tool integrations. This covers the majority of first-agent builds.
  </Card>

  <Card title="Complex Build" icon="gauge-high">
    **3–4+ weeks** for agents with multiple triggers, branching logic, five or more integrations, or custom API connections that require additional development work.
  </Card>
</CardGroup>

## What Can Change Scope During Build

Some changes are expected and handled as part of the build. Others represent meaningful additions to the agreed scope and are treated formally as **change requests**.

<Tabs>
  <Tab title="Handled Within Build">
    * Minor wording adjustments to agent copy
    * Tweaks to escalation thresholds within the same logic structure
    * Fixing edge cases that surface during internal testing
    * Adjusting how an existing tool integration behaves
  </Tab>

  <Tab title="Change Requests">
    * Adding a new tool or integration not in the original design
    * Changing the core workflow logic significantly (new branches, new steps)
    * Adding a new trigger type (e.g., the agent was designed to respond to emails, and you now want it to also respond to form submissions)
    * Any addition that meaningfully increases the scope of the original design sign-off
  </Tab>
</Tabs>

<Warning>
  Change requests during build come with a revised timeline and cost estimate. We'll always surface these clearly and get your approval before proceeding — nothing is added to scope without your sign-off.
</Warning>

Once you've reviewed and approved the agent in staging, we move into the [Deploy phase](/blueprint/deploy).