Publications

How to Choose the Right Intelligence for the Problem

By Natalie Gill-Mensah · August 2026

In 2025, MIT’s NANDA initiative published a study of enterprise AI adoption drawn from more than 300 publicly disclosed initiatives, 52 organizational interviews, and 153 executive surveys. Roughly 95 percent of enterprise generative AI pilots, it found, showed no measurable impact on profit and loss, against somewhere between $30 and $40 billion in spending. The figure went viral and deserves its caveats, since the study is preliminary and defines success narrowly, but the explanation behind it is the part I keep coming back to.

The researchers did not attribute the failures to weak models; they pointed to brittle workflows, poor integration, and misalignment with how the work actually gets done. That is not a tool selection problem. It is a problem-definition problem.

I am still learning to apply this well myself, but I have come to believe that the sequence matters more than the selection. Name the problem first, then choose the intelligence that fits it.

The most common version of the mismatch is expensive and easy to miss. An organization licenses a frontier model, points it at work that repeats every week, and concludes two quarters later that AI did not save them much time. They are right about the result and wrong about the cause. The task never needed something that could think. It needed something that could repeat.

Four shapes of problem

Most of the requests I hear from leaders fall into one of four shapes, and the shape tells you what kind of intelligence you actually need. The tool comes last.

Recall. The answer already exists, and nobody can find it.

This is the policy buried in a 200-page manual, or the contract clause someone will need at the worst possible moment. What you need here is accuracy grounded in your own material, with a visible source, which means the system has to read your documents rather than answer from whatever it absorbed in training. Organizations tend to underestimate how much of their apparent AI need is really this one, and it is the shape where a general-purpose chatbot will fail you most convincingly.

Reasoning. There is no clean answer, and you need to think it through.

Strategy questions, tradeoffs with no obviously correct side, decisions where the value is in pressure-testing your own logic rather than producing a document. This is the one case where you want the strongest model you can get your hands on, used as a thinking partner.

Repetition. You do this every week and it eats a day.

Intake, triage, formatting, routing, status updates. The requirement here is consistency rather than brilliance, and what you want is the same output every time, with a person reviewing the exceptions instead of the whole batch.

Production. You need the artifact by Friday.

The deck, the graphic, the video, the website, the one-pager for the board. Purpose-built tools beat general-purpose ones here, and the difference is not small.

The technical community has names for the architectures underneath these, retrieval systems for the first and agent frameworks for the third. If you are building, that vocabulary matters. If you are deciding, the diagnosis matters more.

If your organization already holds an enterprise license, this is where the question gets uncomfortable. One platform can serve all four shapes, and it can serve all four of them badly. The organizations that get value tend to be specific about which shape they are solving before they decide whether what they already own is enough.

Three questions before you buy anything

1. What does this problem actually need? To find, to think, to repeat, or to produce. This is the four shapes again, in the form of a question you have to answer out loud. If you cannot do it in one of those four words, the problem is not defined well enough to solve yet.

2. Where does the source of truth live? Inside your documents, or inside the model. If the answer has to come from your policies or your data, then a general model answering from memory is a risk, because it will sound right. That is the danger.

3. How often does this happen? Once is a reasoning task, weekly is an automation task, and the same request at different frequencies calls for a completely different build.

One honest complication: real organizational work is usually two shapes stacked. Grounded knowledge feeding a repeated process is the most common combination I see, and that is a design decision rather than a purchase.

The clearest version of this in my own work is a blueprint I built for my life, covering every lane I operate in. Personal, professional, community service, entrepreneurial. Notion holds it and Claude built it. Notion has its own AI, and I did not need it, because connecting the two gave me the split I actually wanted: Notion is the second brain where the information lives, and Claude is the workshop where I create, manage, and drive results in each lane. I run parallel projects there, one per lane.

The most useful piece of it is also the least glamorous. A daily scan runs against fit criteria I designed myself, updates the blueprint with the executive opportunities that match, and tells me which applications are worth my time in the week ahead. Grounded knowledge feeding a repeated process, which is the same stack I keep recommending to everyone else.

The habit I am still building is to start from the decision I am already losing time on, rather than from what a tool can do. Those two starting points lead to very different budgets.

What I use now

This is my current stack, grouped by shape.

Recall. Claude Projects, for working against a defined set of documents instead of general knowledge, where the output is only ever as good as what I put in. I have gotten stricter about that over time. Otter runs on some of my meetings, and the value is not the transcript, it is that decisions and commitments end up somewhere searchable instead of in five people’s separate notes.

Reasoning. Claude and ChatGPT, run against each other on anything consequential. When two strong models reach the same conclusion by different routes, that tells me something. When they diverge, that tells me more.

Repetition. Zapier for connecting systems, and Claude Code, Cowork scheduled tasks, and custom assistants for the processes I run often enough to justify building.

Production. This is where my stack is deepest, because production problems are the easiest to name and the fastest to verify. Canva and Gamma for visual and presentation work, Google’s Nano Banana image model and Midjourney for generated media.

ElevenLabs for voice. I have used it to clone my own voice for video narration and to produce ad voiceovers, and the quality is high enough that the real questions stopped being technical ones. They are questions about disclosure and consent, and they arrive faster than most people expect.

Lovable and Claude Code for building. Two of my sites are live and running on Lovable, designed without my writing any code, and the build is genuinely fast. I have built two apps and another site with Claude Code. What I would tell anyone considering this route is that speed of creation and cost of maintenance are separate questions, and the second one only shows up later.

This is a partial list. There are tools I am still working through, and this will look different in a year.

The layer most people skip

There is a category of tool that gets left out of AI conversations because it is not AI. For me that includes tools such as Notion, Google Drive, Gmail, GitHub, and Vercel.

These are where the work lives, and they are also the connection points that make AI useful at an organizational level rather than an individual one. The pattern is simple enough: a model on its own produces output in a window that someone then has to move somewhere, while a model connected to a system of record can read from where your information already sits and write back to where your team already works. That is the difference between a tool a few people use and a process that actually improves.

It also sets a floor. If an organization’s documents are scattered and there is no shared system of record, no amount of AI will solve a recall problem, because what looks like an AI gap is a knowledge management gap.

Before adding intelligence, ask what it will connect to.

The part that lasts

The MIT researchers found that the difference between the 5 percent and the 95 percent came down to approach rather than model quality, which matches the pattern underneath all four shapes. The organizations that got value were the ones that picked a real problem and built around it.

Platforms will turn over. Capabilities that require a specialized build today will be a feature inside something you already own within two years, so betting an organizational strategy on any single tool is a losing position.

Problem definition does not expire. It is the skill I am working on, and it is the one I would tell any leader to build first.

Name the problem. Then choose the intelligence.

Source note: MIT NANDA / Media Lab, “The GenAI Divide: State of AI in Business 2025.” Findings based on 300+ publicly disclosed initiatives, 52 organizational interviews, and 153 executive surveys. Preliminary and not peer-reviewed.

Views expressed here are my own and do not represent those of my employer or the U.S. government.