Don’t Sell Thinking
Software must either disappear into the work or give thought a place to land
I internalized something interesting recently: while AI makes it easier than ever to write down what happened, teams are still losing the plot.
Every meeting has a transcript. Every customer call has a summary. Every agent run ends with a tidy report. Every product discussion can be turned into bullets, themes, risks, action items, and next steps. We create more artifacts without creating more knowing.
The mistake is treating thinking like the product. It is not. Thinking is becoming ambient. It is in every inbox, editor, meeting, dashboard, repo, support queue, and text box. The hard thing is being able to make these thought-shaped artifacts survive contact with the organization.
You can see this most clearly in customer work where a call ends, and the AI produces a perfectly reasonable summary. It captures the request, the follow-up, the sentiment, and the action items. Everyone skims it and nods… the record exists, at least in the most literal sense. Two weeks later:
What did the customer actually mean?
Were they asking for a dashboard, or were they trying to say they get surprised every Monday because nobody can tell them what changed?
Did we already decide not to build this?
Was that a real decision, or just something someone said in a meeting?
Did engineering push back because the idea was wrong, or because the right version is expensive?
The issue is that the summary did not become part of what the company knows. It did not update the account context. It did not travel with the roadmap conversation. It did not preserve the customer’s actual language before it got laundered into product-speak. It did not separate the solution they asked for from the problem they were trying to express. It did not become something a PM, engineer, founder, or account lead could rely on later when the question came back in a different form. In Meditations, Marcus Aurelius has the line:
“The things you think about determine the quality of your mind.” — V. 16
The same is true for companies, except companies do not have minds in the clean individual sense. What a company thinks about, however, is what survives.
This then is the dead zone for AI software: cognition without consequence.
The model will compress the conversation, name the themes, and produce something legible which is not the same thing as memory. Most products now generate the notes, the spec, the recommendation, the ticket, the plan, or the answer, and then leave the actual organization unchanged.
This is not a problem with model capability but the product assumptions around them. A lot of AI software has just updated an old workflow by adding a button that generates the artifact faster. But if the original workflow was already bad at preserving context, making the artifact cheaper does not fix it.
This is why the “AI wrapper” conversation feels so tired to me. The useful question is really whether the product around the model knows something, remembers something, or changes something that the model does not do by default.
Once you frame it that way, the shape of durable AI software gets clearer. It either disappears into the work, or it gives thought a place to land. The first kind runs quietly in the background, before the user asks, in the place where the work already happens: spam filters, fraud check, deployment guardrails, sync engines, the thing that becomes part of the floor. This matters, but I am more interested in the second kind: software that takes cheap, abundant thinking and turns it into the stuff organizations actually benefit from later.
The better version of an AI meeting summary is a product that notices the same pain appearing across four enterprise accounts, links the call to an existing roadmap bet, preserves the customer’s language, carries the accepted interpretation into the spec, and attaches the eventual ticket back to the original conversation. It lets engineering see why the work matters. It lets sales see what was actually committed. It lets the team ask months later why a decision was made and recover the reasoning without reconstructing it from Slack archaeology and half-remembered meetings.
The same pattern shows up with coding agents. The better version captures the command, the result, the diff, the failing test, the fix, and the remaining risk. It links the change back to the original goal and makes verification part of the work itself, not just part of the story the agent tells afterward. That is still memory, just with different consequences: the organization can know what changed, why it changed, and whether the claim survived contact with reality.
This is where software still matters. The model does not know your company by default. It does not know which customer promise still haunts your roadmap, which decision was real, which concern was political, or which constraint if violated creates pain somewhere else. Even when a model can infer some of that, inference is not enough. Organizations do not run on plausible answers. They run on commitments, records, permissions, incentives, trust, and memory. They run on the difference between “this seems right” and “this is now how we work.”
Do not sell thinking. Sell the thing where thinking becomes memory, coordination, verification, and change. Or disappear so completely into the work that the user no longer has to think about you at all. The dangerous middle is the next newfangled polished destination for cognition, a login for wrapped intelligence, a product that assumes users will pay for access to thinking when thinking is becoming a basic property of software.
Thinking is becoming ambient so build the thing that makes thinking matter.