Skip to main content

Solution · Review and sign-off

Code review and release that keep pace with coding agents

Every pull request reviewed by its owner and, above a limit, decided by the person who holds the decision, even when agents open more than people can read.

PR, then Ana decides, then Merge.

Who decides · Ana Okafor · Head of platform · above the service owner’s limit

How it runs

Coding agents open more pull requests than people can read. Each one needs an owner, a check against your rules and, above a limit, the person who holds the decision, without anyone chasing anyone.

A seat is a role a person and an agent hold together; the escalation matrix says who decides above each limit, seat by seat.

  1. Agent carries08:40
    Pull request #4812 opens, with a migration
  2. Agent carries09:05
    Tests, scans, the rollback plan: the packet
  3. Rules check09:12

    ENG-R08

    Schema change above the service owner’s limit

  4. Person decides09:12
    Sofia sees why it is not hers
  5. Person decides11:20
    Ana Okafor approves, with a condition: backfill in the window
  6. Agent carries22:00
    Merged and deployed in the window; team told
  7. Person decides08:00
    Daniel starts from the decision
up the escalation matrix, by rule a person decides

Your repository host · invoicing-service

Add entity column with backfill #4812

  • TestsPassed
  • Security scanPassed
  • Rollback plan attachedPassed
  • CClrSlate · waiting on Ana OkaforRequired
MergeMerging is blocked until the owner decides
Drawn as your tool shows it; ClrSlate adds the line that names the owner.

Illustration · Halden, a fictional company

Step by step

Who takes each step, in order.

For

  1. 01A coding agent, from whichever vendorOpens pull request #4812 on the invoicing service, with a database migration. It becomes REQ-2214, a request.
  2. 02The invoicing service agentPicks it up for the seat it holds with Sofia Brandt and runs the change review: tests, scans, the rollback plan, the packet.
  3. 03The rulesENG-R08: schema changes are beyond the service owner’s limit, so it goes up the escalation matrix, packet attached.
  4. 04Sofia Brandt, service ownerSees why it is not hers to approve; she decides every change inside her service.
  5. 05Ana Okafor, Head of platformApproves with a condition: the backfill runs in tonight’s maintenance window. DEC-0917.
  6. 06The invoicing service agentMerges in the window, links the ticket, deploys and tells the team.
  7. 07Daniel Ruiz, CTOStarts the next morning from the decision, and from a rule worth changing: ENG-R08 keeps sending backfill-only migrations up.

Where the decisions sit

Decision, who decides, up to where, and above that whom.

  • Merge to mainDecides: the seat that owns the serviceUp to: changes inside the service, checks passingAbove that: the architect, or the practice the change touches
  • A database schema changeDecides: the Head of platformUp to: additive and reversibleAbove that: the CTO
  • A design that crosses servicesDecides: the team’s architectUp to: within the architecture standardsAbove that: the Head of platform, through an architecture review
  • A release is cleared to shipDecides: the QA engineerUp to: the quality standard and its evidenceAbove that: the Quality practice lead, as a recorded exception
  • Release to customersDecides: the owner of the releaseUp to: the scheduled window, checks passingAbove that: the department head
  • Rollback in productionDecides: the on-call seat in SREUp to: the runbookAbove that: the department head

How much the agent decides, to start. Coding agents prepare every change and every review packet. What they may merge alone is written down per team: documentation-only changes, or dependency updates inside a minor version with the checks passing, are common starting limits. Everything else asks the person who holds the decision.

The record it leaves. REQ-2214 and DEC-0917: who asked (a coding agent, pull request #4812), what was checked (tests, scans, the rollback plan), which rule sent it up (ENG-R08), who decided (Ana Okafor, with a condition) and what was done (merged and deployed in the window). Ask the record “who approved the schema change on invoicing, and why” and the answer is one line.

How it plugs in

No new inbox, no new tool to learn.

  • 01

    An app in your tools

    Connects to your repositories, trackers and chat as an app

  • 02

    A check, not a meeting

    Holds a decision as a check the owner clears

  • 03

    Where people already work

    Asks the owner where they already work, and carries out what was decided

HA
REQ-2214

Review · REQ-2214

Schema change: invoicing service Escalated

The service agent prepared the packet. The rules check it before anyone decides.

Checked against the rulebook 4

RuleResult

ENG-R02Tests pass on the branch

Passes

SEC-R04No new secrets, scan clean

Passes

ENG-R08Schema changes beyond the service owner’s limit

Escalates

ENG-R11Rollback plan attached

Passes
The packet checked against the rulebook; above the limit, it goes up.

The tools it runs through

We connect to the systems you run, and build the connection before the demo.

What it uses

Start with howyou run today.

Bring one piece of work that breaks at the handoffs: a pull request waiting on three reviewers, an initiative spread across twelve tools, a release nobody owns. We model the seats it crosses, give one of them an agent, and follow one decision to its record.