Delivery platform

What happens between the command and the proposal

We built an AI-augmented delivery platform and we run our own projects through it. Seven stages take a request from someone typing one command all the way to a deployed release and a price with the business case behind it, with a schema contract enforced at every handoff.

Stages: 7, plus an audit trail
Documents out: 3 per pass
Schema contracts: 16 enforced
Status: Running in production

The problem

Why pay for hours when you need the outcome?

In a lot of software contracting, work is billed by time and materials. The uncomfortable arithmetic of AI-assisted delivery is that under that model, productivity is a liability: if a team delivers in six person-months what used to take ten, the invoice drops by forty percent for the same delivered software.

That is a bad incentive to build a company on. So we built for the opposite model. Under fixed-price delivery, the same compression is margin rather than lost revenue, and the client gets working software sooner. But fixed price only works if you can define scope accurately and defend the result, which is an evidence problem, not a speed problem.

Nearly everything below exists to produce that evidence: typed requirements traced to their sources, a gate that has to return a verdict before work moves on, test cases written before implementation, and an audit trail emitted at every stage boundary.

The pipeline

Seven stages, end to end

01Intake
Someone types one command in Slack. The platform gathers every source that mentions the keywords and acknowledges in under three seconds.
02Extract
An LLM reads every source and returns typed requirements with confidence scores. Anything it is unsure about becomes an open question rather than a guess.
03Assemble
Agents turn requirements into a specification, a work breakdown, a split between what is essential and what can wait, and executable test cases. Every output carries an explicit verdict before it leaves the stage.
04Plan
The same package becomes a roadmap: work rolled up into epics, effort summed from the individual estimates, and each task placed in a month against real capacity.
05Build
Work is routed by type to the model that handles it best, each with a fallback chain. Every task arrives pre-sized: nothing larger than a two-hour change.
06Review
Security runs before code review, not after. A failing review blocks the pull request outright, and the fix loop gets three attempts before a human is called.
07Ship
Deploy, close the ticket, notify the channel. Every stage boundary emits a completion event, so the whole run is auditable after the fact.

Inside assembly

Four agents, one job each

Assembly is deliberately split four ways. Each of these produces a single artefact and is scored on that artefact alone, and moving the package downstream takes a verdict from the gate.

A1

Spec author

Turns extracted requirements into a specification with acceptance criteria, and flags every ambiguity it had to resolve.

A2

Work breakdown

Splits the specification into items sized xs (under thirty minutes) or s (under two hours). Anything still medium gets split again.

A3

Scope classifier

Sorts the work into must, should, could, and won't, so scope conversations happen before code rather than during it.

A4

Test-spec generator

Writes executable test cases against the acceptance criteria, before any implementation exists to bias them.

Run it yourself

The front of this runs in your browser

Intake and assembly are the production code, and you can put your own meeting notes through them. Paste a rough note and watch it become segmented, classified, and traced back to the line it came from.

Try it on your own notes

330

Test functions across the two core stages

84.39%

Median token reduction on paired live runs

≤120s

Meeting to draft requirements, 95% of runs

JSON schemas enforced between stages

On the numbers

Where these figures come from

The token reduction figure is a median across paired runs measured internally: the same task executed with and without our context retrieval layer, 44,669 tokens against 6,971. It is a real measurement on our own workload, not a benchmark, and your codebase will differ.

The 120-second figure covers the intake stage, from the Slack command to a draft set of requirements, and it is the time 95 runs in 100 land inside rather than an average. The acknowledgement itself returns in under three seconds. The test count is literal: 330 test functions in the two stages that carry the specification and implementation logic.

We would rather publish a number we can source than a rounder one we cannot. If you want the methodology behind any of these, ask and we will walk you through it.

Want to see it run on your problem?

The most useful version of this conversation starts with a real requirement of yours. Send us one and we will show you what comes out the other end.

hello@littlelabrats.com