Review-Gated Agentic Workflow. How We Use AI Agents

An AI agent can read a repository, propose a plan, change code, and run tests. That does not yet make a dependable delivery process. A production team still needs to know who approved the intent, which permissions the agent had, what it verified, and who accepted the change.

At Rise we use a review-gated Shadow model. The agent prepares a change in an isolated worktree, but V1 is started manually. People approve the plan, exceptions, merge, and deployment. The system automates repeatable work and preserves evidence. It does not pretend to own production.

We recommend this model to teams that want faster implementation without surrendering control over scope, security, and release. It is not the fastest answer to every experiment. Ad hoc prompting may cost less for a small reversible task.

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 human-controlled merge.

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 that the agent merely watches a developer. It works in a real delivery flow, but permission to change the shared base or production remains outside its reach.

The work starts with a WorkOrder. It records the goal, allowed file scope, risk, required checks, and prohibited actions. The agent turns that into a plan. Implementation cannot start until a person approves it.

After approval, one writer gets an isolated worktree. This reduces the chance that two sessions overwrite the same files or invalidate each other’s test evidence. 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 first explains the approach, affected boundaries, and verification.

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”. When a check fails, the writer gets only a predefined number of repair attempts. The change then stops and waits for a decision. This keeps time and spend out of an endless loop.

A reviewer with fresh context reads the completed change. The reviewer does not silently repair the writer’s work. Findings return to planning or the reviewer issues a decision. The resulting evidence manifest records the scope, commands, results, known risks, and open questions.

The final gate belongs to a person. The agent does not merge or deploy. GitHub rulesets can require pull requests, reviews, and successful status checks. The team still owns risk acceptance.

What we automate and what people decide

Automation is useful where the same input should lead to the same decision. A human gate belongs where business context, an exception, or an operational consequence must be judged.

1. Automated steps

   Contract validation, dry runs, state rules, hooks, CI checks, and evidence assembly.

2. Human decisions

   Plan approval, scope exceptions, risk acceptance, merge, release, and deployment.

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 deployment. This boundary also matters for security. OWASP recommends least privilege, human approval for sensitive actions, input and output validation, audit trails, and resource limits.

Seven workflows need different rules

One universal template is tempting, but a hotfix and a research spike have different goals. As of 24 July 2026, we have validated seven workflow types at the contract level. Live integrations and permissions are verified separately in each project.

The limit does not constrain how often a developer may think. It prevents an agent from repeating the same strategy without a new decision.

Why prompting or CI alone is not enough

Ad hoc prompting suits a small and easily reversed task. Its weakness is process memory. Scope, permissions, and verification are reconstructed by the operator for every session.

CI addresses a different layer. It can reject a change that fails a test, but it usually cannot tell whether the agent was allowed to edit a module, whether its plan had owner approval, or whether a third attempt still makes economic sense.

Review-gated Shadow adds a contract before implementation and evidence after it. This is better for a production team that must explain a decision later. The cost is preparation of the WorkOrder and time at human gates.

A fully autonomous factory can process more independent tasks without waiting. It also needs stronger isolation, observability, emergency stops, identity management, and confidence in automatic merge or deployment. For most small teams, that is a product of its own rather than a prompt setting.

Measuring value without promotional percentages

We do not publish a universal saving percentage. The result depends on repository quality, tests, task definition, and reviewer experience. Compare accepted changes before and after the workflow instead.

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

The first weeks should 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, one repository, and a manual trigger. Define the WorkOrder, permitted commands, approval owner, and evidence required at handover. Run a 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, prohibited actions, and the acceptance path for a completed change.