Nothing ships without you.
The reason AI stays stuck in pilots is that nobody can answer what it is allowed to do, or what happens when it gets something wrong. Both have plain answers here.
It asks in words you can act on.
When it wants to do something that matters, it stops and tells you four things: what it wants to do, why it thinks that, what it affects, and how to undo it.
The same card reaches you wherever you already are — on the pull request, in Slack, in email, or in the browser. Approving in any of them is the same act, recorded the same way.
No dashboards to learn, no logs to read, and nothing that needs a specialist to interpret.
Ship the fix for duplicate confirmation emails
- What it wants to do
- Ship a fix for duplicate order confirmation emails. 3 files changed.
- Why
- Ticket #2841. It reproduced the bug, wrote a test for it, and all 214 tests pass.
- What it affects
- The checkout service, in production. No spending involved.
- How to undo it
- Roll back to the previous release. It will watch error rates for 30 minutes after and undo it automatically if anything looks wrong.
You decide how far it can go.
- Watch only It reports what it would have done. Changes nothing at all.
- Suggest It writes up the fix and the reasoning. A person does the work.
- Draft it It does the work and opens a pull request, then stops.
- Ask me first It can ship — once you approve. Where most teams stay.
- Go ahead It ships inside limits you set, on work you nominated.
This is not one switch for the whole system. It is set per team, per repository and per kind of work, so a dependency bump and a production deployment do not have to be trusted the same amount.
Most teams start at ask me first for anything customer-facing and never move it. That is a perfectly good place to stay.
What you can put boundaries around.
Which repositories
It only ever sees the ones you connect.
Which kinds of work
Bug fixes but not schema changes. Test coverage but not deployments. Your call.
Which environments
Freer in development, tighter or blocked in production.
How much it may spend
A ceiling per ticket and per team, enforced rather than requested.
Who can approve what
By role and by team, so a production change needs the right person.
When to escalate
If it is stuck, over budget, or past a deadline, it comes and finds someone.
These are settings, not instructions written into a prompt and hoped for. An agent cannot talk its way past them, and it does not matter what it was asked to do.
Every change can be undone.
It cannot ship without a way back
Anything reaching production must have a way to reverse it before you are even offered the approval. No rollback, no approval — you will not be asked to make that call.
It watches after it ships
For a window you set, it keeps checking that things are healthy. If they are not, it puts them back on its own and tells you what happened.
You can always take over
Pause it, redirect it, or stop it entirely, mid-task. It hands back what it has done so far rather than disappearing with it.
Every change has a paper trail.
For anything consequential, you can answer the questions an auditor or an incident review will ask: what happened, when, who approved it, what evidence they had, and what the outcome was.
It is not a report generated afterwards. It is the same record the system itself works from, so it cannot disagree with what actually happened.
- · What was changed, and where
- · Who approved it, and what they were shown
- · What evidence supported it — tests, tickets, reviews
- · Everything the agent did on the way
- · Whether it worked after it shipped
- · What it cost
Bring us your approval process.
Describe the path a change takes through your organisation today, and we will show you where each step lands. That is a more useful hour than any feature tour.