INITE Protocol: The 6 Stages Applied to a Real Q2-2026 Deployment, with the Artifacts at Each Step

What this post is, and what it is not

The INITE Protocol is the 6-stage methodology behind every B2B SME deployment INITE AI ships. Break, Hold, Track, Cut, Cast, Form. The names are stage labels and most readers can guess the meaning from the word. What is harder to convey - and what every consultancy-flavoured methodology overview leaves out - is what the team actually does at each stage, what artifacts come out, and which decisions are made.

This post fills that gap. It walks one real Q2-2026 deployment at a 60-person professional-services firm (anonymized; sector, scale, and process pattern preserved; specific names and numbers removed where the contract requires). The deployment shipped 2 production workflows in 19 calendar days from kick-off. The 12-month ROI projection is +$340K against a $74K all-in build cost. The team uses the workflows daily and has not asked us to come back - which is the goal.

Every artifact described below is a real deliverable from a real engagement. The protocol itself is documented in lib/brand-canonical.ts (whatShipped), locales/<lang>/common/protocol.json, and the HowTo JSON-LD in components/StructuredData.tsx. The proof numbers (40-60% efficiency, 3-6 month ROI, 50+ companies, 200+ workflows) are the company's reported aggregate across all engagements.

Stage 1 — Break (Week 1-2): Diagnose & Reset

The Break stage answers one question: is there a process here whose automation math survives scrutiny? If yes, we keep going. If no, we end the engagement and refund the diagnostic deposit.

What we do. Stakeholder interviews (CEO, COO, 1-2 frontline operators - in this case the partner running the practice, the office manager, and 2 senior consultants). Process observation - we shadow the actual work for 4-8 hours per target workflow. Data pull - we ingest 90 days of operational data from the existing systems (CRM, project tool, billing, time tracking). Baseline measurement - we instrument the current process with timing, throughput, and error counts.

Artifacts produced.

1. Process map with bottleneck markers. A swimlane diagram of every step in the target workflow, with quantified throughput, error rate, and cycle time at each handoff. For this deployment we mapped 3 candidate workflows: (a) inbound lead qualification (median cycle time 38 hours, 24% drop-off), (b) project status update communications (4.5 hours/week per consultant, 12 consultants), (c) invoice / time-entry reconciliation (8 hours/week, 22% error rate).
2. Cost-of-chaos report. The dollar value of hours lost per week to manual rework, missed handoffs, and waiting. For this deployment the cost-of-chaos was $11,200/week across the 3 candidate workflows - the number against which ROI gets measured later.
3. Priority matrix. Every candidate workflow scored on automation feasibility (technical, 0-100) × ROI (business, 0-100). The top of the matrix is what gets built in Cast; the bottom is explicitly deferred. The matrix below is the real one (numbers preserved).

The third workflow does not get built in this engagement. It is documented as a follow-up candidate for a future cycle, but only after the Hold stage cleans up the data-quality issues that make it both lower-feasibility and lower-ROI today. Honest deferral is part of the methodology - we do not bundle the bad one in to keep the engagement bigger.

Decision at the end of Break. Cost-of-chaos $11,200/week → annualized $560K → top 2 workflows estimated to recover 50-60% of that = $280-340K/year. Build cost estimated at $74K all-in over 12 months (engineering + monitoring + tuning). Conservative ROI estimate: +$200K in year 1, payback in month 4. Decision: proceed to Hold.

About 1 in 3 of our Break engagements end with the decision not to proceed. The diagnostic finds no candidate where the conservative ROI math is positive. We refund the deposit and write up the reasons. This sounds like a marketing claim; in practice it is the rule that keeps the rest of the methodology honest.

Stage 2 — Hold (Week 2-3): Stabilize & Fix

The Hold stage answers: can the target process be automated in its current state, or does it need stabilization first? Automating chaos is the most expensive way to make slow systems slow forever; this stage stops that.

What we do. For each workflow that will be built in Cast, we identify the upstream data sources, validation rules, and handoff points that must be reliable for automation to work. We fix the ones that are broken. We document the SOPs (standard operating procedures) for the manual versions of the steps that will remain human - because the new automated workflow will still hand off to humans at the edges, and the human side needs to be consistent.

Artifacts produced.

1. SOPs for key workflows. For this deployment: the email triage rules for inbound leads (what counts as a qualified lead, what gets escalated, what gets discarded - written down for the first time); the status-update template the team had been improvising; the data field requirements for the CRM (which fields are mandatory at lead capture vs at conversion).
2. Data quality fixes. The CRM had three lead-source values where there should have been one ("website", "web", "Website"). We collapsed them. The project tool had 4 active status values where the team only used 3. We removed the dead one. The email inbox had 14 inbox rules accreted over 5 years, half of them dead. We pruned to 6 active rules.
3. Quick manual fixes that save time immediately. Two of the bottlenecks in the lead-qualification workflow turned out to be fixable without any AI - one was an email forwarding rule that misrouted leads to a vacation auto-responder; the other was a CRM required-field bug that forced consultants to re-enter the same data twice. Both were fixed in Hold, before Cast started. The Hold-only time savings ran about 6 hours/week across the team - a small but measurable win before any automation shipped.

Hold is the stage that most "AI pilot" methodologies skip, and it is the stage that determines whether the eventual Cast workflow has stable inputs to work against. An LLM-driven workflow that receives inconsistent lead-source values, ambiguous status values, and emails routed to the wrong inbox will produce garbage and the team will blame the AI. The Hold stage ensures the substrate is clean.

Stage 3 — Track (Week 3-4): Measure & Analyze

The Track stage answers: what does the process actually look like in instrumented production, not in the interview-based map we drew in Break?

What we do. Instrument every step of the workflow with timestamped event logging - typically a lightweight middleware that records process events (lead received, lead qualified, lead converted, status update sent, etc.) with timing, identity, and outcome. Collect 2-3 weeks of data on the now-stabilized process from Hold. Find patterns the static map missed.

Artifacts produced.

1. KPI dashboard (live metrics). A real-time dashboard of the per-workflow KPIs that will be tracked through Cast and Form. For this deployment: per-workflow cycle time, throughput per consultant, intervention rate (how often the operator overrides an automated decision), and error rate. The dashboard goes live in Track and stays live through every subsequent stage - the team sees it daily.
2. Pattern analysis report. The non-obvious findings from the instrumented data. For this deployment, three findings stood out. (a) 31% of inbound leads came in between 6pm and 8am local time - the manual workflow had nobody on shift then and these leads sat for 12-16 hours before first response (a fact the team had not measured because nobody was watching during off-hours). (b) Project status updates were 2.3x longer when written between 4-6pm on Fridays than at other times - we suspect rush fatigue; the automation can normalize this. (c) The consultants writing the longest status updates had the highest client satisfaction scores - we should not automate them to brevity blindly; the long-form quality is a feature.
3. Automation feasibility scores per process step. A line-by-line evaluation of which steps in each workflow are good automation candidates (high-volume, well-defined inputs, clear success criteria) vs which should stay human (low-volume, ambiguous inputs, judgment calls). For this deployment, lead qualification scored 82/100 (highly automatable), the first-draft status-update generation scored 76/100 (automatable with human-in-loop review), and the final client-facing send scored 38/100 (should stay human, even after AI drafts).

Track is what transforms the Break-stage hypothesis ("this process looks slow and error-prone") into Cast-stage specification ("this workflow has these specific bottlenecks at these specific steps, with this specific data shape"). A team that skips Track ships a Cast that fixes the wrong thing.

Stage 4 — Cut (Month 2): Simplify & Eliminate

The Cut stage answers: which steps in the process should not exist at all, before any of them get automated?

What we do. Take the now-instrumented process map from Track and walk it step by step. For each step, ask: does this step add value, or is it scar tissue from a problem that no longer exists? Eliminate the ones that do not. Merge duplicate steps. Re-order steps where the order is arbitrary. Prepare the cleaned process as the specification for Cast.

Artifacts produced.

1. Streamlined process flows. The cleaned-up version of each target workflow, ready for automation. For this deployment, the lead-qualification workflow went from 11 steps to 6. Five eliminated steps: one duplicate data entry (CRM was being updated twice for legacy compatibility reasons that had not been true for 18 months), one redundant manager approval (added during a previous quality issue that had been resolved), two status-tracking emails that nobody read (we measured open rates - 4% and 7%), and one manual data export that fed a report nobody ran anymore.
2. Eliminated redundant steps - count and categories. Across the 2 target workflows, 9 steps eliminated of 22 - 41%. Median Cut-stage elimination across our deployments is 30-40%; this engagement was on the high end because the firm had not done a process review in 4 years and the scar tissue had accumulated. Categories: 4 duplicate data entries, 2 redundant approvals, 2 dead notifications, 1 manual feed to a dead report.
3. Automation-ready specifications. For each step that remains and is to be automated, a written spec - input data shape, success criteria, error handling, escalation path, monitoring metrics. This is the artifact Cast builds against. For the lead-qualification workflow, the spec is 11 pages. For the status-update workflow, the spec is 7 pages. Written specs prevent the most common Cast failure mode, which is the engineering team building something that does not match what the operations team agreed to in Track.

Cut is the stage that most CTO-led "let's add AI" initiatives skip because nobody wants to argue with the team about eliminating their pet step. We argue. The math wins; the elimination decisions are written down with the per-step volume from Track attached as evidence. A team that does not Cut ends up automating the chaos and locking it in.

Stage 5 — Cast (Month 2-3): Build & Deploy

The Cast stage answers: do the spec'd workflows ship to production, and do they survive contact with real users?

What we do. Build each workflow against the specification frozen in Cut. Ship to production - not a demo environment, not a sandbox, the real environment with the real users. Wire monitoring before launch. Integrate with the existing tools the team already uses - the CRM, the inbox, the project tool - rather than replacing them.

For deployments that sit on the Inite ecosystem (see the companion post on the shared @inite/* runtime), the Cast stage reuses @inite/assistant for the LLM runner, @inite/inbox for any conversation surface, @inite/api-kit for the request-wrapper pattern, @inite/incidents for the human-in-loop escalation path, and @inite/security for PII masking on the audit log. The reused infrastructure compresses Cast from "build everything" to "configure most of it and write the domain logic". For this deployment, the lead-qualification workflow shipped in 8 calendar days from spec-frozen to live-with-real-leads.

Artifacts produced.

1. 1-3 automated workflows in production. For this deployment: (a) lead-qualification workflow live in CRM + email inbox - 100% of inbound leads now flow through the AI triage, with operator-override available at any step; (b) project status-update workflow live in the project tool + email - generates draft status updates which the consultant reviews and sends. Both workflows hit production within 14 calendar days of Cast start.
2. Integration with the firm's existing tools. No new dashboard for the team to learn. The lead workflow appears as automation rules and AI-generated comments inside the existing CRM. The status-update workflow appears as drafts in the existing email-compose flow. The team's daily tools are unchanged; the AI is invisible plumbing inside them. Adoption is the silent killer of pilots; building inside the team's existing tool set is how Cast avoids it. We use @inite/assistant's tool registry pattern to expose the workflows to any agent that needs to call them - including the MCP-compatible agents the firm's CTO uses for code review.
3. Team training and handover. A 90-minute live session per workflow with the team that will operate it, plus a written runbook (3-5 pages) for each workflow covering: how the workflow normally runs, what monitoring metrics to watch, what to do when an alert fires, who owns the workflow internally, how to escalate to us. The runbook is the bridge to Form.

Cast is also where the browser-agent-readiness checks get applied to any operator-facing surface the workflow exposes - because if an AI agent is going to drive the firm's tools to assist humans, the tools themselves need to be agent-readable. This is a small but increasingly important detail in 2026 deployments.

Stage 6 — Form (Month 3-6): Optimize & Scale

The Form stage answers: does the deployed workflow survive 12 months of real usage, and does the team accumulate a capability instead of getting a one-off project?

What we do. Watch the production traffic for the first 90 days. Tune the workflow against real data, not assumed data. Scale to additional workflows on the same platform. Hand over operational ownership to an identified internal owner.

Artifacts produced.

1. Performance monitoring dashboard. The KPI dashboard from Track, now wired to the production workflows and watched daily by the internal owner. For this deployment, week-12 metrics: lead-qualification cycle time down from 38 hours to 1.4 hours (96% reduction), drop-off rate from 24% to 9%; status-update consultant time from 4.5 hours/week to 0.8 hours/week (82% reduction), consultant satisfaction score (Likert 1-5) up from 3.1 to 4.4. The 40-60% efficiency claim in the protocol holds - this deployment is on the higher end.
2. Optimization based on real usage data. 4 rounds of tuning in the first 90 days. Round 1 (week 3): the AI was too aggressive about classifying borderline leads as unqualified - we adjusted the threshold and the false-negative rate dropped from 11% to 3%. Round 2 (week 6): the status-update drafts were too generic - we added per-client context retrieval from the project tool. Round 3 (week 9): the escalation path was too noisy - we added a confidence-threshold gate. Round 4 (week 12): the consultant-override pattern showed that 3 specific lead types should never auto-qualify - we added those as hard rules. The tuning is not optional; it is what makes the workflow good rather than functional.
3. Scaling plan for next automation wave. With the platform live, the team's bandwidth opens up. We documented 4 follow-on candidates for the next cycle: the invoice/time-reconciliation workflow deferred in Break (now feasible because Hold cleaned the data); a client-onboarding automation; a proposal-drafting assistant; a quarterly-business-review automation. Each scored on the same feasibility × ROI matrix used in Break. The firm picked 2 to run in Q3-2026; we are scoping those as a separate engagement.

The handover is the hardest part of Form. The internal owner gets root access to the workflow config, the monitoring dashboard, the prompt registry, and the escalation runbook. We stay available on a quarterly check-in for the first year, but the operational responsibility is theirs. Workflows that do not have an identified internal owner with budget for tuning are the ones that quietly go dark in 6 months. We refuse to ship Cast without Form, and we refuse to call Form complete without the internal owner.

What the deployment cost, and what it produced

The numbers are real for this specific deployment. The aggregate across the 200+ workflows we have shipped at 50+ companies sits at the 40-60% productivity-gain band and 3-6 month payback. Individual engagements range above and below; this one was on the better end because the firm had been running the manual processes for 4+ years and the Cut stage found unusually high scar tissue.

What the protocol is, in one sentence

The INITE Protocol is what a methodology looks like when it is built backwards from the question "did the workflow survive 12 months of real usage?". Break / Hold / Track ensure the math is real. Cut ensures the substrate is worth automating. Cast ships production-grade software against a clean process. Form makes the change stick. Skipping any one of the six is how AI consultancy money goes to die. Following all six is how 200+ workflows at 50+ companies get to keep running after we leave.

If your math survives Break, your team owns Form. Everything between is engineering.