Human-in-the-loop
What AI agents may do alone,
and what needs a person
In our system, agents may research, draft, build and test on staging without asking. A person has to approve production releases, spending and any new public channel, and a person decides which other kinds of work may run on their own behind automatic checks. No agent touches live customer or payment records, and no agent handles a credential's value. The gate sits in the tool that does the action, so it holds even when an agent is wrong about what it is allowed to do. You get the speed of agents on the preparation work, and you keep the decisions that carry your money and your name.
What the gates protect for you
- Your customers. They see a release only after a person has reviewed it, and no agent can alter their accounts or payments.
- Your money. Nothing is spent and no vendor is signed up without a person's approval.
- Your keys. They stay out of chat logs, reports and transcripts.
- Your time. Agents do the research, drafting, building and testing, so a person only has to make the decisions.
The line, in one table
| Agents do this on their own | A person decides | What it means for you |
|---|---|---|
| Read code, documents and public sources; research and write briefs | Releasing anything to production | A release reaches your customers only after a person has looked at it on staging. |
| Write code on a branch and build it on staging | Spending money, or committing to a vendor | No charge and no vendor commitment is made by software on its own. |
| Test on staging, including signed-in checks of our own consoles | Opening a new public or outbound channel | No new channel opens under your name without your approval. |
| Propose new work orders and raise alerts | Pricing and anything legal. Which kinds of content may publish on their own, behind automatic checks | Your prices, your voice and your obligations stay your call. |
| Report a blocker and stop | Changing the rules the agents run under | The limits you set stay set until a person changes them. |
A reviewer decides when work is done. Agents mark their own work delivered. Closing it as done is a reviewer's call: the reviewer re-checks the result, and the worker never closes its own. "Done" on your board means someone checked it.
Rules no agent can cross, even with approval
- Live customer and payment records. The tool that releases staging to production only moves the display layer: pages, content, menus and theme settings. It never reads or writes customer accounts, bookings or payment references, and that wall is in the release tool, not in an agent's judgement. Your customers' accounts and payment details are not something a release can change, by mistake or otherwise.
- Credential values. Keys live in one store and are named by the job they do. An agent asks for a key by job name and the value is passed straight into the process that needs it, never into a message, a transcript or a result, and never as a masked printout either, because a mask that misses prints the secret looking like a clean redaction. Your keys do not end up in a chat log or a report where someone could copy them.
- Whole-database copies to production. Production is never overwritten from a copy. Changes are scoped, backed up first, and diffed before they apply. A release cannot replace real customer data with an old test copy.
How a production change actually happens
- An agent builds the change on a branch and puts it on staging.
- The work order is marked as staged, which means built but not yet released.
- A person reviews it on staging and approves the release.
- The release tool shows a dry-run diff, approved only if it shows exactly the intended change and nothing touching customer or environment settings.
- The tool backs up what it is about to touch, stops if the backup is not confirmed on disk, applies the change and verifies it.
What you see is a change waiting for your yes on a copy you can click through, and a release that does only what was approved. If something does go wrong, there is a backup of exactly what changed.
Changes to the live system need a quiet fleet
When someone changes the live tooling the agents depend on, the fleet is paused first, the change is made and verified, and the fleet resumes. Every pause expires on its own and raises an alert, so a forgotten pause cannot hold the business down. For you, changes to the tools your business runs on never land in the middle of a job.
When an agent hits a wall
An agent that lacks a tool, or finds one broken, measures the problem, names what kind of failure it is (login, permission, plan limit, or genuinely missing), raises an alert and waits. Routing around a gate is treated as a defect, not initiative. You find out about a gap when it happens, instead of learning later that a job was quietly done a weaker way.
When a job needs a human hand, such as an app that only works from a phone, the agent writes a task card for a person. You get the result confirmed on the platform itself, not taken on anyone's word.
Why the gate lives in the tool
An instruction like "never touch production data" depends on the agent reading it, remembering it and agreeing that this case counts; a release tool that cannot reach production data does not. We write the rule down for the agents, and we also build it into the thing they would have to use to break it. Your protection does not depend on an AI agreeing that the rule applies.