The short version
I had two AI calls this week. One was with a CMO at a financial institution who is being sold a Salesforce Data Cloud transformation. The other was with an engineer in Latin America building a real product on a stack of vector search, fast APIs, and their own agent layer. They sit on opposite ends of the technical spectrum and they were making the same mistake. The CMO was buying more sophisticated silos. The engineer was building more sophisticated silos. The builder trap is the belief that you are supposed to assemble the parts. You are not. You are supposed to own the outcome and let the agent layer decide what parts are needed at all.
Both calls ran long. I am going to do something I do not usually do, which is publish the pattern straight from the field. The names are blurred. The conversations are intact.
Call one. The CMO at the financial institution
They run marketing for a financial institution. They found a post of mine on LinkedIn, remembered me from the Salesforce days, and asked for an hour because they are being pulled in nine directions at once. Generative AI in Copilot. Claude components turning on. OpenAI versus Anthropic. A Data Cloud project that just kicked off and is supposed to be the platform on which "everything else" gets built.
They told me what they are seeing on the ground. The Data Cloud rollout is, in their words, re-engineering. They are pulling everything that lived in Salesforce Marketing Cloud across the years into one centralized data layer. Then they will put an agent on top of it. The agent will do what Journey Builder did. The IT team that used to gate data tables and attribute permissions is no longer the bottleneck. One click pulls the audience. The brief is generated. The campaign goes out.
Then, almost as an aside, they said the sales team is so far behind that leads are dying off because no human follows up in time. So they are looking at an agent for the CRM too.
I asked what changed underneath all of this. They told me, with admirable honesty, "nothing has changed." They still have the same workflows. They are just telling a bot to do them now instead of building the automation themselves in Journey Builder.
That is the trap.
Call two. The engineer in Latin America
They are ex-McKinsey, ex-large-platform engineer, now running their own small business in Latin America with consulting work funding the bills and their own product on the side. The product is real. They have built a vectorization layer, a hybrid ML and text-mining ingestion pipeline, a modular ingestion architecture, a fast API in Python, and a Flutter front end. They showed me an insurance app they are piloting in Latin America with a partner. Centralized policy storage. A smart chat. Document understanding across messy PDFs.
They are doing in months what most engineering teams I have worked with at scale would do in a year. They are also being held back by the same trap as the CMO.
When I asked what was next, they walked me through a two-year roadmap. They knew the regulatory limits in Latin America. They knew which advanced features to gate behind premium pricing. They had thought about user counts, infrastructure costs, and per-seat economics. They told me they were planning to serve "maybe a thousand users" by next year.
I asked them: what if I gave you five hundred engineers tomorrow. What would you build? They started thinking in features. What if I gave you five thousand engineers and a thousand designers? They started laughing. What if you stopped writing code and stopped looking at code? They paused.
Same trap. Different costume.
Same trap, different costumes
The CMO is buying more sophisticated silos. Data Cloud is a beautiful silo. A Journey Builder agent is a sophisticated automation inside that silo. The CMO is one Salesforce upgrade away from the same shape of work they have been doing for ten years.
The engineer is building more sophisticated silos. The platform is beautiful. The vectorization layer is real. The three prototypes are aimed at three personas: insurance, legal, learning. They are building a feature stack for a buyer persona, the same way every SaaS company since 1999 has built.
In both cases the assumption is identical. There is a workflow. The workflow has steps. Each step needs a tool. Tools are bought or built. AI then drops into the steps and makes them faster.
That is not what is happening. That is not the trend. That is the old shape of work with a chatbot stapled on top. The most common form of it in 2026 is the silo with a chat sidebar bolted on, which the AI noise tax describes in more detail.
The actual shift is that the workflow itself is going away. The persona is going away. The role doing the work is going away. The outcome is the only durable thing left.
What outcome thinking actually means
A company I am advising builds software for energy traders. Their AI strategy is to give their analysts better dashboards. Faster calculations. More charts. They are investing real money into the model layer to make analysts more productive.
I told them: the analyst job will not exist in two years. Building a dashboard for that role is building a stable for cars. Build the software that replaces the analyst. The deal teams do not need a better calculation, they need the recommendation and the reasoning. There is no rule that says a human must sit between the data and the decision.
The same logic applies to the insurance app. The engineer in Latin America told me regulation prevents auto-renewal, so the feature is on hold. I asked them: who said the feature has to be auto-renewal? Send the policyholder a notification that says renew, click here. The model is not blocked. The outcome shifts from "I auto-renewed" to "renewal happened on time," which is the outcome the user actually wants. The regulatory wall is a wall around one specific feature. It is not a wall around the outcome.
The same logic applies to the CMO. The goal is not "build a campaign in Journey Builder." The goal is engagement growth on a member segment. Right now, AI is smart enough that they can say "increase engagement on segment X by one percent" and let the system work backward through audience, channel, copy, timing, and reporting. The campaign brief, the audience pull, the send, and the measurement collapse into one outcome request.
Outcome thinking is the only thing that stays stable when every layer underneath you is being re-platformed. There is a longer treatment of this in the impact loop in the handbook.
Three reframes I keep making people sit with
One. Stop building for personas
The persona model worked when software had to be sold to a buyer. The buyer decided what the software did. Marketing buyers bought marketing software. Sales buyers bought sales software. Analysts bought analyst software.
The work was never persona-shaped. The handoffs between personas were where the real value lived, and we never automated those handoffs because no buyer would pay for them. The software industry has not mastered the art of connecting a marketer to a salesperson to a customer in a meaningful way. We exchanged data through imports and exports, or we hired a project manager who sat on top and sent status updates.
The agent layer can finally do this. Not by replacing the silo tools, but by making the silo irrelevant. The outcome travels across what used to be a persona boundary because the agent has access to all of it. The CMO at the financial institution does not need a marketing agent and a sales agent and a CS agent and a project manager stitching them together. They need one agent with access to the full member workflow.
Two. Stop being the typist
This is the one I get the most pushback on, so I want to be precise. The engineer in Latin America is an excellent engineer. They like looking at code. They like understanding the structure. They have good reasons.
Claude Code, today, writes the kind of code most of us spend our days typing better than we do and faster than we do. I have not written a line of the typing in the system I have been building for the last three weeks. I describe outcomes. The system writes the code. It built itself a CMS, a CRM, a lead funnel, a scheduling layer, a content gallery, a memory layer, and a governance layer. I asked for none of those things directly. I asked for outcomes. It decided what it needed.
This is not the same as "engineers do not matter anymore." Senior judgment, the architectural calls, eval design, system boundaries, dispute mechanisms, those still need humans, and the more sophisticated the system gets the more they need humans. The nuanced version of this argument lives in the AI product engineer, and the new specialist roles that grow up around it are sketched in triad is dead, pods are dead.
The thing to stop is being the typist. If you are still being the typist, you are doing the lowest-leverage thing in the stack. You are also slowing the system down, because every line you type is a line the agent did not type, and the next line the agent types will conflict with yours.
This was hard for me. I used to write code. I do not anymore.
Three. Stop optimizing for ten thousand generic users
The engineer in Latin America told me their plan was to serve a thousand users, then a hundred thousand, then figure out how to commoditize. They are repeating the SaaS playbook. The SaaS playbook is dead.
There is no rule that says software has to be generic. The reason it was generic was that custom software was expensive to write and expensive to maintain. Neither is true anymore. The cost of custom is approaching the cost of generic, and the value of custom is significantly higher.
You can give every customer their own software. The framework you build is the only generic part. The instance is theirs. The agent maintains it. The agent fixes it. The agent extends it. You charge per outcome, not per seat. There is more on the pricing implications in per outcome pricing and on the broader economic shape in Jevons cliff outcome pricing.
This is also the answer to the CMO. They do not need to wait for Salesforce to ship the right vertical. They can have the agent build exactly what they need on top of the data, no app required.
The hour-long exercise I gave them both
Here is what I told the engineer at the end of the call. I am going to repeat it because I want anyone reading this to try it.
For one hour, do not type. Sit with Claude Code, or whatever your tool of choice is. Tell it the most ambitious outcome you can articulate. The thing you would never ask for because it sounds too big. Describe it. Walk it through what success would look like. Walk it through the constraints. Then tell it to plan.
When it comes back with a plan, your job is to push it. It will try to be conservative. You tell it: do not ask me, just build. Let it run.
Come back in an hour and look at what it shipped.
I gave this same exercise to the CMO in a different shape. I told them to stop thinking about which Salesforce module to turn on. I told them to write down the outcomes they would actually be evaluated on at year-end, the ones that would still matter if every system between them and the outcome disappeared. Then, for each one, to ask what agent stack would deliver this outcome end to end without them assembling it. A starting point lives in your AI agent fleet, and the strategic frame is in the product operating model.
Why this matters more than it sounds
The pace is the part most people are not pricing in. The closest real anchor I have is the 90-day SaaS-to-agents transition in this field report, a $30M ARR business that ran an 8-week legal review on a single lead contract on the way to a 21-month sunset of the legacy product. That is the actual clock, and it is the fast version, not the slow version.
The role that used to buy the application is being absorbed into the outcome layer. Systems of record will survive. Hybrid models, where customers pay a platform fee plus per-outcome, will be most of what gets sold over the next three years. Pure seat-based application SaaS is the part that breaks. The pricing reasoning is in per outcome pricing and Jevons cliff outcome pricing.
The same logic applies to careers. The switchboard operators did not stay switchboard operators by working harder. The job went away. The way to survive a wave like this is to step up a level, to own the outcome instead of the task. Project managers, analysts, and marketers who are still defining their job by the tools they operate are going to find themselves in the seat that was supposed to be optional.
There are still people who say "we cannot adopt AI here, we are in financial services, we are in healthcare." I have shipped software inside clinical workflows for years, including the healthcare company I sold a few years ago that now runs across large health systems for transcription and billing. The cycle time on a working prototype in that environment has compressed by roughly 1.5 orders of magnitude in the last twelve months. The eval work, the integration work, and the compliance review still take real time. The building part does not. Regulation is not the problem. The mindset is the problem.
There is a societal question underneath this. If the role goes away faster than retirement, healthcare, and tax structures can adapt, the dislocation will be real. Governments are not innovating at the speed of the underlying shift. That is what should worry us. The part that should not worry you is whether AI can do your job. Of course it can. The only question is whether you move up a layer before it does.
Pick one thing this week
If you do nothing else, do this. Write down the outcome you actually own. Not the tools. Not the feature requests. Not the roadmap. The outcome. One sentence.
Then ask one honest question. If you replaced every tool and every role currently between you and that outcome with a system that just delivered the outcome, would your job still exist?
If the answer is yes, you are in good shape. Focus there.
If the answer is no, you have time. Use it to learn how to operate the system that replaces what you do. The window is open. It will not stay open long.
Frequently asked
What is the builder trap?+
The builder trap is the belief that your job is to assemble parts (tools, features, code, dashboards) for a known workflow. The trap is that the workflow itself is going away under AI. The work is to own the outcome and let the system decide what parts are needed at all.
Why do you say most SaaS is dead?+
SaaS is a workaround for talking to a database with forms and lists, built for a persona buyer. Both halves of that model break under agents. Conversational AI replaces the form interface. The agent layer crosses persona silos, so there is no buyer for the silo anymore. Some systems of record will survive. Most application SaaS will not.
What changes if you stop writing code?+
You stop doing the lowest-leverage thing in the stack. Claude Code today writes better code than most engineers, faster. The constraint moves from your typing speed to your ability to describe outcomes and feedback loops. If you keep typing code, every line is one the agent did not write and will conflict with what it does next.
How do you make agents trustworthy enough to act on outcomes?+
Governance, memory, and feedback. Treat the system as one agent with access to everything, not many disconnected agents. Give it ground truth (data, transcripts, prior decisions). When it produces work you change, tell it what you changed and why. The feedback is what makes it better. Add guardrails that are real, like budget caps, model selection rules, and scope limits.
Does this apply in regulated industries like healthcare and finance?+
Yes. Regulations apply to specific actions, not to the outcome. I have shipped software inside clinical workflows for years, including the healthcare company I sold a few years ago that now runs across large health systems for transcription and billing. The cycle time on a working prototype in that environment has compressed by roughly 1.5 orders of magnitude in the last twelve months. The eval, governance, and integration work still take real time. The building part does not. The mindset shift is the unlock, not the regulatory environment.
What is the one-hour exercise you recommend?+
Do not type. Tell your AI tool the most ambitious outcome you can articulate. Walk it through what success looks like and the constraints it must respect. Tell it to plan. When it asks permission, tell it to just build. Come back in an hour. Look at what shipped. The point is to discover what is actually possible when you remove yourself as the bottleneck.
How do you charge for software when there are no seats and no features?+
Per outcome. The value the customer pays for is the outcome delivered, not the access. Pricing is a lagging indicator of the architecture, and the architecture is now outcome-shaped.

Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn