As we keep adopting more autonomous steps in our automated processes, situations like this are becoming more frequent: Suppose an agent drafts a test plan for an engineering change. The plan then waits for weeks for a supplier’s sign-off. The agent has completed its task, but the change is still blocked.
If we want to improve delivery cadence and quality, we need to measure what happens between the agent’s output and the changes we make to our product. Industry reports, like Capgemini’s latest Rewiring automotive product development, are raising warnings about AI output accumulating faster than organizations can validate, approve, and deploy it.
What interested me in the report
The group Capgemini calls high-value realizers reports 17% faster development cycles than low-value realizers, at 7%. It also reports a 19% reduction in time-to-market, compared with 5%. The executive summary states that their use of agentic and generative AI is no higher than that. I would look closely at how those teams organize the work.
The stronger performers are more likely to monitor data quality for lifecycle-critical datasets: 82%, compared with 54%. They are also more likely to define business cases and cost-value models for agentic AI: 66%, compared with 32%. Capgemini describes stronger governance and clearer responsibilities for work involving partners. These survey results show an association between operating practices and reported benefits.
Make the handoff useful.
When an agent sends you a draft, you need enough information and evidence to accept or reject it. If the handoff omits that information, you may have to reconstruct the work before you can decide.
The handoff I described in Design operating contracts for AI Agents personas covers the evidence, the decision path, and pending questions. The same information is useful when the agent completes its task and sends the draft for acceptance.
Capgemini gives a useful example of engineering data that must remain consistent. Its illustrative braking requirement specifies a stop from 100 km/h within 38 meters. The requirement must mean the same thing in the requirements tool, simulation model, test report, and supplier specification. The report recommends consistent identifiers, units, and definitions across those systems.
For example, if an agent drafts the braking test, the engineer must check that the test uses the required speed and stopping distance and with the same values and units from the supplier specification. Just linking the test to the requirement does not prove that the agent used those values correctly. You will want the handoff to show the inputs the agent used and the checks the engineer performed independently. Without that record, the next engineer may have to repeat the checks before accepting the work.
Assign acceptance to a named role with authority to accept, reject, or return the work. When a supplier is involved, agree who can resolve a disputed result.
Measure the path to the product.
Capgemini recommends three lifecycle measures. Together, they describe the path from feedback to a product benefit.
| Measure | Start | End |
| Feedback-to-decision time | An insight from tests, vehicle data, customer feedback, or warranty data | An approved engineering decision |
| Decision-to-release time | The approved decision | A deployed software update, design change, or product release |
| Release-to-value time | The released change | A measurable business, customer, or operational benefit |
Feedback-to-decision time includes analysis and validation as well as approval queues.
Within each interval, work can move, wait, or return for correction. The cause may be missing evidence, an unresolved supplier test, or a release date that keeps an approved change waiting. Those delays call for different responses.
I would review these intervals alongside validation results and repeated work. If the team accepts changes that fail their tests, a shorter review time leaves the problem unresolved. The aim is less avoidable delay, with the checks that establish whether the change is valid.
Start with one workflow.
An engineering leader can start with a one-week review of one agent-assisted workflow. Use it to identify current gaps and delays, then decide what to change and measure.
- Pick one workflow, preferably one that includes a consequential engineering decision. Review recent completed work and work still in progress. Identify the agents involved, including those supplied with vendor tools.
- At each handoff, inspect the evidence to check the applicable policy version, inputs, validation results, approval authority, and exception handling, so you can identify the person who can resolve the next decision.
- Record the available dates for feedback, decisions, and releases. Distinguish time spent doing necessary work from time waiting or repeating work. Mark outcomes that the team has not yet observed.
- Compare exception and mandatory approval demand with the team’s available capacity. Extend the calculation from Who supervises an agent that runs for two hours?:
Exception minutes/day = exceptions/run × runs/day × minutes/exceptionApproval minutes/day = approvals/day × minutes/approvalTotal oversight minutes/day = exception minutes/day + approval minutes/day
- Include the time necessary to resolve the work, not only read it. Count each minute once. If exception handling includes approval time, exclude that time from the approval estimate. Compare the total with the time the team can provide.
During the week, the team can identify missing owners, partial records, and demands that exceed review capacity. The sample may miss rare exceptions and benefits that appear later. Capgemini recommends a longer baseline: its three lifecycle measures per program within a quarter. The initial review helps identify the measurements to continue over that period.
Use the findings to make the next decision. If the receiving engineer lacks evidence or authority, repair the handoff before you expand consequential work. If oversight demand exceeds capacity, decrease the agent’s scope or increase the team’s capacity. If accepted work waits for release, check the delivery process before you add more work to the queue.