What the third way actually is

Search for “AI enablement” and you will find a crowded shelf: staffing firms rebranded as AI-talent shops, process consultancies selling adoption roadmaps, upskilling companies selling courses, automation agencies selling bots. We are not bidding for that word — the shelf is full and the word has stopped meaning anything. This company is named after a different idea, and this piece exists to define it precisely, because a name that cannot be tested is just a mood. The third way is not a service category. It is a delivery model.

One sentence, built to be quoted: the third way is governed AI delivery — software agents do the executing, under constraints the system itself enforces, while humans own the judgment. Every clause is load-bearing. Take away “enforced” and you have the second way with a disclaimer; take away “judgment” and you have the first way with a surcharge. The rest of this piece defends the middle clause, because that is the one everyone claims and almost nobody has.

01Why “third”, and why it is not the middle

The first way is the traditional delivery team: senior people, human hours, real accountability — priced in months and headcount. The second way is autonomy: agents building unsupervised, nearly free by the hour, with nobody answerable when they are wrong. The obvious assumption is that the third way sits between them, a rate card where some hours are human and some are machine. It does not. A blend of two models is not a third model; it is a worse invoice. The third way has a different shape entirely: machines do the execution, humans do the judgment, and the line between them is drawn by machinery, not by intentions.

That last clause is the whole trick, and it is where most “hybrid AI” delivery fails. The rules live in a policy document — review everything before it ships, keep work-in-progress small, keep a human accountable — and a policy document is an aspiration. A constraint that depends on discipline degrades the first week everyone gets busy, and agents do not get less busy. What survives is a constraint the system refuses to let you break. So our delivery org runs on four of them, enforced by the task board every piece of our work moves through — and each one doubles as a test you can run against any vendor claiming to operate this way, including us.

• —The limit is enforced by the system, not by discipline: one in-progress task per project; a worker that tries to open a second has the write refused by the API.
• —Nothing counts until a separate reviewer approves it: implementers finish into review, never done; a reviewer approves or blocks with named gaps.
• —Every decision leaves a log: each status change, dispatch, approval and block writes an activity row, so the work is auditable after the fact.
• —The engine runs without its founders pushing cards: scrum-master and product agents form sprints, dispatch work and post the reports.

02The limit is enforced by the system, not by discipline

Work-in-progress limits are the oldest idea in lean delivery and the first casualty of a busy week, because humans are optimistic about what they can carry — and agents are optimism with a compute budget. On our board the default is one in-progress task per project. A worker that tries to start a second does not get a warning, a nudge, or a dashboard turning amber: the API refuses the write and returns an error naming the task that holds the slot. A human can override in an emergency, and the override is logged — the activity row shows it came from a human channel, not an agent. That is what a constraint looks like in practice — not a preference, a refusal.

03Nothing counts until a separate reviewer approves it

An agent that finishes a task lands it in review, never done — that is the dispatch contract every implementer is issued, and completion authority sits elsewhere. A separate reviewer session is dispatched against the task, and it either approves, which completes the work, or blocks it with named gaps that go back to an implementer. The reason is structural. The session that wrote the work is the worst-placed judge of it, and “our AI checks its own output” is self-grading with extra steps. Separation of builder and reviewer is old in software engineering; what is new is that here it is the default state of the pipeline, not a policy a team aspires to when things are quiet.

04Every decision leaves a log

Every status change, dispatch, approval and block writes an activity row: who acted, what moved, when. After any piece of work you can reconstruct its history — which agent built it, which reviewer approved it, what the reviewer flagged, where a human overrode the machine and on what grounds. This is what “governed AI” has to mean inside a regulated firm, and it is the test most of the market quietly fails. A vendor that cannot produce the ledger is selling governance as a feeling. We can produce it because nobody writes it — it is a side effect of how the work moves.

05The engine runs without its founders pushing cards

The fourth test separates a governed pipeline from a managed one. Sprints on our board are formed and dispatched by a scrum-master agent on a heartbeat; a product agent proposes work, attaches the evidence and posts the reports. When a task completes and frees its work-in-progress slot, the system itself queues the next ready task for dispatch — nobody moved a card. The founders’ hours go to what the machine cannot do: choosing what is worth building, judging what is acceptable, and answering for the result. If an “AI-native” process needs a person dragging tickets between columns all day, the people are the assembly line.

06Tests, not virtues

Notice what the four have in common: none of them is an aspiration. Anyone can write “we believe in small batches, rigorous review, transparency and automation” — consultancies have been putting that sentence in proposals for two decades. The difference between a virtue and a test is that a test can fail in public. So ask whoever is pitching you AI delivery — your internal platform team included — to show you four things: the error a worker receives for exceeding the limit, the review gate between an implementer and done, the activity log for a shipped piece of work, and the sprint report nobody had to push. Four out of four, or it is not a model — it is the first way with an AI surcharge, or the second way with a disclaimer.

07Proof by construction

We run our own delivery org through this exact pipeline — this site ships through that board, every post, tool and page change landing as a dispatched task under the same limit and the same gate. More than twenty sprints have now been formed, dispatched, reviewed and closed by agents under those constraints, each one closing with a report. And this piece is itself a specimen: an implementer was dispatched to write it, it landed in review, and a separate reviewer approved or blocked it before it reached you. That recursion is the point. A definition of governed AI delivery that arrived ungoverned would be a lie with good SEO.

We are not the only ones reaching for “third” language — the framing is in the air, which is a sign the category is real. But a path is not a model until something enforces it. The third way is a division of roles, drawn by the system that runs the work: machines under constraint, humans under accountability. That is the whole definition. Hold a delivery model up to the four tests and if it passes, you have found one — whoever built it.