INITE Protocol: 6 Stages Applied to a Real Q2-2026 Deployment

What this post is, and what it is not

The INITE Protocol is the 6-stage methodology behind every B2B SME deployment INITE 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 Q2-2026 deployment at a 60-person professional-services firm, twelve of them fee-earning consultants (anonymized; sector, scale and process pattern preserved, names and commercially sensitive figures removed). Two production workflows shipped in 19 calendar days from the Cast kick-off, against a $24K build. Year one roughly washes. Year two is where the return sits. That is the shape a first automation actually has, and it is the shape most case studies decline to show.

Every number below belongs to this one engagement, and every one of them derives from another number on this page: volumes come out of the systems, hours out of the volumes, money out of the hours at a stated loaded rate. Where a benefit could not be priced that way it is named and left out of the return rather than estimated into it. INITE publishes no cross-client average, because there is no measured one to publish. 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 discipline behind the Break stage in particular is in process audit before automation.

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: 34 leads a week, 22 minutes of ops-coordinator time each for research, CRM entry and routing, so 12.5 hours a week, plus 6 hours a week of consultant time redoing work on mis-routed leads. Median first response 38 hours; 24% of leads had no reply inside five working days. (b) Project status updates: 26 active engagements, one note a week each, 40 minutes of consultant time per note, so 17.3 hours a week. (c) Invoice and time-entry reconciliation: 8 hours a week of office-manager time at a 22% error rate.

2. Cost-of-chaos report. The hours above, priced at loaded cost: $95 an hour for a consultant, $45 for the ops coordinator and the office manager, which is what the hour costs the firm to provide rather than what appears on a payslip. Lead qualification $1,133 a week, status updates $1,647, reconciliation $360. Total $3,140 a week, annualised over 48 working weeks rather than 52, because holiday and slack weeks do not get automated away: $151K a year. That is the number every later claim gets measured against.

   The 38-hour first response and the 24% of leads that never got a reply are not in it. Both are real, and both are probably worth more than the hours, but converting them into money means assuming a conversion rate and a deal value, and an assumption is not a measurement. They stay on the page as findings and out of the return.

3. Priority matrix. Every candidate workflow scored on automation feasibility (technical, 0-100) against return (business, 0-100). The top of the matrix is what gets built in Cast; the bottom is explicitly deferred.

Lead qualification scores higher on return than its hours alone justify - it is the smaller of the two lines at $1,133 a week against $1,647. The score is the one place the unpriced drop-off is allowed to count, because the matrix is a ranking rather than a sum and a ranking can carry a judgment. The money below cannot, which is why the same drop-off stays out of every figure in the rest of this post. Saying which of the two is happening is the whole difference between a matrix and a guess.

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-return 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. The two workflows worth building carry $2,780 a week of the $3,140, which is $133K a year. The model assumed automation would take back 60% of those hours rather than all of them, because the exceptions stay human: $70-85K a year. Build estimated at $24K, monitoring and tuning at $750 a month afterwards. The workflows go live at the end of month 3, so year one collects nine months of benefit: roughly $52K against $33K of cost, a net near +$19K with payback around month 9. Year two, with only the support cost left, sits near +$61K. Decision: proceed to Hold.

Nobody in that room found this exciting, which is the correct reaction and the reason it was approved. A first automation that pays for itself inside a year and compounds afterwards is a normal good outcome. A first automation projected to return four times its cost in twelve months is a sales document.

A Break stage is allowed to end here with a no. Had the arithmetic at conservative inputs not cleared - and the third workflow on its own would not have - the diagnostic deposit goes back and the engagement stops. That has to be a real outcome or none of the measurement above means anything.

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 a week across the team - a small win before any automation shipped, and those hours sit inside the week-12 figures below rather than on top of them, because the same hour cannot be counted twice.

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) Most status updates went out in a single batch on Friday afternoon, which is why clients experienced the reporting as bursty rather than weekly, and why nobody inside the firm had noticed - from the inside it feels like a weekly rhythm. (c) The two consultants who wrote the longest status updates were also the two with the highest renewal rate on their engagements. Two consultants is not a sample and it proves nothing; it was still enough to decide against tuning the automation toward brevity, which is the kind of call a dashboard cannot make for you.
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%. That is a high proportion, and the reason is specific rather than typical: 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, and the test of its length is whether the operations lead will read the whole thing in one sitting rather than skim it. Both specs here passed that test. 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 19 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. Week-12 measurements, against the baseline the operator signed at the end of Track: median first response on an inbound lead from 38 hours to 1.4 hours; leads with no reply inside five working days from 24% to 9%; ops-coordinator time on lead handling from 12.5 to 3.5 hours a week; consultant time on status updates from 17.3 to 5.2 hours a week; consultant rework on mis-routed leads from 6 to 1.5 hours a week. Exceptions still go to a person, which is why none of those figures goes to zero and why a proposal that promises one should be read carefully.
2. Optimization based on real usage data. Four rounds of tuning in the first 90 days. Week 3: the classifier was too willing to mark borderline leads unqualified, so the threshold moved and the ops coordinator stopped having to re-check the discard pile every morning. Week 6: the drafts read generically, so per-client context retrieval from the project tool went in. Week 9: the escalation path was noisy enough that people had begun ignoring it, so a confidence gate went in front of it. Week 12: the override log showed three lead types that should never auto-qualify, and those became hard rules. None of this could have been done before go-live, because none of the data existed.
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 reclaimed hours came in at $95K a year against a modelled $70-85K. That is the direction an estimate should miss in, and it is the reason the model assumed 60% recovery rather than 90%.

The drop-off improvement is not in any of those figures. A quarter of inbound leads going unanswered, down to under a tenth, is at this firm's deal sizes almost certainly worth more than every hour in the table put together. It stays out because nobody measured what those leads would have converted at, and a number built on an assumed conversion rate would have made the whole table unfalsifiable. If the firm instruments that next year, it becomes a measurement and it goes in.

The numbers are for this deployment and nothing else. There is no published INITE average to hold them against, and there should not be one until it has been measured across a sample worth quoting. The CFO frame for projecting a lift like this onto the P&L is in measuring AI ROI.

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 a workflow is still running the quarter after we leave.

If your math survives Break, your team owns Form. Everything between is engineering. The substrate that makes the Cast stage compress from 3 weeks to 8 days is described in the Inite operating model for vertical AI products.