Your POC Tests the Business Case, Not the Technology

Every AI agentic proof of concept sets out to answer a question, but often teams focus on the wrong one.

The question they often try to answer is: Can the technology do the task? Can an agent draft the email, collate the report, summarise the content? 

For most well-chosen use cases, the technical question is already answered, even if the outputs may still feel incredulous because of the pace of innovation. Frontier models already draft competent first-pass content. Agent platforms, such as Optimizely’s Opal accurately collate data across systems and provide high-quality reasoning and insight over the top.

It’s a waste to use a twelve-week engagement to confirm what a vendor demo can show you in twenty minutes.

Should we keep paying for it?

Strip away the theatre and a PoC exists to inform exactly one decision: Do we invest further, or do we stop?

That's a commercial decision, and so needs commercial evidence. Does the time saved justify the licence cost, the configuration effort, the ongoing maintenance? Does output quality hold up against a human baseline, not in a demo, but across real briefs, real amends, real deadlines? What does it actually cost to run, govern and improve?

It’s vital to learn this as early as possible before you have an albatross hanging from your neck

I’ve seen organisations make these mistakes in MarTech before. Email Marketing Automation promised automation of marketing decisioning, outbound communication and personalised follow ups. The tech worked, but some of the most expensive white elephant projects I’ve been involved in were caused because the operating cost and skills required to execute were significantly more expensive than the (already large) license costs. Great tech, but you had to invest heavily to realise a return. 

Learning this late is very expensive and disruptive.

Design it backwards 

Start from the decision. Ask what evidence the budget holder will need, the numbers, the quality comparisons, the cost model and build the PoC to generate that evidence as a first-class output.

Working with a regulated financial services marketing team, we made this explicit. The proof-of-concept phase was designed to do two jobs at once.

Job one: prove the use cases. Take the prioritised tasks, the repetitive, data-heavy, low-judgement work surfaced in discovery and demonstrate that agents deliver measurable value on real examples. Time saved. Quality proven. Effort quantified.

Job two: prove the operating model. In a regulated environment, the technology working isn't the barrier to adoption. Trust is. So the PoC was also the vehicle for tuning the platform's control and quality mechanisms on real tasks, approval gates, output evaluation, audit logging, demonstrating that "trust and control" is an observable property of the system, and one that the team feel confident in further refining moving forwards.

The second job is easy to miss, and it's the one that has most impact on adoption.  Governance hardened on real work beats governance designed in theory.

Choose use cases for what they teach, not what they demo

This reframing changes how you pick your Agentic PoC candidates.

It’s too easy to select AI use cases optimised for impressiveness: pick the use case that demos best. We select based on a dimension we call learning potential. Which use cases will teach us the most about whether this will work at scale?

Sometimes that means deliberately choosing the less glamorous option. A use case that stress-tests an approval workflow tells you more about enterprise viability than one that produces a prettier output. A task that requires the agent to read from your messiest system tells you more about your data readiness than one fed clean inputs. One of the most valuable PoCs you can run is a head-to-head: agent versus the incumbent process you're already paying for. The direct comparison is a consolidated business case in itself

The point of proving a concept

The clue was always in the name. A proof of concept is supposed to prove something and the concept worth proving isn't "large language models can write emails". The industry has established that.

The concept worth proving is that agentic automation, running inside your workflows, under your control, on your data, generates more value than it costs. That's what will get  funded. That's the case that survives the budget round.