How I work

In short

I use three methods, in the order they are needed. Value Intelligence decides whether an AI initiative is worth the spend, counting hours given back and requests for help instead of features shipped. Safe-to-Learn tests the idea in a separate environment before asking for budget. Portable Operational Memory keeps the company's context apart from the model of the moment, so changing technology does not mean starting over.

The stated problem is almost never the problem. That is where the work starts.

A company says: we need an AI agent for customer service. It may be true. But the same sentence can mean the answers live in four different systems, nobody knows which one is right, and an agent built on that data would give wrong answers faster.

Three methods came out of that gap between what gets asked for and what is needed. Each one answers a different question:

The order matters. A perfect prototype of a problem that was worth nothing is still worth nothing.

Value Intelligence

AI initiatives are almost always justified by counting features shipped. That is the wrong measure.

A feature nobody uses costs as much as one everybody uses.

Value Intelligence moves the investment decision onto the value obtained, measured as cost reduction and process efficiency, and does it before the budget is committed. I designed it in my current role, and it is now how decisions are made on Salesforce and Agentforce initiatives.

Where I look first

A process is as slow as its narrowest step. Improving any other point does not change the result, it just moves the queue somewhere else.

It happens a lot with sales automation. Lead qualification gets automated, inbound requests double, and closed deals stay where they were, because the bottleneck was never qualification: it was the engineering team preparing the quotes.

A good investment in a point that was not the constraint returns zero.

So the first question is not which technology. It is: which obstacle, if it disappeared, would actually change the result?

How I find it

Not by asking whether people like the idea. By asking what has already happened.

"Would an AI agent help you?" gets polite answers. "When did a sales rep last lose half a day chasing information, and what did it cost?" gets facts. Budget already spent trying to solve a problem says more than any forecast, because it is a decision already made with real money.

What I measure

One use case, with the number chosen before starting and a written criterion for stopping. I use two numbers:

A committee accepts them because they can be counted. On the knowledge base we made queryable in SharePoint and Teams, the number was the second one: internal support tickets down more than 30%, across roughly 2,000 users, in the two months after launch.

The stopping criterion is the part most often skipped, and the one that matters most.

Large programmes rarely fail. They continue, and absorb budget, because stopping them requires someone to admit a mistake.

Safe-to-Learn

Value Intelligence says what is worth testing. Safe-to-Learn says how to test it without touching the company's systems.

In a listed company you do not connect an AI tool to production systems to see what happens, and there is a good reason for that. But if evaluating a hypothesis takes two months, by the time the evaluation ends the model has changed, the feature is new, sometimes the product is different.

Technology changes faster than an organisation can absorb it.

To find out whether an idea can work, though, you do not necessarily need production data. Salesforce provides free demo environments, separate from the corporate org: there I explore a capability, build a working prototype on sample records, and gather evidence before asking the company for a wider evaluation.

I call it Safe-to-Learn. It does not separate a before and an after governance, it separates two questions that always get confused:

  1. 01 Discover Can this idea work? A clean demo org, official documentation and Trailhead MCP. No connection to the corporate org. Evidence the idea holds up · Technical feasibility
  2. 02 Prototype Can I demonstrate it? Same demo org, sample records. With the Salesforce CLI I bring across the field structure of one or more objects, so the environment resembles the sandbox connected to real company data. Working technical evidence · Technical feasibility
  3. 03 Pilot Does it work for this company? First the sandbox connected to real data, then a pilot in production: bounded scope, selected users, reviews proportionate to the risk. Enterprise validation · Enterprise readiness
  4. 04 Production Can we scale it safely? Scaling in production: authorisation, security, access control, monitoring, ownership, audit and lifecycle. Ready to be operated · Enterprise readiness

Security and authorisation requirements apply at every stage. What changes is the depth of the controls, which follows the risk and the consequences.

Before the pilot you need three names on a sheet of paper: who answers for security, who for compliance, who has the final word. If you do not choose them at the start, you meet them halfway through, when they say no and everything stops.

Sandboxes have existed forever, so the novelty is not technical: it is who uses them and why. A developer opens a sandbox to test a feature, whereas here an isolated environment serves whoever has to decide, to test a business hypothesis before committing serious company resources.

My goal is not to bring an idea to the architecture team. It is to bring an idea backed by working technical evidence.

In a large company every idea costs something before it is even approved: people, analysis, architecture, meetings, a business case. A prototype that costs days kills weak ideas early and exposes the real dependencies, so architecture and governance only work on what already has evidence behind it.

The goal is not to produce more AI pilots. It is to decide better which pilots deserve to exist.

Portable Operational Memory

Safe-to-Learn is about how you experiment, and the question that follows is what survives. Models, agents and interfaces change frequently, and that has a real impact on cost and on what stays technically available: if we build every process around the agent of the moment, we rebuild that process every time the technology turns over.

I picture it as an external memory with a lot of USB ports. The company plugs in whichever model it wants, whenever it wants, and keeps the memory.

Inside there is more than the data:

It is not necessarily a new database, it is a logical, governed layer over the systems a company already has.

Conceptual architecture: this is my proposal, not an architecture already built across all of these layers.

Portable does not mean moving sensitive data between vendors. It means designing interfaces, semantic contracts, authorisations and capabilities so that different tools can reuse them, always under company policy.

Models and interfaces should be replaceable. A company’s operational memory should not be.

Autonomy, then, is not a property of the agent but of the individual capability. An agent that summarises public documentation and an agent that can change a customer’s opportunity are not the same governance problem: put both through the same process and you create pointless friction on the first, give the second the freedom of the first and you create a risk nobody should accept.

When the answer is no

Sometimes the right answer is that the project is not needed, or not yet. That is an answer too, and usually the cheapest one.

In your company, did the last AI initiative that got approved have a number decided before it started?