THINK
We help enterprise leaders identify where AI can create measurable advantage, then turn that ambition into a roadmap, operating model, investment case, and delivery system.
Where value at stake meets delivery feasibility. Placing each candidate on both decides whether it is funded first, given a precondition, kept cheap or declined in writing.
Use-case prioritisation →By settling before the first sprint what stalls most portfolios: which process, whose data, who owns it, and what happens when the model is wrong.
Why portfolios stall →Each use case is given a risk tier before it is funded, must show evidence at four gates, and carries a named condition that would pause it once it is live.
The four gates →The roadmap’s first horizon, planned as months 0 to 3, ends with one system running in production, with evaluation evidence and a named owner.
The three horizons →Against a baseline taken before anything ships. Each value claim carries a target, a measurement method agreed in advance and an owner after go-live.
The value model →The business problem
Most AI strategies fail at the handover to engineering: ambition gets funded, but the operating model, data realities, governance, and capability plan are missing.
Why AI portfolios stall
Six places an enterprise AI portfolio actually stops. None of them are a modelling problem, and all of them are decided before the first sprint.
The business case names a value pool and a technology. Engineering receives a budget and an ambition rather than a use case, and the first real decision (which process, whose data, what happens when the model is wrong) is taken by whoever happens to be in the room.
Feasibility gets judged on how convincing the prototype looks, which selects for use cases with no integration surface and no consequence. The portfolio then stalls at the first case that touches a system of record.
Access, lineage and quality turn out to be the programme rather than a precondition to it. The roadmap is already public by then, so the work gets done quietly and the dates slip without an explanation anyone believes.
Decisions that need a business answer queue behind a committee that meets monthly. The delivery team either waits or decides for them, and both outcomes are recorded as a delivery problem.
A policy that reviews model choice and training data has nothing to say about an agent that takes an action in a live system. The first agent either waits for a policy that does not exist or ships outside one.
The system works and nobody inside the organisation can change it. Capability is treated as training to be arranged later, rather than as the condition for the second use case costing less than the first.
The problem is rarely the absence of AI ideas. It is the absence of an executable portfolio.
Captivolt point of view
What the organisation can execute this year decides which use cases are worth funding first, whatever the ambition.
An assumption with an owner can be revisited. One without is defended until nobody believes the number.
Criteria agreed afterwards tend to describe what was built rather than what was needed.
Readiness
Strategy written without this produces a roadmap the delivery team cannot accept. Seven dimensions, assessed against evidence in your own systems rather than a maturity questionnaire.
Whether there is a funded owner with a decision to make, an agreed value pool, and an appetite to change the process itself, not only an interest in AI. A programme without this stalls long before the technology is the constraint.
What can be accessed, under whose permission, with what lineage and what known quality problems, and whether anybody owns it.
The integration surface: what can actually be called, what only exists as a screen, and where a write is possible rather than a read.
Where the decision sits today, who makes it, how often it is reversed, and what evidence the person making it currently uses.
What exists for models, what exists for actions, and which regulator or auditor will ask. The gap between those two is usually the programme risk.
Who can build, who can operate, who can review: named, not counted. A capability gap is a sequencing constraint, not a training budget.
Whether the organisation can ship and run software it did not buy: environments, release path, on-call, and the appetite to own a system rather than a licence.
Exploring
Pilots and ideas, with no agreed agenda and no owner beyond the sponsor.
Piloting
Use cases funded one at a time, with data, governance and ownership settled per project.
Operating
A funded portfolio, named owners and shared foundations, with systems running in production.
Scaling
New use cases land on existing foundations, and internal teams run what gets built.
Illustrative: the structure we produce, not a client deliverable
There is a short version of this you can run now. Eight questions, no sign-up, and it ends on the stage you should start at rather than on a contact form.
Run the AI Readiness DiagnosticUse-case prioritisation
Value at stake against delivery feasibility. The quadrant a use case lands in decides what happens to it, including the two quadrants that produce a decision not to build.
The first production system: one use case, end to end, with evaluation evidence. It also does the work of finding out what the platform beneath it has to be.
Worth doing and not yet buildable. Whatever has to be true (an access path, a lineage fix, a control that does not exist) becomes a funded work item with an owner, rather than a use case that keeps slipping.
Useful for building the team’s muscle and for learning the release path. It is not a programme, and it should not be the thing the board is shown.
The list of what you are not doing is part of the strategy. Left unwritten, it returns every quarter and costs the portfolio its credibility each time.
| Opportunity | Value at stake | Feasibility now | Where it lands |
|---|---|---|---|
| Customer-service assistant over existing knowledge | High: volume work with a measurable handling time | High: the content exists and the workflow is bounded | Fund first |
| Contract intelligence and obligation extraction | High: risk and effort both sit in the same documents | Medium: depends on document access and retention rules | Name the precondition |
| Autonomous approval of financial transactions | High: the effort is real and repetitive | Low: irreversible actions, and accountability is unresolved | Decline, in writing |
Value model
Four inputs, kept apart on purpose. A business case that blends a measured baseline with an adoption assumption cannot be checked later, which is how AI value claims stop being believed inside an organisation.
Growth, conversion, cross-sell: value that shows up as money coming in.
Cycle time, effort and throughput: the same work done with less of someone’s day.
Error reduction, consistency and decision quality: fewer things done wrong.
Governance, compliance and operational resilience: exposure that no longer sits open.
Where the money or the time actually sits, named as a process with a volume and a current unit cost. Not a market study, and not a percentage of revenue.
The number as it is today, captured before anything ships. A claim about improvement is unverifiable without it, and taking it afterwards is not the same measurement.
What share of the pool is addressable, at what adoption, by when, stated as an assumption with a named owner, so it can be revisited rather than defended.
Build, run, inference, evaluation, monitoring and support. Evaluation and monitoring are the two that get left out, and they do not stop when the project does.
Architecture implications
This is the handover a strategy deck normally omits. Every decision on the left has a consequence on the right that someone has to engineer, pay for and operate, and the time to know that is while the decision is still open.
Every strategic AI decision has architecture implications, and they land in the same four-layer architecture the rest of this site describes.
We engineer against the systems you already run, through the APIs where they exist and the integration work where they do not, and a call carries the permissions of whoever made it.
Permission-aware retrieval, semantic modelling and lineage, so an answer can be traced back to a source the caller is allowed to see. This is the layer a document dump into a vector store skips.
Models chosen per task rather than per vendor, agents given explicit tools and a defined authority to act within, and an approval step on the actions that are hard to reverse.
The workflows and applications that act on the output, with an audit trail per action rather than per conversation, so what was done, by which agent and under whose authority, is answerable afterwards.
Identity-scoped tool permissions, an approval step on consequential actions, and an audit trail per action rather than per conversation.
A context layer with retrieval, permission inheritance, freshness and lineage, not a document dump into a vector store, which is the shortcut that fails at the second business unit.
Evidence produced at decision time and retained with the record. Explanation reconstructed afterwards is a report, and it is not the same artefact an auditor asks for.
Tenancy, cost attribution and a shared evaluation harness. Six local harnesses is the same spend with none of the comparability.
Deployment into your cloud, identity and network boundary, which constrains model choice, and is cheaper to know before the model is chosen.
An abstraction at the model boundary and a regression suite that survives the swap. Without the suite, the second model is a rebuild dressed as an upgrade.
Operating model
Four layers of accountability, and the decisions each one actually holds. Most AI operating models name the layers and leave the decision rights implicit, which is why funding, architecture and release approval all end up at the same steering committee.
Owns the portfolio, the money and the risk appetite. Decides what is funded and what is stopped.
Target architecture, evaluation policy, reusable assets, model and vendor decisions. Small, and staffed by people who still build.
AI, data, software, cloud, QE, security and product in one team per value stream. The pod owns the release.
Context layer, evaluation harness, observability, incident path and cost attribution: operated, not project-funded.
Illustrative: the structure we produce, not a client deliverable
Governance
Programme governance: what a use case has to show to move from idea to funded to built to released. The controls inside the system (evaluation, guardrails, monitoring) are a separate discipline, and this is the decision layer above them.
Illustrative: the structure we produce, not a client deliverable
Roadmap & investment sequencing
The roadmap says when; the sequencing says how much, and why in that order. Each horizon carries an exit test, because a horizon with no test to leave it is a date rather than a plan.
It runs in production, with evaluation evidence and a named owner.
The second use case costs materially less than the first did.
The organisation ships and operates without us.
Illustrative: the structure we produce, not a client deliverable
Do not fund twenty AI experiments independently. Fund the reusable foundations, then the vertical slices that prove them.
Shared data and context, identity and permissions, evaluation, and the platform pieces more than one use case will need.
These are the parts every later use case assumes exist. Funded per use case, they are rebuilt badly three times.
Agent workflows, retrieval, and the automations the prioritisation matrix put in the funded quadrant.
A platform with no consumer is a cost centre. These prove the foundations and pay for the next increment.
Low-value ideas, and high-value ones whose preconditions are not met yet.
Deferred in writing with the precondition named, so it is a decision with a trigger rather than a queue nobody revisits.
Capabilities
The method above is delivered in these eight engagement forms. Most engagements combine two or three: a diagnostic and a roadmap sprint, or an operating-model design with standing advisory through delivery.
Assess data, systems, governance, people, process, and delivery maturity to determine what the organisation can realistically execute.
Define priority use cases, target architecture, investment sequence, ownership model, and execution roadmap.
Quantify AI value pools, delivery cost, adoption assumptions, and measurable business outcomes.
Design the AI CoE, governance cadence, decision rights, delivery model, and cross-functional engagement rhythm.
Define delivery pods combining AI, data, software, cloud, QE, security, and product capabilities.
Define roles, skills, levels, competency standards, and growth pathways for AI and engineering teams.
Redesign business workflows so agents, copilots, and automation fit real operational processes.
Provide senior AI and technology leadership for AI architecture, vendor decisions, governance, and execution oversight, without a full-time hire.
Use cases
How Captivolt delivers
Typically a 4–8 week diagnostic and roadmap sprint, followed by ongoing advisory or fractional CTO support through delivery.
Evidence
Relevant accelerators
The registers the governance section calls for: system inventory, risks and exceptions, decisions and evidence.
A first read of where the organisation stands across strategy, build, assurance and capability.
A structured first conversation about what you are trying to build, govern, or scale.