Pilot to Production: The Proof-of-Work That Gets You Hired

The gap, in numbers

Start with what the market actually looks like as of mid-2026, because the shape of the gap tells you where the opportunity sits.

The adoption-to-production gap in enterprise agent deployment. Figures as reported in 2026 industry research; sources differ slightly in methodology, which is why two failure rates appear.

Measure	Reported figure	What it tells you
Pilots failing to reach production	~88%	Forrester/Anaconda, replicated by a16z and MIT Sloan
Alternative estimate	~89%	Gartner, same direction, different method
Enterprises that adopted agents in some form	~4 in 5	Interest is not the constraint
Organisations running an agent in production	~31%	The real number is far below the hype
Enterprises running agents in production	~1 in 9	A stricter read of the same gap
ROI delivered by pilots that survive	171%	Gartner — the winners win big
Agentic projects forecast cancelled by end-2027	>40%	Gartner — attrition is not finished

Two things follow. First, the bottleneck is unambiguously the transition, not the ambition: adoption is near-universal and production is rare. Second, the payoff for crossing is real — a 171% ROI on the survivors is why organisations keep funding attempts despite the failure rate.

An organisation staring at a 171% return that it cannot reach, having already failed once or twice, is an organisation that will pay for someone who has crossed before. That is the whole thesis of this guide.

The three blockers are three skill sets

The reported blockers are worth reading as a curriculum:

• Evaluation gaps — ~64% of leaders. The team cannot say, with evidence, how good the agent is or whether a change made it worse.
• Governance friction — ~57%. Nobody can answer risk, audit or legal on what the agent is permitted to do and how that is enforced.
• Model reliability — ~51%. Behaviour varies unacceptably across runs, versions or inputs, and there is no plan for when it does.

This reframing matters for how you spend your time. A candidate who spends three months making a demo more impressive is competing in the abundant category. A candidate who spends three months making a modest agent defensible is competing in the scarce one.

What proof-of-work means here

Most AI portfolios show capability: here is an agent, watch it do a thing. That was differentiating in 2024. It is now table stakes, because the tooling has collapsed the cost of a working demo to an afternoon.

Production-readiness proof-of-work shows something different — that you know what would go wrong and have handled it. The artefact is not the agent. The artefact is the evidence pack around it.

What separates a demo from production evidence, gate by gate.

Gate	The demo version	The production evidence
Evaluation	"It works on these examples"	A versioned suite built from real failures, with a defined pass bar and a regression run in CI
Governance	"It has a system prompt telling it not to"	Enumerated permissions, enforcement outside the model, an audit trail captured by infrastructure
Reliability	"It usually works"	Variance measured across N runs, defined degradation behaviour, a rollback that has been rehearsed
Cost	"Tokens are cheap"	Cost per successful task, including retries and human clean-up time
Handover	A notebook	A runbook someone else can operate at 2am

Build the evidence around a small agent

The most common mistake is scaling ambition instead of rigour. If you have never shipped an agent, do not attempt something impressive. Take something deliberately modest — a document-triage agent, a support-ticket classifier with tool access, an internal data-quality checker — and build the full evidence pack around it.

A 150-line agent with a 200-case evaluation suite, a failure taxonomy and a rehearsed rollback is a stronger hiring signal than a multi-agent research system with none of those. Interviewers who have lived through a stalled pilot recognise the difference immediately, and they are the ones making the offer.

The artefacts, concretely

1. An evaluation suite built from real failures

Not a benchmark. A private set of cases drawn from things that actually went wrong, each with an expected outcome and a rationale. Aim for 150–300 cases; below about 100 you cannot detect regressions reliably, and above a few hundred the maintenance cost outruns the value for a single agent.

Three properties make it credible. It grows from production incidents rather than imagination. It is versioned alongside the code. And it runs automatically, so a regression is caught by CI rather than by a customer — the discipline covered in running evals in CI for prompt and agent regression testing.

One caution worth internalising, given what the UK AI Security Institute reported this summer: an evaluation the agent can reach is an evaluation the agent can game. Keep answer keys off infrastructure the agent can route to. We cover the full threat model in building evals your agent cannot game.

2. A written failure-mode analysis

One page. For each plausible failure: what it looks like, how it is detected, what happens automatically, and what a human must do. This is the artefact that most obviously separates people who have operated a system from people who have built one.

Include the failure modes specific to agents rather than only the generic ones. What happens when a tool call returns malformed data? When the agent loops? When it takes a plausible but wrong action that is expensive to reverse? When the model provider changes the default model underneath you? That last one is not hypothetical and it is worth having an answer for.

3. Enumerated permissions and enforcement

A list of every action the agent can take, every system it can reach, and — critically — where that boundary is enforced. If the answer is "the system prompt asks it not to", you have documented an intention rather than a control.

Governance reviewers are not asking whether you told the model to behave. They are asking what stops it if it does not. Enforcement lives in scoped credentials, network egress rules and tool-level authorisation — the territory of least-privilege credentials for AI agents — and being able to speak precisely about that distinction is a strong senior signal.

4. A rollback procedure you have actually run

"We would roll back" is not a plan. A plan states what triggers it, who can pull it, how long it takes, and what happens to work in flight. Then you rehearse it, and you record how long it really took, which is usually longer than anyone estimated.

An engineer who can say "we rehearsed rollback and it took eleven minutes, of which nine were draining the queue" is describing lived operational experience that cannot be faked. Our guide to LLM incident response runbooks covers the structure.

5. A cost model in cost per successful task

Not tokens. Not monthly spend. Cost per successful task, including retries, failed tool calls and the human minutes spent fixing what the agent got wrong. This is the number a finance-literate manager actually needs, and producing it signals you understand the economics rather than just the engineering. The method is in LLM unit economics and cost per task.

A worked example

Suppose you build a document-triage agent that routes incoming supplier invoices to the right approval queue. Deliberately unglamorous. Here is what the evidence pack looks like when it is done properly.

1. Scope. Routes invoices into four queues. Explicitly does not approve, pay or edit anything. The boundary is enforced by the credential it holds, which has read access and queue-write access only.
2. Evaluation. 220 real invoices, including 40 deliberately awkward ones — scanned at an angle, multi-currency, a credit note misfiled as an invoice, two near-duplicate suppliers. Pass bar set at 97% correct routing with zero instances of the highest-severity error, which is routing a payable to the wrong legal entity.
3. Failure analysis. Six identified modes. The interesting one: on low-confidence extraction the agent used to guess. Now it routes to a human review queue, which turned a silent error class into a visible workload.
4. Reliability. Each eval case run five times to measure variance. Three cases were non-deterministic, all in the near-duplicate supplier category, which is now a known limitation stated in the runbook rather than a surprise.
5. Rollback. Feature-flagged to route everything to the human queue. Rehearsed. Takes about four minutes, dominated by in-flight items rather than the switch itself.
6. Cost. Measured per correctly routed invoice, including the human review queue the agent generates. Compared against the baseline of the fully manual process.

Now read that list as an interview answer. Every item invites a follow-up question you can answer from experience. That is exactly what the project deep-dive round is designed to find, and most candidates cannot sustain it past the second probe.

If you cannot show the work

Much of the strongest production experience sits inside employers who will not let you publish it. The answer is to publish the method rather than the material.

Your evaluation design, failure taxonomy, runbook structure and threshold reasoning are portable and rarely confidential. Swap the domain data for a public dataset and keep the architecture of the approach. Describe outcomes in relative terms — "reduced a specific error class by roughly two-thirds" — rather than absolute business figures.

Write it up as a short technical post. Two thousand words on how you designed an evaluation suite for a document-processing agent, with the reasoning behind the pass bar, demonstrates more than a repository of code nobody reads. It is also durable: it keeps working for you while you sleep, which a private repository does not.

Where the demand is, in both markets

This capability is in demand on both sides of the AI Tech Connect map, for different reasons.

In India, the Global Capability Centres are the epicentre. India hosts over half the world's GCCs with more than 126,000 AI professionals, and around 58% are investing in agentic AI capability. A GCC building agents for a global parent inherits the parent's governance requirements — SOX, internal audit, regional data protection — which means the governance gate is not optional there, it is the first gate. Engineers who can navigate it are disproportionately valuable, and the roles increasingly sit in platform and enablement teams rather than in individual product squads.

In the UK, the driver is regulatory posture in financial services, healthcare and public sector delivery, where the evidence requirement arrives before deployment rather than after. UK AI engineering job adverts have risen sharply over the past two years, and the roles that stay open longest are the ones asking for production experience rather than research experience. A candidate who can walk into a risk review and speak the language of controls and evidence is solving the actual bottleneck.

The two markets increasingly draw from one talent pool, which is why the same evidence pack travels. What varies is emphasis: Indian GCC roles tend to weight governance and audit trails, UK roles tend to weight assurance documentation and demonstrable controls. The underlying artefacts are the same.

How to present it on a profile

Hiring teams searching for this capability are not searching for framework names. They are searching for the vocabulary of production: evaluation, rollback, governance, reliability, production.

The second version is the same project. It states a gate cleared, evidence produced and a measured outcome. It also gives an interviewer five specific things to ask about, each of which you can answer in depth — which is precisely how the deep-dive round is won.

Your Builder profile is the right home for this because it is structured around projects rather than job titles, and because the people hiring for agent production work browse it directly. Founding Builder spots are still open, and an early profile carries that badge permanently.

A 90-day plan

1. Days 1–15. Pick a deliberately modest agent task with a real user, even an internal one. Ship a working version quickly. This part is not the point.
2. Days 16–40. Build the evaluation suite from actual failures. Run it. Fix what it finds. Wire it into CI.
3. Days 41–60. Write the failure-mode analysis and enumerate permissions. Move every boundary you find in a prompt into infrastructure.
4. Days 61–75. Write the runbook. Rehearse the rollback. Record the real timings, including the embarrassing ones.
5. Days 76–85. Build the cost model in cost per successful task.
6. Days 86–90. Write it up publicly, method not material. Update your Builder profile with the gate-and-evidence framing.

Common mistakes

• Scaling ambition instead of rigour. A bigger agent with no evidence pack is a weaker signal, not a stronger one.
• Evaluation sets built from imagination. Cases you invented test what you already thought of. Cases from incidents test what you did not.
• Governance described as prompt instructions. A reviewer will ask what enforces it. Have an answer that is not the model.
• An unrehearsed rollback. Every unrehearsed plan is optimistic, and the interviewer asking about it has usually found that out the hard way.
• Reporting tokens instead of cost per successful task. The first is an engineering metric, the second is a business one.
• Hiding behind the NDA. "I cannot discuss it" ends the conversation. Publishing the method keeps it going.

Next steps

The 88% figure is not a reason to be pessimistic about agents. It is a map of where the value sits, and it happens to point at a set of skills that are learnable, demonstrable and currently scarce. Build the evidence pack around something small, write up the method, and describe it in the language of gates cleared rather than technologies used.

If you want to go deeper on adjacent ground, our guides to building an evals portfolio, the AI engineer system-design interview and the AI governance engineer career path cover the neighbouring skills that make this one land harder in an interview.