Most AI proof-of-concept projects do not fail because the technology is not clever enough.
They fail because everybody involved is already busy.
The sponsor is busy. The subject matter experts are busy. The people who know how the work really happens are busy. The people who can say whether the output is useful are busy. Then the project asks them for a few meetings, a bit of feedback, maybe a steering call every two weeks, and expects something genuinely new to emerge.
That is not enough.
Agentic projects are not ordinary IT projects. They are closer to onboarding a new person into the work.
The old project shape is misleading
A lot of delivery thinking still has the same basic rhythm.
Analysis. Design. Development. Testing. Deployment. Training. Handover.
Even when we use sprints, the pattern often stays similar. There is discovery. There is a backlog. There are reviews. There is a sponsor. There are subject matter experts. The team asks questions, goes away, builds something, comes back, and asks for feedback.
That can work when the problem is stable enough.
It can work when the process is known, the data exists, the workflow is documented, and the main job is turning a requirement into a system.
But agentic work is different.
The reason you are using an agent is usually that the work is fuzzy. If the work were fully deterministic, you would just write code. You would define the input, define the output, run it again and again, and move on.
Agents are useful when the work involves judgement, context, exceptions, interpretation, and the awkward middle ground where people normally fill the gaps.
The project needs the client inside the work
In a normal project, the customer may attend key meetings. The sponsor may unblock decisions. A subject matter expert may explain the process at the start. Then the delivery team goes away and does the work.
For agentic projects, that is usually too thin.
The client needs time each week with the team. Not just a polite review slot. Real working time.
Because the early stage is training.
You can cycle through the documents, the process maps, the data, the example cases, the call notes, the policies, and the existing knowledge base. That will get you somewhere. It will show you what is written down.
Then you hit the interesting bit.
What does good look like?
What is in people's heads that never made it into the process?
What do people do every day that nobody wrote down?
Where do two experienced people do the same job differently?
Which shortcuts are clever, and which ones are risky?
Which exceptions are normal, and which exceptions should stop the work?
That knowledge does not come out in one workshop. It comes out through use, correction, argument, examples, judgement, and repetition.
You would not onboard a person like this
Imagine hiring someone into your team.
You would not give them a 20-minute briefing, point them at a shared drive, speak to them every two weeks, and then be surprised when they misunderstand the work.
You would sit with them. You would show them examples. You would correct them. You would explain the exceptions. You would tell them when to ask. You would help them understand the team, the customer, the politics, the history, and the quiet rules that make the work safe.
An agentic POC needs the same shape.
Not because the agent is a person. It is not.
But because the work it is being asked to do lives in the same messy human environment.
This is why people teams matter
This is also why I think HR, people teams, or organisational-change teams should be much closer to agentic rollout.
Technology teams are good at systems. They are good at delivery, infrastructure, integration, security, support, and the mechanics of getting something live.
But agentic adoption is not only a system rollout.
It changes how people work. It changes what people explain. It changes what they supervise. It changes how managers allocate time. It changes training, confidence, accountability, and trust.
People teams already understand that new capability needs management.
They know people need onboarding, support, time, supervision, feedback, and permission to learn. They know managers cannot just say, "Here is a new worker, absorb it into your day." Someone has to make space for the change.
That is the muscle agentic projects need.
The real POC question
A weak POC asks:
Can the AI do the task?
A stronger POC asks:
Can this team make the AI useful, safe, trusted, and worth keeping inside the real work?
Those are not the same question.
The first question can produce an impressive demo. The second question tells you whether the organisation is ready.
So if you want your AI POC to work, give it a proper operating model.
- Give the sponsor actual time.
- Give subject matter experts allocated hours, not goodwill.
- Name who is accountable for the POC.
- Name who is responsible for training and adoption.
- Set a weekly rhythm for feedback and correction.
- Write down what good looks like.
- Capture the tacit knowledge as it appears.
- Decide what the agent can do, what it can suggest, and what it must ask.
- Be clear about what work stops or changes while people support the POC.
If nobody has time, the POC is not under-resourced. It is not real.
The uncomfortable bit
The uncomfortable truth is that many AI POCs are asking busy teams to train a new capability while pretending it is not extra work.
That is unfair on the team, unfair on the sponsor, and unfair on the technology.
If the agentic system is working in fuzzy areas, it needs supervision. It needs judgement. It needs correction. It needs people who can say, "No, not like that", and then explain why.
That time has to come from somewhere.
So the next time you launch an agentic POC, do not only ask what tool you are using.
Ask whose calendar is paying for it.
Ask who is onboarding it.
Ask who is responsible when the written process runs out and the real work begins.
Because one of your team members in that project may be agentic, but the work of making it useful is still very human.