Proof of Concept, Pilot or Production: What Each AI Stage Must Prove

A proof of concept shows that a task can be done with your own material. A pilot shows that real people get dependable value from the agent under supervision. Production shows that the agent can be owned, monitored and corrected as part of normal operations. Each stage exposes different people to different risks, so the move to the next one should depend on evidence, not on the calendar.

Key takeaways

• The three stages are not three sizes of the same project. They answer three different questions: can it work, does it help real people, and can we depend on it.
• Exposure grows at each stage. A proof of concept should touch only builders and reviewers, a pilot touches named users, and production touches everyone who relies on the workflow.
• Authority should be granted by action, starting with drafts and reversible steps, and widened only when logged evidence supports it.
• Write the evidence needed to leave each stage before the stage begins. Stopping or narrowing the scope is a legitimate outcome.
• Production is not the end of the work. It needs an owner, observability, permission reviews and a controlled way to change the agent.

What is the difference between a proof of concept, a pilot and production?

The three words are often used loosely, and that looseness is where projects get into trouble. A team calls a demo a pilot, or treats a pilot that ran for a few weeks as a finished production system. The honest way to tell them apart is to ask what question each stage answers and who can be harmed if the answer is wrong.

• Proof of concept: can this work at all with our real material? Exposure is limited to the builders and a few reviewers. Data is sample or copied, and the agent has no authority to act.
• Pilot: does this help real people doing real work, and do the controls hold? Exposure covers named users and the colleagues who receive the output. Authority is limited and approvals stay on.
• Production: can the company depend on this as a routine part of operations? Exposure covers everyone who relies on the workflow, including customers and partners. Authority is defined, owned and reviewed.

Most failures come from skipping a question, not from answering one badly. A proof of concept that goes straight into daily use has never been tested with real users. A pilot that never ends has no owner who can declare it done. If you recognize that pattern, why AI pilots stall and how to move them to production looks at the causes in more detail.

What must a proof of concept prove, and who is exposed?

A proof of concept answers one narrow question: given our real material, can an agent do this task well enough to be worth testing with people? It tests feasibility, not value. Keep it small on purpose.

It must show three things:

• The information the task needs exists and the agent can reach it, whether it lives in documents, a shared inbox or a system with an interface.
• The output is good enough on realistic examples, including awkward ones such as incomplete requests, contradictory notes or outdated files.
• The task can be described clearly enough that a person could check the result without guessing what was intended.

Exposure should be close to zero. Only the builders and a few reviewers see the output, so the agent should work with read-only access, copies or sample data, and no ability to send, write or change anything. If a proof of concept can email a customer, it has already become something else. Data still deserves care at this stage: even sample documents can contain personal or confidential details, so decide where they are processed before you load them.

The evidence to produce is a written set of realistic cases, with the expected result recorded in advance by the person who does the work today, and a note of where the agent was right, wrong or unsure. A demo that works on a few hand-picked examples is not evidence. A list of cases that includes the failures is. Anthropic's guidance on evaluating agents makes the same point: define the tasks and how they will be judged before you look at behavior.

What must a pilot prove, and how do you limit the risk?

A pilot asks whether real people, doing real work, get dependable value from the agent, and whether the controls hold when the work is messy. The success criteria should be written before the pilot starts. How to define success criteria for an AI agent pilot covers the method in detail.

A pilot must prove four things:

• Usefulness: people choose to use the agent, and the owner can observe that work is faster, more consistent or better prepared than before.
• Boundaries: the agent stops and asks where it should, and never acts outside the permissions it was given.
• Failure handling: when something goes wrong, a person can see what happened, correct it and resume the work.
• Fit: the people involved understand what the agent does, trust it to the right degree and know how to challenge it.

The exposed group is larger now: the named users, the colleagues who receive the output and, at the edges, customers if anything reaches them. Limit the scope to one team, one workflow and a short list of actions. A sound way to begin is shadow mode, where the agent prepares drafts or proposed actions that people compare against what they would have done. Running an AI agent in shadow mode before giving it authority explains how. After that, grant authority one action at a time, reversible actions first.

The evidence a pilot produces includes logs of the cases handled, a record of human edits and rejections, a list of incidents and how each was resolved, and direct feedback from users. Edits are more informative than praise, because every correction marks a place where the agent differs from your standard.

What must be true before an agent runs in production?

Production does not mean the agent is finished. It means the company has accepted that the agent is part of how work gets done, and that it must therefore be owned, supervised and maintained like any other operational capability.

These conditions should hold continuously, not just on launch day:

• Ownership: a named person is accountable for the role, and someone is responsible for access and permission review.
• Observability: logs and traces let someone reconstruct what the agent did, which tools it called and why. The general ideas of observability (traces, logs and metrics) apply to agents as they do to other software.
• Permissions: the agent works under its own identity with the least access needed, and authorization is reviewed on a schedule.
• Change control: updates are tested against the original case set before release, as described in how to update an AI agent in production without breaking it.
• Recovery: there is a way to pause the agent, roll back a change and hand unfinished work to a person.

The exposed group now includes everyone who relies on the workflow, plus the company itself through its data handling and any regulatory obligations. A risk framework such as the NIST AI Risk Management Framework is a useful reference for organizing this. For most mid-sized firms a lightweight version is enough, as long as someone actually runs it.

What evidence lets you move from one stage to the next?

Use the lists below as gates. If an answer is no, that is a result, not a failure: extend the stage, narrow the scope, fix the cause or stop.

Before moving from proof of concept to pilot, ask:

• Is there a written set of realistic cases with expected results, and does the agent handle them acceptably?
• Have the failures been listed and traced to a cause: missing information, unclear instructions or a tool limit?
• Is there a named pilot owner and a small group of users willing to give honest feedback?
• Is access agreed, with the agent on its own identity and limited to reading or drafting?
• Is there a written success criterion that someone other than the builder can measure?

Before moving from pilot to production, ask:

• Did the pilot meet its written criterion across ordinary and difficult periods, not only the easy ones?
• Do the logs show where people overrode the agent, and were the approval rules updated as a result?
• Are incidents closed, with causes understood and fixes tested?
• Is there an owner, a support path and a regular review rhythm?
• Can the agent be paused, and can unfinished work be resumed or handed over?
• Do users know what the agent does and how to raise a problem?
• Does the real cost of running it, including review time, match what the business case assumed?

Moving backward is normal. If production reveals a new kind of case, the right response may be a short return to shadow mode for that case alone, not an argument about whether the agent is good or bad.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a description of a real engagement. A distribution company wants an agent to prepare first replies to supplier questions about delivery status.

In the proof of concept, the agent reads copied past emails and a document of shipping terms, and drafts replies for a set of old queries. An operations coordinator marks each draft against what she actually sent. The review shows the agent struggles when one email refers to two orders. That is a finding about instructions and tools, and it is fixed before any user sees the agent.

In the pilot, the agent runs in shadow mode for one coordinator. Drafts are not sent. Her edits are logged, and the most common edits lead to a clearer rule about which delivery dates the agent may quote. Later, the agent is allowed to send plain acknowledgements by itself, while anything that would change a date still goes to a person for approval.

For production, the agent gets its own mailbox and credentials, a named owner, a way to be paused and a regular review of its logs and permissions. When the company later wants to change the reply style, the change is tested against the original case set first. At no point did anyone have to trust the agent on faith: each step was granted because the previous one left evidence.

How does Be Human handle the three stages?

Be Human treats the stages as a sequence of access and authority, not a sequence of tools. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. The agent starts with narrow access, evidence is collected against that criterion, and authority widens only when the evidence supports it. After launch, managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the routine work of production has an owner.

Frequently asked questions

Is a proof of concept the same as a pilot? No. A proof of concept tests whether the task is feasible using sample or copied material, with no authority and very few people involved. A pilot puts the agent in front of real users on real work, with defined controls and success criteria.

How long should each stage last? There is no honest fixed duration, because the stage ends when the evidence is in, not when a date arrives. A workflow with frequent, varied cases produces evidence quickly, while a rare or seasonal one takes longer. What matters is that the exit evidence is written down before the stage starts.

Can we skip the proof of concept? Sometimes, when the role is narrow and closely resembles one you already run. You still need the written case set, because it becomes the baseline for later changes. Skipping the pilot is the riskier shortcut, since it is the stage that shows how people and the agent work together.

What happens if a pilot does not meet its criteria? You have three reasonable options: narrow the scope, fix the cause and run it again, or stop. Stopping with clear findings is a good outcome, because it spares the company from running something it cannot depend on.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.