Building an AI data-driven strategy consultant

Clever data analysis combined with context graphs can help you build one

Back in October 2025, when I was still building Babbage, I noticed a pattern in what a bunch of prospective customers were telling us. They all wanted to use Babbage not because they wanted to track metrics (the intended use case of the then Babbage product), but because they wanted to move them.

Moving metrics

“Our average delivery takes 22 minutes. How do we bring it down to 19 minutes?”
”We currently convert 20% of our leads, and want to move that to 25%. What can we do?”
”3% of our orders get cancelled. My target is 1%. What should we do?”
”<big-box strategy consultant> has advised us to bring down our transportation costs. We need continuous insights for this”

All of this was straight up strategy consulting work, except that they were tactical enough that nobody would go to a big-box strategy consultant to do such work. More importantly, all of these were problems that could be addressed using data. And clever analysis of data could give continuous insights on how to move these metrics.

There is a subtle difference between tracking metrics and moving them. When you track metrics, they become a reporting tool, and when you are a reporting tool, people have weird expectations.

“Can you support this kind of graph?”
“We track this metric on a YTD vs LYTD basis. Can your tool do that?”
“Can you support our custom colours?” and so on..

And the moment you are a consulting tool; none of this matters. The reporting doesn’t matter. What really matters are the insights.

Consulting with big box strategy consultants

Excited about a potential pivot, I quickly spoke to two friends who are partners are big box consulting firms, in an attempt to validate the idea.

“What you seem to be able to build”, said consultant1, “is an excellent diagnosis engine. An AI that can continuously monitor data, and quickly identify when something is off, along with reasons on why that is off”.

“That is only part of the problem”, he continued. “The reason we are able to add value is the extensive case library we bring. As a leading global firm we would have seen hundreds of such instances across firms and geographies and industries. And we draw upon those to recommend what needs to be done”.

Clearly, unless we were going to be creative, we would have a cold start problem - where would we find this “case library” to draw upon?

Consultant2 was more straightforward. “The reason clients pay us is not just for the advice; it is for the trust that we have built with them. They pay us for the accountability apart from the insights. An AI delivering the same kind of insights will not be similarly valued”.

This is something I have heard from other places as well, and come to own (new blogpost coming up on that shortly) - the reason people pay consultants is for accountability, and this part is going to be hard for AI to disrupt.

Anyways.

Putting together data and context graphs

A month or two ago, the topic of “context graphs” became viral on LinkedIn. Proposed by partners at Foundation Capital, the concept is that capturing “decision traces” (why certain decisions were made) can enable AI to make much better context-sensitive decisions.

There have been arguments for and against the utility of context graphs, but in the context of providing continuous insights, and provide a ready “case library”, I think they can be rather useful. However, for them to be really useful, they need to be combined with fairly smart data analysis (which I’m not sure can yet be fully automated).

In the absence of an extensive global case library, the best one can do is to rely on the company’s own history. If you are looking at a large enough enterprise, it is unlikely that you are coming across unprecedented problems - whatever issues you see, it is likely that the same issue had come up in some part of the company at some time in the past.

Now, one won’t have formal data (structured or otherwise) from history that contain the precise decision traces. However, through some clever analysis, we can glean three things:

• Identify all scenarios in the past when this kind of a situation arose in some part of the company

• What actions the company took at each of these points in the past

• The outcomes of the said actions, along with the contexts in which those actions were taken

In other words, we can construct a backward-looking context graph based purely on structured data!

Suddenly we have an internal case library that an AI can actually put together based on the current situation. And because there is data available on the context of each historical decision (basically historical structured data can be used to retrospectively construct a “decision trace”), the system is able to recommend the most appropriate action at the current point in time.

The trust and accountability factor - I don’t (yet) know how to model for that!

Continuous insights

One issue with the standard strategy consulting model is that it is a one shot process. The consultant comes in, does a study, recommends some stuff, make some changes and moves on. And then things mean revert a little bit, undoing some of the work that the consultant does.

The other thing is that not all problems have big bang solutions. There is no silver bullet. Instead, improvement of a metric comes in “little drops” delivered continuously over a period of time - something unsuited to the traditional strategy consulting model.

This is another win for our AI-driven strategy consultant - there is no compulsion to give all insights at once. Those can trickle in over a period of time. And if you have a consultant who is ever-present, any slippage can be quickly monitored and reversed.

Unlocking new solutions

Ronald Coase is known for several things, of which one is the theory of transaction costs. In our context, when you employ an external consultant for some function, not all problems get solved because some are “too trivial”. The transaction cost of precisely defining the problem, constructing a contract, negotiating the price and handing it off to a consultant can be of the same order of magnitude as the actual price of solving it. And companies sometimes elect to simply not solve the problem, rather than going through all this hassle.

This leads to inefficiencies that can compound, all due to transaction costs. I had noticed this first hand when, after nearly a decade as a consultant, I had joined Delhivery to head up their analytics and data science.

Now, with what I have described above - an AI “strategy consultant that delivers continuous insights”, there is a system that can handle more trivial problem statements than what a consultant will be called in to advise on. That bridges the gap and solves problems that would otherwise not be solved. This is pure alpha!

Epilogue

Reading all this might be making you wonder why I’m writing this and not actually building it. It’s a combination of things, but one thing was that by the time we arrived at this formulation, we had been nearly two years into building Babbage, with not that much traction. I simply ran out of energy. The idea still remains valid, and I’m happy to implement it. I’m not willing to start a new company for that, though!