The Carbon method: Discovery, Delivery, Run

Consider a pattern that appears in many mid-market businesses (an illustration, not a client story). A finance operations team has run two AI pilots in a year. Each produced a convincing demonstration. Neither reached production, because nobody had agreed who owned the workflow, what the system was allowed to decide on its own, or which number would show that it worked. The model was rarely what failed: the work around it had never been redesigned.

Carbon is an AI transformation firm for Europe's real economy. We help mid-market businesses put AI to work. The Carbon method is how that work gets done: one workflow taken from evidence to production in three stages, Discovery, Delivery and Run, each ending with client sign-off. This article explains what happens in each stage, what the client decides at each gate, and how Carbon works with the client's own people.

In brief

• The Carbon method is organised around one workflow and the result it has to show, not around a fixed team or headcount.
• Discovery establishes how the work really runs and tests three ways of doing it. Delivery builds the redesigned workflow, runs it alongside the people who own it and puts it into production. Run keeps it working and improving.
• Every stage ends with client sign-off, and the client can stop at any gate.
• Every engagement starts with one recurring workflow, whatever the size of the business.

The Carbon method is built around one workflow

The Carbon method is the business, technical and adoption work needed to take one workflow from an objective baseline to a measured result in production. The people involved follow the workflow. A document-heavy intake process needs different skills from a reconciliation process, so Carbon does not fix the number of people or the roles in advance.

That choice is deliberate. A delivery model described by its headcount invites the wrong comparison, people against price, and hides the question a buyer needs answered: is the workflow running, and did the agreed metric move? The industry evidence points to the same place. MIT NANDA's The GenAI Divide: State of AI in Business 2025 (July 2025) found that only about 5 per cent of AI pilot programmes achieved rapid revenue acceleration, and attributed the gap mainly to flawed enterprise integration: tools that do not learn from or adapt to the workflows they are used in (Fortune, 18 August 2025). The Carbon method is organised around that integration problem, so the unit of work is the workflow itself.

Discovery: establish how the work runs and what AI should do in it

Discovery produces the evidence for everything that follows: how the workflow actually runs, the baseline it will be measured against, and which parts of it AI should handle.

It starts with the workflow as people perform it, which is often different from the documented version. Exceptions get handled by whoever understands them, approvals drift to other desks, and workarounds accumulate. Carbon's Audit-First Doctrine sets out why that examination comes before any design. In Discovery, Carbon and the client agree four things: the workflow owner, the objective baseline on a metric the business already tracks, the acceptance test the production system must pass, and the scope boundary. Work stays at function level, outside the client's core IP.

The three-arm parallel test

The three-arm parallel test runs the same real work three ways and compares the results. People do it unassisted. People do it with an AI copilot. A standalone AI agent does it on its own. Each arm is measured on hours, error rates, exceptions and how often a person has to override the AI.

The comparison replaces opinion with evidence about what should stay human, what should be augmented and what can run autonomously. That matters because average productivity figures hide large differences. In a study of 5,179 customer support agents, Brynjolfsson, Li and Raymond found that an AI assistant raised issues resolved per hour by 14 per cent on average, by 34 per cent for novice and low-skilled workers, and had minimal impact on the most experienced (NBER Working Paper 31161, 2023). A business cannot assume that a published average describes its own team, its own documents or its own exceptions. It has to measure on its own work.

The result is rarely one answer for the whole workflow. As an illustration: in a document intake process, the agent might classify and extract routine documents reliably, a copilot might help reviewers with unusual cases, and judgement on disputed items might stay entirely human. The test shows where those lines fall before anything is built to production standard.

Delivery: build the workflow, run it alongside the team, then put it into production

Delivery turns the Discovery evidence into a working system, proves it on live work beside the existing process, and moves it into production once it passes the acceptance test.

Carbon builds a prototype from what Discovery established and runs it in a shadow run: the new workflow processes real work while the existing process continues, and the outputs are compared against the baseline. Exceptions and overrides are logged, because they show where the design still needs a human decision or a change to the rules. The workflow owner reviews those results with Carbon and decides what changes.

Adoption work runs inside Delivery, not after it. Champions inside the client team test the workflow, raise what does not fit how the work is done, and help colleagues use it. Role redesign starts here too: when part of a task moves to an agent, the people who did it take on review, exceptions and the judgement calls the test showed should stay human. Carbon's Rebuild-First Doctrine explains why the work is redesigned around people rather than around their removal.

The workflow goes into production when it passes the acceptance test agreed in Discovery, and the result is reported against the baseline. For a single workflow, Carbon's scoped expectation is about 90 days for Delivery, with the metric reported at the end. It is a planning expectation, not a guarantee, and the acceptance test decides when the workflow goes live.

Ownership is settled in writing. The client owns its data, the workflow, and the business knowledge captured in it: the rules, the exception handling, the acceptance tests and the documentation of how the workflow runs. The client keeps everything that describes its own work, in a form it can take elsewhere.

Run: keep the workflow working and improving

Run is the ongoing stage: Carbon keeps the workflow in production, maintains it as models and connected systems change, and improves it against the same baseline.

A workflow in production keeps changing around it. Model providers retire versions, connected systems are updated and the work itself shifts. Run covers that upkeep, and it is the point at which the next workflow can be considered with evidence from the first. Like every other stage, it follows a client sign-off.

What the client signs off at each stage

Every stage ends with client sign-off, and the client can stop at any gate. A business that completes Discovery and decides not to build still keeps the baseline and the evidence from the parallel test.

How Carbon works with the client's team

Carbon works inside the client's operation, with a named workflow owner on the client side who holds the decisions about how the work should run. Carbon carries the business, technical and adoption work together, so the person who maps the workflow and the people who build and test it stay in the same engagement and the same conversation. Requirements are tested on real work rather than handed across a gap between a strategy team and a build team.

Where the work starts

Every engagement starts with one recurring workflow that has a clear owner and an acceptance test. In a surveying or accounting firm that might be document intake, report preparation or client onboarding. In a larger organisation it might sit in customer operations, finance or the back office, with more teams and systems involved. The method does not change with the size of the business: the same three stages, the same baseline and the same sign-off at every gate. Discovery decides whether a candidate workflow is worth building at all.

The two pilots at the start of this article did not fail in production. They failed in the first meeting, when nobody agreed who owned the workflow or which number had to move. The Carbon method is built so that meeting ends with an answer.

‍Carbon builds nearshore engineering Hubs and embeds AI capability inside client operations, for scaling technology companies and PE-backed organizations. Operational infrastructure, built to last.

Own the Build™