The right deliverable isn't necessarily a piece of software. It's a lasting capability
For decades, the deliverable was what made consulting's value tangible: a report, a presentation to the executive committee, a structured recommendation. AI doesn't make these formats useless. What it does is make it far harder to confuse the document that reports on the work with the capability the client is actually buying.
The most important transformation, then, isn't the shift from PowerPoint to an AI agent. It's the shift from a deliverable designed as the end of the engagement to a system that keeps helping the client decide, act, measure or learn after the consultants leave.
The thesis argued here is this: the right deliverable for tomorrow isn't necessarily software. It's a durable capability. Depending on the problem, that can take the form of a supervised agent, an updatable dashboard, a simulator, an instrumented method, or even a document, when the need is precisely to lock in a decision. What changes is the final test: what will the client still be able to do, check or evolve once the consulting team is gone?
Part of the consulting industry now explicitly describes a shift "from the document to the living system": deliverables taking the form of interactive dashboards, supervised agents, simulators or platforms that can be updated after the engagement, extended through more iterative delivery — framing around expected outcomes, a fast proof point, then possibly continuous operation and improvement.
This trend, though, deserves a cautious reading.
The historical problem isn't that a firm produces a PowerPoint. A presentation can be exactly the right object for crystallising a strategic choice, documenting an executive committee's options, or keeping a record of a trade-off. The problem shows up when the value stops at the handover, while the engagement claimed to durably change how something gets decided or run.
A pricing-policy recommendation that ends up in a deck is fragile if teams can't reproduce the analysis three months later. A new operating model stays theoretical if nobody can measure gaps against the target model. A sales strategy is incomplete if teams have to call the firm back for every new simulation.
AI makes this weakness more visible because it lowers the cost of producing part of the analysis and formatting it. It shifts the question, then, toward the after: what's left once the analysis has been produced?
An NBER study published in 2025 offers an interesting reference point, even though it isn't about AI. Using Belgian administrative data spanning 2002 to 2023, the authors estimate that after engaging management or strategy consultants, client companies' labour productivity rises by an average 3.6% over five years; average wages also rise by 2.7%. The engagements observed are generally one-off and last less than a year.
What this shows: a consulting engagement's effects can persist well beyond the end of the contract. Consulting's value, then, clearly doesn't reduce to the immediate time consumed by the external team.
What it doesn't show: the study doesn't let us attribute these effects to a specific type of deliverable, let alone an agent, a dashboard or a skills transfer. It essentially covers a period before the current wave of generative AI. It absolutely doesn't let us conclude that a "living system" produces more value than a report.
This is exactly where the organisational question starts: if impact can last, what mechanisms let an outside intervention durably change internal behaviours, decisions or processes?
The deliverable is only part of the answer.
Current practices at the big firms aren't representative proof for the sector. They do, however, give interesting clues about the direction some offerings are taking.
McKinsey: from an internal tool to an architecture the client can adopt
McKinsey built Lilli as an internal platform for querying the firm's knowledge base. McKinsey says 72% of its people use the platform, and reports gains of up to 30% on research and synthesis. More interesting for our purposes: the firm says it uses the experience gained with Lilli to help clients build their own comparable systems, and offers a version of the underlying architecture for certain client use cases. These are figures and details published directly by McKinsey, and so are self-reported.
This case doesn't prove every client needs its own Lilli. It shows something more limited: an asset originally built to augment consultants can become something transferred to the client organisation.
The logic then changes. The firm's knowledge isn't just used to produce a recommendation anymore; it helps build a mechanism that gives the client more lasting access to its own knowledge.
Deloitte and HPE: co-building a tool used inside the finance function
Deloitte and Hewlett Packard Enterprise say they co-developed "CFO Insights", a solution combining generative AI and agents on Deloitte's Zora AI platform. Deloitte also presents Zora as an architecture that can be delivered as SaaS or installed in clients' cloud or on-premise environments.
Here again, this is a case presented by the vendor itself. It doesn't offer an independent ROI evaluation and doesn't allow for generalisation.
But the commercial object is telling: the outcome of the consulting relationship is no longer exclusively a recommendation addressed to the CFO. It can become a system the finance function keeps using.
PwC: the consulting asset becomes an orchestration layer
PwC now sells an "agent OS" designed to orchestrate agents from multiple vendors and integrate them into company processes, with oversight functions built in. The platform is advertised as compatible with a range of systems and vendors, including Microsoft, AWS, Google Cloud, OpenAI, Anthropic, Salesforce, SAP and Workday. Here again, this is a commercial description published by PwC, not an independent demonstration of performance.
The organisational signal is still interesting: the firm is no longer only selling its expertise on how to organise agents. It's also trying to supply the infrastructure to run that organisation.
These cases don't let us declare "the end of the deliverable". They show a new continuum emerging between consulting, software, integration and operations.
The transformation of deliverables isn't independent of the business model.
In an interview published in 2026, BCG's CEO says three-quarters of the firm's largest AI projects now include a variable, outcome-linked pay component. He immediately clarifies that across the whole of BCG's business, the share of engagements using this kind of mechanism stays well under a third. This is a self-reported figure from the firm's own leader; it doesn't describe the market as a whole.
That nuance matters.
AI isn't suddenly giving birth to value-based pricing: these contracts already existed. But when a firm supplies a system that keeps generating, measuring or influencing a result, it becomes more natural to discuss usage, availability, performance, licensing or outcomes, rather than just days consumed.
This is also why asset-based consulting is taking up more room in the sector's thinking: automated diagnostics, sector-specific agents, platforms, cockpits, datasets or reusable methods become assets to maintain, version, and sometimes monetise over time.
The firm then edges closer to a product business. And with it come problems the deck never had: maintenance, intellectual property, security, running costs, versioning, support and obsolescence.
It would be easy to conclude a good firm should now end every engagement with an agent or a platform.
That would reproduce exactly the mistake AI is supposed to fix: confusing transformation with equipment.
A panel of thirty companies observed for their organisational signals — not representative — shows this in a different context: several companies have integrated AI without fundamentally overhauling their organisation. The tool, then, can move forward without decision rights, accountability or the division of labour genuinely changing.
An agent handed to a client can suffer the same fate as a forgotten report.
All it takes is no team owning it, the data no longer being refreshed, nobody knowing how to interpret the alerts, the model provider changing its terms, or the business process evolving. The object stays technically available, but the organisational capability is gone.
A living system is only alive if the organisation using it knows how to keep it that way.
This is why the important notion isn't "technological deliverable", but operable capability.
An engagement that claims to durably transform an organisation should aim to leave behind five layers of value.
Transferable reasoning. The client needs to understand the assumptions, criteria and trade-offs that lead to a decision. AI doesn't lower this bar: it raises it. A result produced quickly but impossible to explain becomes hard to defend.
A reuse mechanism. That can be a calculation model, a simulator, a framework, a workflow, an agent, or simply a method formalised enough to be re-run without rebuilding the whole analysis.
Observable proof. A useful system has to make what it produces visible: source data, indicators, assumptions, quality, error rate, any exceptions — with traceability, versioning of sources and prompts, testing, and human control once AI artefacts go operational.
Internal accountability. Someone at the client needs to know who updates, validates, halts or evolves the system. With no owner, a living asset quickly becomes an orphaned one.
Human capability. The client needs people who know how to use the mechanism, challenge its results, and modify it as its environment changes.
This last layer is probably the most important.
A firm can leave behind the best simulator on the market while actually increasing its client's dependence. Conversely, a simple method, properly understood, practised and built into how the company runs, can produce lasting effects.
The right form depends on the decision or work the engagement is trying to improve.
| Form left with the client | Relevant when… | What genuinely needs to remain | Main risk |
|---|---|---|---|
| Decision document | A one-off trade-off needs to be made explicit, defended and archived. | Assumptions, options, the decision, accountability. | Mistaking a continuous problem for a one-off one. |
| Dashboard / cockpit | A situation needs regular monitoring and reassessment. | Reliable data, indicators, thresholds, an owner. | A dashboard that gets viewed but drives no decision. |
| Simulator | Leaders need to regularly re-run scenarios. | The model, editable assumptions, documentation, usage rules. | A false sense of precision, or a model that's never updated. |
| Supervised agent | A repeatable activity can be partially executed. | Context, permissions, evals, human controls, logging. | Delegating accountability along with the task. |
| Instrumented method | The main goal is making teams self-sufficient. | Process, templates, examples, training, an improvement loop. | A formal methodology that never gets built into real work. |
This grid avoids turning "living system" into a maturity ladder where the agent would necessarily rank above the document.
A board deciding on an acquisition doesn't necessarily need a permanent agent. It needs a robust, defensible case file.
A pricing team that has to revise prices every week probably needs a simulator and a reusable decision process more.
A support function facing thousands of requests every day, on the other hand, can benefit from a supervised agent.
The format should follow the nature of the decision, not the technology trend.
As soon as a firm leaves an operational asset with its client, the engagement no longer fully ends at handover.
Who maintains the agent? Who adapts the simulator to new regulation? Who checks the data is still correctly feeding the dashboard? Who funds a migration when a model vendor changes? Who's on the hook when the automatic recommendation turns out to be wrong?
These questions push the firm closer to operating like a software vendor or a managed service.
That logically means managing certain deliverables like products: an identified owner, test suites, security protocols, versioning, ongoing operational upkeep, a licensing model, and a regular call between maintaining and sunsetting.
But there's a mirror-image risk.
A firm obsessed with "productisation" can end up only chasing problems standardised enough to use its assets. The client's problem then becomes an occasion to sell the platform, rather than the platform a means of solving the problem.
What differentiates consulting remains precisely its ability to work in situations where context, power dynamics, trade-offs and human behaviour matter.
The living system, then, shouldn't remove the consultant's judgment. It should stop wasting that judgment on permanently rebuilding what could be codified instead.
A paradox shows up here.
For the client, the best transfer is the one that increases their autonomy.
For the firm, a recurring asset can, conversely, create a subscription, usage, and steady revenue.
These two interests aren't necessarily incompatible. But they need to be made explicit.
A dashboard hosted only in the firm's environment, impossible to export, can prolong the commercial relationship while reducing the client's autonomy. An agent whose prompts, rules and data are opaque can become a new black box. A simulator that needs the firm to step in every quarter just to change three assumptions isn't really a transferred capability.
The question, then, becomes almost contractual:
What can the client still do the day after they decide to stop working with us?
A firm can legitimately protect its pre-existing assets and intellectual property, by distinguishing the firm's own assets, co-created assets, and data that belongs to the client.
But transferring a capability requires, at minimum, making usage rules, accountability, reversibility and the level of autonomy actually acquired explicit.
Without that, the "living system" mainly risks becoming a living contract instead.
For a partner or a manager, this shift changes the very way an engagement gets scoped.
It's no longer enough to ask: "What will our final deliverable be?"
The better question becomes: "what capability needs to exist at the client after the engagement, and what needs to stay human for it to work?"
That framing forces you to think about operations much earlier.
It also changes team composition. Building a robust simulator requires linking domain expertise, data and user experience. Putting an agent into production requires integration, evaluation and governance skills. Transferring a method requires teaching skills and change management.
That doesn't mean every consultant needs to become a developer.
It means the boundary between "analysis", "system design", "implementation" and "adoption" becomes less watertight.
The firm has to know when to stop at advice, when to build, when to partner with a technology player, and when to explicitly organise the transfer to internal teams.
At this stage, none of the sources examined lets us prove that engagements leaving behind an agent or a dashboard systematically produce more value than ones that conclude with a report.
The current examples of firms building platforms mainly show an evolving offer. The performance figures published by firms or their partners often remain self-reported. The available academic data on consulting's effects measures overall outcomes but doesn't identify the causal role played by deliverable format.
It would, then, be premature to declare PowerPoint dead.
The reasonable takeaway is more precise: the more continuous, repetitive, measurable, and dependent on evolving data a problem is, the less a static document can suffice on its own. Conversely, the more a problem involves a singular, political or irreversible trade-off, the more a document structuring the decision can keep its full value.
The shift isn't ideological. It depends on the problem.
Consulting shouldn't aim to systematically leave more technology at its clients.
It should aim to leave more capability.
Sometimes that capability will be technological: an agent, a cockpit, a simulator, or a platform.
Sometimes it will be organisational: a new decision loop, indicators, roles, and decision rights.
Sometimes it will be human: managers able to use the system, challenge its results, and keep progressing without the firm.
PowerPoint becomes insufficient when the engagement deals with a living problem and the document can't live alongside it.
But the agent becomes just as insufficient when it's handed over with no owner, no governance, and nobody able to supervise it.
The transformation of the deliverable, then, isn't the shift from slide to software. It's the shift from recommendation to operational autonomy.
These positions shape the way we approach IT recruitment in the age of AI. Let's talk about your context.