Skip to content
A conveyor line in a dark factory hall, paused at one brightly lit inspection station, robotic arms idle beside it.

How we work

Agents build. People sign.

Agents give you the speed. Named people own intent, architecture and each sign-off.

Book a readiness reviewAI-native SDLC
  • You agree scope in writing before code exists
  • A named architect signs the design
  • A separate session reviews code and tests
  • Release waits at a gate the agent cannot pass

Example record

Follow one change through

So you can see who closed each stage. The next one opens only after a name goes against it.

A failed sign-off sends the work back to the stage that caused it.

change · card payment retrySample log

  • Scope agreed in writing

    you + our analyst

    Signed

  • Design before the build

    our architect

    Signed

  • Work split into 30- to 60-minute units

    our engineer

    Signed

  • Code with its tests, reviewed separately

    engineer + test lead

    In review

  • Release past the production gate

    your release manager

    Waiting

  • Production watched against your thresholds

    you, with the agent read-only

    Next

4 sign-offs, and who gives each

  1. S01

    Agreed scope, in writing

    We write business rules, checkable acceptance criteria, worked examples and an out-of-scope list. Gaps and contradictions come back to you as questions, before a plan exists.

    You sign off, with our analyst

  2. S02

    The design, before the build

    Interfaces, data model, dependencies, constraints and the rejected alternatives, on paper. On an existing system it also names the behaviour that has to stay as it is.

    Our architect signs off

  3. S03

    Work you can follow

    We split your change into units of 30 to 60 minutes. Each has its own finishing condition, so you see progress unit by unit.

    Our engineer signs off

  4. S04

    Working code, with its tests

    Code, tests and a pull request from the same session. The tests are written from the acceptance criteria agreed at stage 01, not from the code, and a separate session and our test lead check them for the patterns that make a suite hollow. A unit without passing tests goes no further.

    Our engineer and our test lead sign off

A failed sign-off sends the work back to the stage that caused it. Stages run in order.

After the last sign-off, the line closes into a loop

  1. S05

    Release, behind a gate the agent cannot pass

    An agent prepares the release, writes the changelog and triages the flaky test, sandboxed on credentials scoped to the job. It stops at a production gate enforced in the pipeline, and a refused attempt is logged with its reason.

    Your release manager authorises

  2. S06

    Production reports to a person

    A deterministic script watches your metrics against your thresholds and calls the agent when one breaks. The agent diagnoses read-only, and its fix reaches you as a pull request at the same gate as on day 1.

    You triage. A merge needs a name

A breached threshold becomes scope and re-enters at stage 01, behind the same 4 sign-offs. You lose the wait for a ticket and keep the approval.

6 stages that close into a loop

What production finds becomes your next scope. That return turns 6 stages into a loop.

01SCOPE02DESIGN03WORK UNITS04CODE AND TESTS05RELEASE06WATCHA BREACHED THRESHOLD BECOMES SCOPE

Four sign-offs, each by a named person. You sign the scope and authorise the release. Our architect, engineer and test lead sign the rest. The last 2 stages run after the merge, and what stage 06 finds skips the ticket queue.

Reference

The loop Anthropic published, mapped stage by stage

Anthropic's AI-native SDLC playbook runs delivery as 6 stages in a loop, with people accountable at each gate. Ours is mapped to it stage by stage, on the model your contract allows.

Playbook stageRef
PlanAgreed scope, in writingS01
DesignThe design, before the buildS02
BuildWork you can followS03
TestWorking code, with its testsS04
DeployRelease, behind a gate the agent cannot passS05
MaintainProduction reports to a personS06

In the playbook and here, what stage 06 finds goes back into stage 01 as scope.

The AI-native SDLC playbook, claude.com ↗

Capabilities

What runs without a reminder

We put the guardrails in the agent's own loop, so they hold on each machine that clones the project. Their configuration is committed with the code.

01Secret files are refusedCredential files, private keys and service-account files are denied before they open. The agent gets a refusal instead of the contents.
02Context is checked on each promptWhat enters the model is checked against your data rules. Credential-shaped strings and personal data are caught before they reach it.
03Destructive commands are blockedRecursive deletes outside the project, force pushes to protected branches and destructive schema statements are refused. The agent's reasoning does not change that.
04Errors come back before a commitStatic analysis and the tests touching the change run before a commit or pull request. A broken change stays out of your branch.
05Each action is loggedFiles touched and commands run are appended to a log kept with your project.
063 categories, settled in advanceReads, test runs and step commits go unattended, and a new dependency, infrastructure change or external call waits for a yes. Secret paths, destructive commands and production credentials are blocked, with the reason returned.

Why review is a different session

The session that wrote the code defends its own decisions, wrong ones included. A separate session reviews it against the spec.

  • Review runs separately, from the spec and the change

  • It gets no account of how the code came to be

  • 1 in 5 defects caught before merge is found only here

  • The expensive kind: violated requirements, unhandled edges, invented patterns

How we keep a session cheap

The context window is re-sent on each turn, so cost grows with session length. An overloaded context also degrades output, so the same discipline pays on both.

  • Model matched to the task class

  • 1 task per session, clean context between unrelated tasks

  • A full repository sweep costs 25,000 to 50,000 tokens per question, so agents query the index instead

  • A turn and spend cap on each session, so a loop stops itself

  • A weekly baseline for the trends

Model

What we fix, and what you decide

What we fix

  1. F16 stages in order, each producing something a person reads
  2. F24 sign-offs, each with a named owner and a recorded trace
  3. F3The rules above are configured in your repository
  4. F41 agent per stage, its instructions versioned with your code
  5. F5A commit per step, reviewed by a different session
  6. F6The delivery baseline in place before agents are let in

What you decide

  1. C1Vendor, model and region, against your contract and regulator
  2. C2The enforcement point. We set the behaviour, you pick the mechanism
  3. C3Stack, branching model, test strategy, architectural style
A workshop wall of hand tools, each hung inside its own painted outline.

Our own projects

We run this standard on our own work first

Agents do the implementation on our projects, under the same 4 sign-offs. The standard is published in full, so you can check us against it.

Read the standard (PDF)

Your path in. Review, slice, team

  1. S01

    Review. A readiness review

    So you know what breaks first before you commit budget. Fixed scope, fixed price, each line written down with its price.

    The assessment, a priced plan and the first move

  2. S02

    Slice. One feature under the 4 sign-offs

    So you see the process work on your pipeline before you scale it. One feature, delivered with the 4 sign-offs.

    One feature in production, and your call to scale or stop

  3. S03

    Team. Your backlog, 3 to 8 people

    So your backlog moves the way the slice did. 3 to 8 people, with the 4 sign-offs in place from day 1.

    Your backlog, shipped with the same sign-offs

Each step stands on its own, and you decide whether the next one follows. An audit can also start alone, scoped to a framework and an assessment date.

FAQ

The questions you were going to ask

Answered here, before anyone books a call.

01Are we locked into your tooling?No. The process is ours, the toolchain stays yoursWhere you have CI and review, we run inside themAgent configuration lives in your repository
02Whose IP is the output?Yours, in the contract, before work startsYou see each dependency licence we bring inAnd what the model provider terms say about output
03Which model do you use?The one your contract and regulator allowMore than one is in production across the portfolioSelf-hosted weights where you require them
04Does our data train anything?No. We check vendor terms before issuing a keyRegion pinned where residency requires itWhat enters the context is checked prompt by prompt
05What if we already have a team?Then we work inside itYour review, your merge rules, your definition of doneThe standard is a process, so it travels
06What does it cost?The review is fixed price, quoted after a callDelivery is time and materials, against a written planA spend cap stops a loop, a weekly baseline shows the trends

Next step

Still a question we have not answered?

Ask it directly. You get a written answer before anyone books a call.

Ask us →