Can AI take over the reviews that decide a project’s future?

Why I started with the reviews that govern projects

Before your company buys software, connects two systems or launches an application, several specialists have to look at the project. Are the contract terms acceptable? Is the data protected the way its classification requires? Do the test results support going live? AI does not make those questions go away. It changes who answers them.

That is the question I set out to answer in The Last Human Gate, published on arXiv on 24 September 2026: can an AI agent carry out a project review through to the final decision, without a specialist having to redo the work? And if it can, how much human work is left? Those are two different questions, and this article keeps them apart. The first is answered by an experiment. The second is answered by counting hours.

The title refers to forward deployed engineers, the FDEs who sit with a client's teams and turn an AI demonstration into a system people use every day. They identify the need, build the solution, connect it to the company's applications and data, deploy it and keep it running. Their work is not limited to governance. I nevertheless propose governance reviews as their first target, for four reasons.

There is a practical reason on top of those four. Every AI system an FDE deploys has to pass the company's own reviews. Automating the reviews clears the road for everything that follows. It requires one owner for the whole route rather than one department, and the hours the FDEs spend building and supporting the system belong in the bill. I come back to that bill in section 10.

What has to be checked before a project can move forward

I call the set of required reviews a project must pass its Digital Governance Framework, or DGF. A gate is one checkpoint on that route. At each gate a reviewer reads the available documents and records, names the problems, asks for the necessary corrections and makes a decision. It is a job, not a box to tick.

Not every project follows the same route. Buying a solution, integrating existing systems and developing an application each have their own sequence. The first two pass six gates, the third passes five, and every route ends with a General review that consolidates the earlier decisions with the budget and the strategy.

Several specialists read the same dossier without doing the same job. The legal reviewer and the security reviewer look for different problems in the same contract and the same architecture. Here is what each gate asks, and the kind of material it examines.

The questions summarize the policies I supplied to the benchmark. Your company may merge, split or reorder these gates; the obligations behind them stay.

Five possible decisions, not just yes or no

What an agent needs before it can take over a specialist's review

A job title tells you who does the work today, not whether the work must be done by a person. A review can be mandatory without its execution being human. For an agent to take it over, three conditions have to hold at the same time.

A fourth condition applies the moment you talk about staffing: total human hours must fall. A review that disappears from one team's calendar and reappears at a supplier has not been eliminated. An agent that sends every dossier to a person for a second reading has not replaced anything either. If your reviewers still reread everything the agent produced, you have bought assistance. Decide which of the two you are paying for before you decide what it is worth.

How I tested this without touching a real company's dossiers

DGF-Bench uses 300 entirely fictional projects: 100 purchases, 100 integrations and 100 application developments. A program defines the facts of each project, draws its architecture and writes the documents the reviews need. It deliberately mixes projects that meet the requirements with projects that do not.

Each project holds about 26 Word documents, plus tables and an architecture diagram: a project charter, contracts, security test reports, operating procedures, backup, restore and load test results. Some documents are incomplete, outdated or contradictory on purpose. A summary can say that a contract is signed while the contract register still lists it as a draft, exactly the kind of discrepancy a good reviewer is paid to catch.

The agent does not create the project it reviews. It reads the dossier, queries simulated company systems, asks for missing information and writes its findings for each gate. Those findings are handed to the next gate exactly as written, errors included. Nobody corrects them along the way, because nobody would in a real deployment either.

An actual test document: the architecture diagram of Project Falcon

The same agent runs with three models: Gemini 3.8 Flash, GPT-5.6 Luna and DeepSeek v4.1 Flash, the endpoint names as served on 22 and 23 September 2026. The settings are identical: temperature zero, at most 20 reasoning turns and 40 tool calls per review. The plan called for 1,700 reviews per model, 900 complete project runs in total. One run was lost to a technical failure at the model provider, so the main results cover 899 runs and 5,094 reviews. The model calls for the whole experiment cost $99.58, failed attempts included. That is the price of the experiment, not the price of building or operating such a system in a company.

A program decides whether the agent passed, not a panel

When the program creates a project, it fixes its facts: whether the contract is signed, whether the supplier has been vetted, whether the required test passed. From those facts and its rules it derives the decision to take, the problems to report and the actions to request, and it saves those answers for scoring. No human writes them, and no human judges the agent's prose.

The answers live in 99_hidden_ground_truth.json. The canonical_truth field holds the facts of the fictional project; reference_decisions holds the expected answers for each gate. The agent cannot read this file. Once the route is complete, the scoring program compares the agent's submissions with it, taking into account any conditional approvals that were properly authorized during the run.

For sources, the check goes further than a plausible reference. The scorer reads the tool logs to confirm that the agent actually opened the sources it cites, then checks that its quotations match the required passages word for word. A correct decision can therefore fail because its supporting quotation does not meet the standard an auditor would apply.

Authorization is checked at a different moment. When the agent asks for a conditional approval, the tool checks that its mandate covers this gate and this project phase, that every unresolved problem is listed and that those problems are eligible for conditional approval. If any of that fails, the request is refused and the refusal is recorded.

100% correct decisions, 95% complete reviews, 77% complete routes

With Gemini, the agent takes the correct decision in every one of the 1,694 reviews evaluated. Yet only 94.98% of those reviews meet all five criteria, and only 76.92% of projects pass every gate on their route. The three numbers measure three different things, and you need all three before you delegate anything.

The first measures the decision alone. The second requires a complete review: correct decision, complete findings, correct actions, exact sources, respected authority. The third requires every gate of a project to pass; a single failed review fails the route. "77% of projects passed" does not mean "77% of projects were approved": many of them were correctly refused.

With GPT-5.6 Luna and DeepSeek v4.1 Flash, the strict pass rates are 83.29% and 74.18%, and the complete-route rates fall to 42.33% and 24.67%. Their decisions are correct in about 98% and 95% of reviews. The gap between a correct decision and a complete review is where the engineering work lies.

The weak point: exact source citations

All 85 of Gemini's failed reviews fail for one reason only: a missing source, or a quotation that does not meet the requirement. In Procurement, Luna and DeepSeek take the correct decision in 96% and 97% of reviews but pass all criteria in only 33% and 43%, because they cite a spreadsheet that the scoring rules do not accept as a source. The decision is right; the evidence trail is not.

There are substantive errors too, and I count them separately because they are the ones that matter to a CISO. Luna approves one Legal review despite a missing data-processing agreement. DeepSeek submits a placeholder GO where overlapping address ranges require NO_GO. Gemini records no wrong approval in the main runs. Across about 5,100 reviews, that is one false approval each for Luna and DeepSeek, and zero, three and one serious problems missed.

What the program with no AI tells you

The conventional rules program scores 100% on all 1,700 reviews and 300 projects. That is the most useful number in the table for anyone planning a deployment. When the facts are already structured and the rules are explicit, ordinary software is enough, and it costs nothing per call. The agent earns its place where the facts are scattered across documents, hard to retrieve or contradictory. Build the deterministic core first, then put the agent around it for the parts that need reading and investigation.

One more result shows where the lever is. If the scoring accepts the same values quoted in a different order, 69 more reviews pass for Gemini, 38 for Luna and 52 for DeepSeek, and Gemini reaches 99.06% of reviews and 94.98% of complete routes. Nothing changed in the agent's judgment. What changed is how evidence is represented. That is a tooling problem, and tooling problems are the ones an FDE can fix in weeks.

Falcon and Meridian: what the agent actually does at a gate

Two dossiers from the execution logs show what sits behind the percentages. I chose them after the evaluation to illustrate the mechanism, one success and one instructive failure.

Meridian tells you what to build. The fix is not a more capable model. It is a tool that attaches the exact source passage, with its location and version, to each finding, so that the agent never has to reconstruct a quotation from memory. An evidence service of that kind removes the single largest cause of failure in these runs.

The same dossier can pass one attempt and fail the next

A benchmark score is one attempt. A deployment is thousands. After the main runs, I took 15 projects, five per route, and reviewed each of them three more times with each model: 135 additional project runs, with no best-of-three selection. The question is no longer whether a project passed, but whether all of its reviews pass every time.

Across the 45 repeated runs per model, every review passes in 35 runs with Gemini, 19 with Luna and 11 with DeepSeek. The strict review rates hold at 96.08%, 82.75% and 73.33%. No wrong approval and no serious problem missed in these 135 runs. The repeat tests cost $12.56 in model calls. The lesson for a rollout is simple: before an agent takes over a gate, run the same dossiers several times and look at the variance, not only the average.

Authority cannot rest on the model's own assurance

The agent can ask the authorization tool for permission to approve with conditions. The tool records three things: the requests made, the requests refused and the approvals actually used in final decisions. These are counts of calls, not of projects; one gate can produce several requests.

Requests recorded in the main runs. The same 391 eligible gates are available to every model.

Gemini asks most often and is refused most often: 466 of its 864 requests. An agent will seek approvals that the rules do not allow, sometimes insistently. What stops them is the separate authorization check, not a promise written in the model's answer. If you take one architectural rule from this article, take this one: the component that grants authority must not be the component that reasons.

Execution logs from the benchmark console

Better reasoning cannot recover a fact that was never provided

Take two projects with strictly identical text in all 26 Word documents. The required decision is nonetheless different, because the difference sits in a separate record: in one project the supplier has completed its background check, in the other it has not.

This limit applies to a person as much as to an agent. Reasoning cannot produce a fact that nobody gave the reviewer. Giving the agent access to the CSV record, or allowing it to file a justified request for the missing information, changes the task and makes it solvable.

This is the first job of the FDE, before any prompt: connect the agent to the authoritative records, decide what it may read, and specify what it must do when a fact is missing. In my framework, access to information is a condition of a valid review, not a detail to sort out after choosing a model. Any deployment that hands the agent only the PDFs is leaving out information a fair test and a safe operation both require.

Automating 80% of the cases does not remove 80% of the work

A pass rate does not measure hours saved. An agent can take over most of the straightforward dossiers and leave the specialists exactly the cases that take the longest. Human checks, error correction and platform operations then add hours of their own. To know what you have actually saved, you have to add up everything that is left.

Here is the arithmetic that surprises most people. Suppose the agent handles the easiest 80% of the cases. Each remaining case takes twice the original average time, so the remaining 20% already represents 40% of the original workload. If the new division of labor makes those cases another 50% longer, because a specialist now has to pick up a dossier cold, they alone represent 60% of the original workload. Maintenance has not been added yet.

Quality plays the same way. A mistake that goes unnoticed at first creates work later: someone has to find it, understand its consequences and correct it. And a dangerous error left uncorrected does not become acceptable because the system is cheap to run.

To measure a reduction in your own organization, track the same types of dossiers before and after automation: handling time, cases sent back to people, corrections and support. Keep consistent case identifiers so that the same task is never counted twice and no work is forgotten.

The same automation can leave a need for 44 or 169 FTE

Take a governance function that occupies 140 full-time equivalents today. An FTE is a quantity of work, not a particular person. The four scenarios below keep the same share of cases automated and change only how the remaining work is organized. The gap between them is the whole point.

S0: the AI also helps on the complex cases. Specialists handle them in half the time, and the other cases get limited checks. The result is 43.52 FTE, a reduction of about 69%. It is the most optimistic scenario, and it counts no maintenance at all.

S1: the difficult cases take as long as before. Specialists handle them without AI assistance, the other cases get brief checks, and each team assigns one person to keep the platform running. The need rises to 85.32 FTE. S2 keeps those assumptions and adds half an hour of correction per case: 89.07 FTE.

S3: people recheck every decision. Complex cases take 50% longer, verification is extensive, corrections take two hours per case and two people per team run the platform. The need reaches 168.92 FTE, about 21% more human work than before automation. An organization that trusts nothing the agent produces ends up paying for the agent and for the reviewers.

The share of cases automated is not the number that matters. What matters is how much time the organization still asks of people.

Before you promise a headcount figure, decide which scenario you are actually building: who handles the exceptions, with what assistance, how much verification you keep, and who runs the platform. The same model gives you 44 or 169 depending on those four answers.

How far automation can go, and on what timescale

The benchmark stops at the review. The longer version of my work pushes the hypothesis to its end: eventually, agents perform every review, including the complex cases and the final decision, and the work of supervising them, maintaining the rules and handling exceptions gets automated in turn. Here is what that path looks like for the same 140-FTE function.

The checks never disappear in these scenarios. What shrinks is the human work needed to execute them. The last step, from a small support team to zero, is the hardest: as long as a team operates the agents, it sets a floor under the headcount.

That floor is easy to underestimate. From 140 FTE, automating 80% of the review work leaves 28 FTE of review work. Add five FTE to run the platform and the total is 33, not 28. To land at 28 overall you need to automate about 84% of the review work with a five-person support team, or about 91% with a fifteen-person team. Every FTE you add to support has to be earned back in review work.

A timeline built from explicit assumptions

When could a whole review be delegated? I built the estimate from four stages, each with a stated assumption. It starts from a May 2026 measurement: the best agents complete tasks worth about three hours of human work with an 80% success rate, and that task length has been doubling every seven months. A typical gate review represents about 24 hours of human work, three doublings away, which lands in February 2028.

Capability is not enough. The error rate then has to fall from 20% to roughly one failure in a thousand, followed by a year of testing with specialists and another year for the company to grant the authority. The unknown is how long each tenfold reduction of the error rate takes: six, twelve or twenty-four months.

Six predictions you can check against your own data

The hypothesis fails if a review stays inherently human, if a human signature remains mandatory, if an "automated" service quietly runs on hidden human work, or if the support team can never be reduced. Each of those is observable in a real deployment, which is why I put them on the list.

My prediction: at least 80% fewer FTE by 2033

I do not derive this figure from Gemini's pass rate. It is a separate prediction with explicit conditions. The count includes everyone who contributes to the reviews: the people who prepare and perform them, handle the complex cases, check results, correct errors, maintain and supervise the agents, and support the suppliers.

The prediction fails if more than 20% of the original human work remains, if quality drops or if reviews take longer. It also fails if the comparison excludes the most difficult business units, forgets new support functions or moves the deadline. Fewer employees with contractors doing the same hours does not count. Faster approvals with more defects getting through does not count. A department renamed "AI oversight" whose staff still perform the reviews by hand does not count.

What this means for the people doing the work today

In the division of work I propose, people keep the definition of the rules, the decisions that have not been delegated, the signatures the law or the company requires, the spot checks and the operation of the system. They also carry out the corrections the reviews request, until those actions are automated too. Specialists spend less time on individual dossiers and more on designing, testing and maintaining the decision rules.

That guarantees neither that every job survives nor that every job disappears. A real reduction in required hours can remove positions; a company can also keep the same team and handle more projects with it. Renaming people "AI supervisors" changes nothing in the arithmetic. What gets measured is work, whatever the job title.

Five decisions before you delegate a gate

The agents completed 5,094 scored reviews across 899 project routes. The best model took every decision correctly, most of its reviews met all five criteria, and its main weakness was the evidence trail, which is a tooling problem. Repeat runs showed variance you have to measure, and the authorization tool refused hundreds of approvals the agent was not entitled to. Everything else in this article follows from those facts. Here is what I would do with them.

1. Write the gate contract before writing a prompt. Name the inputs the reviewer may use, the policy version, the mandate, the five expected outputs and the population of dossiers, difficult cases and legitimate refusals included.
2. Connect the authoritative records. Project A and Project B differ by one CSV field. If the agent cannot read it or ask for it, no model will save you. Decide what it may read and what it must do when a fact is missing.
3. Keep the authority outside the model. The agent proposes; a deterministic check grants or refuses; the refusal is logged. Gemini asked 864 times and was refused 466 times. That refusal is the safety mechanism.
4. Attach the evidence by tool, not by quotation. Meridian failed on the order of two fields in a quotation. An evidence service that copies the source value and its location fixes the largest single cause of failure.
5. Count hours, not cases. Follow the same dossiers before and after, including exceptions, verification, corrections and platform support. Decide which of the four staffing scenarios you are building, then announce a headcount figure.

Start with the reviews whose rules are already written and whose facts are already structured, put a conventional rules engine at their core, and let the agent read, investigate and propose around it. Run the same dossiers several times before you trust the average. Then measure the hours. That is the sequence that turns a benchmark score into a governance function that costs less to run and still holds.

The review remains mandatory. The questions are who performs it, what information they can access, which decisions they may make, and how much work they leave for everyone else.