Review-Gated Agentic Workflow. How We Use AI Agents

An AI agent reads a repository, proposes a plan, changes code, runs the tests. None of that is a delivery process. Six months later the questions are different ones, and they are who approved the intent, which permissions the agent held, what it actually verified, and who signed off the change now sitting in production.

At Rise we use a review-gated Shadow model. The agent prepares a change in an isolated worktree, V1 is started by hand, and the plan, the exceptions, the merge and the deployment are approved by a person, who will answer for all four afterwards. The system automates repeatable work and keeps the evidence. It does not pretend to own production.

We recommend this model to teams that want faster implementation without giving up control over scope, over security, over the release itself, which is the control people quietly lose first. It is not the fastest answer to everything. For a small reversible task, ad hoc prompting may well cost less.

1. Ad hoc prompting

   Fast for a small reversible task. Context, permissions, and evidence depend on the operator each time.

2. Review-gated Shadow

   Fits a production team that needs measurable gates, bounded repairs and a merge that stays with a human.

3. Autonomous factory

   Requires strong isolation, observability, emergency stops, and confidence in automatic changes with wider impact.

What review-gated Shadow means

Shadow does not mean the agent sits and watches a developer work. It writes in a real delivery flow, and the only thing outside its reach is the permission to touch production, or the shared base everyone else builds on.

The work starts with a WorkOrder that records the goal, the allowed file scope, the risk, the required checks and the actions nobody may take, whatever the agent thinks. The agent turns that into a plan. Nothing gets implemented until a person approves it.

After approval, one writer gets an isolated worktree. Isolation reduces accidental interference between sessions. Shared services and test data still need coordination. The same operating idea appears in guidance for Codex and Claude Code worktrees.

1. Approved WorkOrder

   Scope, risk, permissions, and required evidence are known before work starts.

2. Plan and human approval

   The agent explains the approach first, then the boundaries it touches and how the work gets verified.

3. Isolated implementation

   One writer works in an isolated worktree with a bounded number of repair attempts.

4. Exact checks

   Deterministic commands verify the agreed scope and produce repeatable results.

5. Independent review and handover

   A fresh context reviews the change. An evidence manifest goes to the person deciding on merge and deployment.

Failed checks return to implementation. Review findings return the change to planning.

Checks are exact project commands. Not an instruction to "test it". A failed check buys the writer a fixed number of repair attempts, nothing beyond that. After that the change stops and waits for a human decision, which is what keeps an endless loop from quietly eating the budget nobody was watching.

A reviewer with fresh context reads the completed change before acceptance. That reviewer does not quietly repair the writer’s work. Findings go back to planning. Or the reviewer issues a decision. What comes out is an evidence manifest holding the scope, the commands, the results, the known risks, the questions still open.

The final gate belongs to a person. The agent neither merges nor deploys. GitHub rulesets can require pull requests, reviews and successful status checks, but no ruleset can accept the risk on behalf of the team that has to live with it.

What we automate and what people decide

Automation is useful where the same input should lead to the same decision. A human gate belongs wherever somebody has to weigh business context, an exception, or the consequence operations will feel on Monday.

1. Automated steps

   Contract validation, dry runs, state rules, hooks, CI checks and the evidence a review needs.

2. Human decisions

   Plan approval, scope exceptions, risk acceptance, merge, release and the call to deploy it.

Our model automates the following work.

• Contract validation checks whether the WorkOrder and workflow contain required fields and permitted commands.
• Dry-run initialization shows planned files and changes without writing into the target project.
• State and permission rules in YouTrack guard allowed transitions and roles. YouTrack workflows are designed for this kind of automation, while YouTrack MCP exposes governed tools to agents.
• Hooks block a prohibited command or start a check at a defined moment. Claude Code hooks are one example of a deterministic layer around the model.
• CI repeats trusted checks in a clean environment.
• The evidence manifest assembles inputs, results, and review into one handover.

People still approve intent, scope changes, security exceptions, risk acceptance, merge, release and the deployment that follows them. The boundary matters for security too. OWASP recommends least privilege, human approval for sensitive actions, input and output validation, audit trails, and limits on what an agent is allowed to spend before someone looks at it.

Seven workflows need different rules

One universal template is tempting. A hotfix and a research spike do not have the same goal, and pretending otherwise is how production incidents end up waiting behind an acceptance-criteria checklist. As of 24 July 2026, we have validated seven workflow types at the contract level. Live integrations and permissions get verified separately in each project.

The limit says nothing about how often a developer may think. It stops an agent repeating the same strategy without a new decision.

Why prompting or CI alone is not enough

Ad hoc prompting suits a small, easily reversed task. Its weakness is process memory. Scope, permissions and the way a change gets verified are rebuilt inside the operator’s head at the start of every session, and they leave with the operator.

CI addresses a different layer. It rejects a change that fails a test. What it cannot tell you is whether the agent was allowed to edit that module, whether the plan had owner approval, or whether the third attempt still makes economic sense.

Review-gated Shadow adds a contract before implementation and evidence after it. For a team that has to explain a decision months later, that trade is worth making, and you pay for it in WorkOrder preparation, plus the time spent at human gates.

A fully autonomous factory processes more independent tasks without waiting. It also needs stronger isolation, observability, emergency stops, identity management, and enough trust to let merge or deployment run without anyone watching, which is the hard part. For most small teams that is its own product, not something you configure in the prompt.

Measuring value without promotional percentages

We do not publish a universal saving percentage. The result depends on repository quality, on the tests, on how the task was written, and on how much the reviewer has seen before, so numbers from somebody else’s team tell you nothing about yours. Compare your own accepted changes before and after.

Useful measures include lead time from approved task to accepted change, net review time, repair count, post-release regressions, blocked unauthorized actions and the cost per accepted change. The denominator matters. Spend on rejected or unusable proposals belongs in the result too, because somebody paid for those.

The first weeks exist to establish a baseline. Only then should the team change limits, add workflow types, or automate another gate.

Where to start

Start with one recurring type of change and one repository. The trigger stays manual. Define the WorkOrder, the permitted commands, the approval owner, and the evidence a handover has to carry, because nobody reconstructs any of it from memory later on. Run the dry run first.

Our earlier article about keeping a human in the loop during AI development explains why expert judgement still matters. The AI agent governance checklist extends the topic to data, tools, and emergency stops.

If you are also choosing the right process, see our AI automation service. A review-gated agentic workflow becomes useful only when the team can name the owner, the prohibited actions, and the acceptance path for finished work.