The default move when a team adds AI is to reach for the largest, newest, most expensive model available and assume quality follows price. Sometimes it does. Often it does not, and the team pays a premium for capability the feature never uses. Model selection is a cost decision as much as a quality one, and the two are not opposites.
Before choosing a model, it helps to know where the money goes inside one. On a model like Claude Sonnet, output tokens cost roughly five times what input tokens cost. That single ratio should shape your choices. A feature that reads a long document and returns a one-line verdict has a very different cost profile from one that reads a short prompt and writes three paragraphs. The expensive model that writes concisely can cost less than the cheap model that rambles. Price per token is only half the equation. What the model is asked to produce is the other half, and it is the half most teams ignore when they compare models.
A founder building an AI personal-branding tool learned the cost and quality question from the output side. Early generated content “sound robotic,” so bad that “anyone with sense of writing could identify it was written by AI.” His fix was not a bigger model. It was building a context layer, user-defined personas that gave the model something specific to work from. Only after that layer existed did upgrading the underlying model pay off. Rolling in newer, cheaper-to-run models on top of good context made the output, in his words, “just remarkable.” The order mattered. A frontier model on top of no context is expensive and still robotic. A modest model on top of good context is cheap and convincing.
The most disciplined model decision I have heard came from a founder building an enterprise collaboration product, who resisted the industry’s default entirely. “We are not a large language model,” he said. His product runs “our own proprietary AI that applies to the telemetry of your phone and laptop and calendar availability.” Large language models were a possible future for one narrow feature, not the engine of the product. He picked the model that fit the signal he actually had, a small model on structured telemetry, instead of paying frontier prices to answer a question that never needed one.
That is the point cheaper-isn’t-worse is really making. The question is not “which model is best.” It is “which model is enough for this specific job,” because the gap between enough and best is money you spend every single request.
A model selection that respects cost tends to check the same things:
Our AI Readiness Assessment is a fixed two week engagement, priced at $2,500. When model choice is the question, we start from the job, not the leaderboard. We look at what the feature has to produce, how long its outputs run, and whether the problem even needs a language model, then match a model to that reality. The common result is a smaller, cheaper model doing the work just as well, because the quality gap was never in the model.
The most expensive model is not a strategy. Fit is.
]]>There is a paradox at the center of AI cost. Per-token prices have collapsed, and bills have gone up. A GPT-4-class model dropped from about $20 per million tokens to about $0.40 in four years, roughly a fifty-fold cut. And plenty of teams paying those lower prices are spending more than ever. Cheaper inference did not save money. It removed the brake that was keeping usage down.
A founder building an AI-native business intelligence platform captured the mindset that gets teams into trouble, and he was not wrong to hold it. “Now we have more computing power than we actually need,” he said. It sits idle, it is cheap, “so we can basically be ineffective on the computing power because who cares.” His mother, he pointed out, once had to schedule scarce university compute on punch cards. He can just spend it.
For a prototype, that instinct is correct. Shipping beats efficiency when compute is nearly free. But the same instinct scaled to production traffic is exactly how a bill balloons. Every inefficient call is trivial until you make it ten thousand times a day. The cost per call did not change. The number of calls did, and nobody was watching that number because each one felt like nothing.
The sharpest version of this hides inside agentic workflows. A single agent that reasons in steps, calls tools, and retries can consume ten to thirty times the tokens of one simple request per user intent. Do the arithmetic on a modest five-step agent: ten thousand runs a day at two cents a run is $365,000 a year, for one workflow. That number is invisible in a demo, where the agent runs a handful of times for an audience. It is very visible in production, where it runs continuously.
The teams that get surprised did not misprice a token. They mispriced how many tokens one user action would actually trigger once the agent was doing real work.
It helps to remember what an API call actually rents. A founder who runs an AI data-security company, and who watched the last wave of infrastructure up close, described the real substrate bluntly. The advantage sits with the few vendors that have “foundational models, energy to run them, a lot of GPUs, land, water to cool those huge data centers.” Inference feels like a line of code. It is GPUs drawing power in a cooled building somewhere, and at scale you are paying for that physical reality whether you priced it or not.
That framing matters because it changes the question. Cutting inference cost is not about finding a cheaper token. It is about doing less inference, or doing it more deliberately, because every call maps to real energy and real hardware downstream.
At scale, the bill is driven less by unit price and more by these:
Our AI Readiness Assessment is a fixed two week engagement, priced at $2,500. When inference cost is the worry, we trace one user action all the way through to the number of model calls it triggers, then project that against real production volume. Often the fix is not a cheaper model. It is removing calls that felt free at prototype scale and stopped being free at production scale.
The price of a token kept falling. Your bill kept rising. The gap between those two facts is the number worth measuring.
]]>Ask a team which systems their AI feature will touch and you usually get a short, confident list. Ship it, and the real list turns out to be longer, messier, and full of sources nobody mentioned because nobody thought of them as systems. The gap between the list you drew and the systems you actually touched is where the deployment gets stuck.
The reason is structural. In most enterprises the data an AI feature needs is siloed across systems that were never designed to talk to each other. There is no tidy warehouse waiting. There is a scatter of sources, each with its own owner, format, and refresh cadence, and your feature has to reconcile all of them. Mapping that scatter is not prep work. It is the work.
The CTO of a healthtech startup working on pharmacy pricing described this with unusual clarity, because his product cannot exist without it. When someone asks what a drug will cost, there is, as he put it, “not like a repository.” The answer is spread across the insurance company, the pharmacy benefit manager, and the pharmacy itself, plus the drug price, the deductible, and the member’s status, each living in a different place.
His AI’s real job is not a clever answer. It is reconciling those scattered, non-integrated sources into one. And the map keeps moving: “pharmacy drug prices go up and down. Formularies change monthly.” A deductible can flip which price applies. A whole parallel cash-pay ecosystem sits alongside the insurance one and has to be modeled too. He also had to ingest plan documents that arrive as a PDF, work historically done by “a human being reading it and typing it and putting in numbers,” and the feeds do not even carry every condition, so the system has to infer what is missing.
None of that is a model problem. It is a mapping problem. Before a single recommendation is possible, someone had to enumerate every system the feature touches, understand how each one lies or omits or shifts, and design the reconciliation. Skip the map and the model produces confident answers from an incomplete picture, which in his domain means a wrong price and a broken trust.
The dangerous systems are the ones that do not look like systems. The PDF someone emails monthly. The spreadsheet that holds an exception the database does not. The downstream tool that consumes your output and quietly assumes a format. The feed that omits a field you needed. Each is a system your AI feature touches, and each one you fail to map is a place production diverges from the demo.
A real map names all of them, including the ugly manual ones, and marks how each behaves over time. That map is boring to make and it is the single best predictor of whether a pilot survives contact with production.
In the AI Readiness Assessment ($2,500), building the map is the first deliverable, not a footnote. We trace every system the feature reads from and writes to, including the informal ones like the monthly PDF and the exception spreadsheet, and we mark which sources shift, omit, or contradict each other. You leave with the real surface area of the feature, not the optimistic short list.
The model can only be as complete as the map underneath it. Draw the whole map first, ugly systems included, and the pilot has a chance.
]]>Ask a team what their AI pilot costs and they point at the model bill. That number is real, but it is the one cost they were always going to see coming. The dangerous costs are the ones that never make it onto the spreadsheet, because you cannot budget for a line item you have not named.
A senior engineering manager at a large video streaming platform built an AI system to check media quality across thousands of titles, catching lip-sync problems and missing dialogue that no human could watch for at that volume. The interesting part was not the models. It was how the work was split: one region built the models, another built the data pipelines and inference orchestration, a third built the interface. Three teams, three time zones, one feature. He called the coordination “very hard.”
That coordination is a cost. It does not appear as an invoice, but it appears as calendar time, as handoffs, as the weeks where three groups are aligning instead of shipping. A pilot that looks like a two-person prototype becomes a three-team program the moment it has to be real, and almost nobody budgets for the overhead of running it as one.
The costs that hurt most are the ones you create early and pay for later. A co-founder and chief product officer at a customer-intelligence startup described what happens when a team skips the architecture conversation to move fast. Build features without planning two or three quarters ahead, and eventually “we have to refactor.” That means a quarter with no new features, where “everything becomes at a glacial pace.” She named it the biggest single cause of technical debt she sees.
That is a budget line nobody writes down: the quarter you spend rebuilding what you shipped too quickly. The pilot felt cheap because the expensive part was deferred, not avoided. Across the industry, real AI costs run two to four times initial estimates, and this is a large part of why. The estimate priced the build. It did not price the rebuild.
Then there is the scaling curve, which teams model as a flat line and reality delivers as a slope. One mid-market example makes it concrete: a contract-summary feature that cost about $180 a month at two hundred contracts cost $14,400 a month at eight thousand contracts, and it got there in six months. Nobody budgeted the eighty-fold jump because the pilot was priced at pilot volume. Success was the thing that broke the budget.
When we help a team find the money before it finds them, the same categories keep surfacing:
Our AI Readiness Assessment is a fixed two week engagement, priced at $2,500. Part of what you pay for is a complete cost picture, not just the visible one. We map the coordination the build actually requires, the scaling curve at real production volume, and the review effort the feature will need every month it runs. The point is to turn the unbudgeted costs into budgeted ones while they are still cheap to plan for.
The token bill was never the surprise. The surprises are the costs nobody wrote down. Write them down first.
]]>A model does not fail alone. It fails because the data it needed did not arrive, arrived late, arrived in the wrong shape, or arrived from an API that changed overnight. The pipeline is the part of the AI feature nobody demos and everybody depends on. When it has gaps, the model inherits every one of them, and the deployment stalls.
The cost of papering over those gaps is enormous. Enterprises spend on the order of 2.8 million dollars in extra middleware and custom APIs just to bridge older systems into new software. That spend exists because the pipelines were an afterthought, and an afterthought pipeline is a standing liability, not a solved problem.
A product manager at a data-pipeline company lives inside this problem, because her product exists to move data out of fragmented SaaS apps into a warehouse so it can serve AI and analytics. Her description of the core difficulty was the chaos of changing SaaS APIs. You build a connector, it works, and then an upstream vendor ships a change and your pipeline quietly stops delivering the data the model was counting on.
Her triage rule cut straight to what matters. If a reliability target is met, you can defer the small straggler fixes. But if something you built “leads to suboptimal customer benefit, you’ve built the ATM and money doesn’t come out, you fix that technical debt ASAP.” That is the mental model every AI team needs for its pipeline. The model is the ATM screen. The pipeline is whether money actually comes out. A beautiful interface over an empty feed is an ATM that will not dispense, and users learn fast to stop walking up to it.
The trap is that pipelines break silently. A connector that stops delivering does not throw an error the user sees. The model just gets stale or partial data and produces worse output, and the team blames the model, tunes the model, and never looks at the feed that quietly went dark.
Demos run on curated, static data. Production runs on live feeds from systems you do not control, through APIs that change on someone else’s schedule. Every gap between those two realities is a place the deployment can stall: the field that gets renamed upstream, the rate limit that trips at scale, the auth token that expires, the record that arrives in a format the pipeline was never taught to parse. None of these are model problems. All of them ground the model.
The teams that ship treat the pipeline as a first-class system with its own monitoring, its own reliability target, and its own owner. The teams that stall treat it as plumbing that either works or does not, and find out which in production.
The ownership point deserves its own line, because it is where most pipeline failures actually begin. When the connector belongs to no one, its silent break belongs to no one either. The model team assumes the data team is watching the feed. The data team assumes the connector was a one-time build that shipped and finished. Nobody is paged when an upstream API changes, so the stale data flows for days before anyone notices the output getting worse. Give every pipeline a named owner who gets alerted when a feed goes quiet, and half of these deployments stop stalling on their own.
In the AI Readiness Assessment ($2,500), we audit the feed before we trust the model. We map every API and data source the feature depends on, flag which ones change often or break silently, and set a reliability bar for the pipeline the same way you would for the model. A feature is only production-ready when the data underneath it is dependable, not just when the model is smart.
Tune the model all you want. If the ATM will not dispense, no one cares how good the screen looks.
]]>“Just plug in the model” is the most expensive four words in an AI pilot. It assumes the hard part is the model and the rest is a cable. In production, the reverse is true. The model is ready. What is missing is the layer that lets it actually talk to the system on the other end, and that layer almost never exists until someone builds it.
The evidence sits in the failure rate. Around 95 percent of AI pilots that stall do so on integration and trust, not on model quality. The models are capable. They just get handed to a system that has no clean way to receive them, and everyone acts surprised when the plug does not fit the socket.
A neuroscientist advising a biocomputing startup described the purest version of this problem. Her team runs code on living neurons. You would think the challenge is the model or the code, but it is neither. You write Python, she explained, and “everything is translated into” hardware behavior, an electrical spike or a dose of dopamine sent to the cells. The catch: “we still don’t have perfect formula on how to interact with neurons to get some meaningful interactions.”
The plug does not fit because the interface layer, the encoding and decoding between the code and the substrate, has not been invented. In her words, you actually need a new framework, “like a new programming language, totally new,” to move information in and out of the system reliably. Until that exists, plugging the code in produces motion, not meaning.
She added the second half of why plugging in fails. Computers are stable: same input, same output, every day. “But brain is plastic.” The same input can give a different output tomorrow. The downstream system is not deterministic, so even a perfect connection cannot assume the thing on the other end behaves the same way twice.
Swap neurons for a legacy enterprise system and the lesson holds exactly. The model is fine. The system it plugs into has no clean interface, holds data in shapes nobody documented, and behaves differently under real load than it did in the demo. “Just plug it in” assumes an interface and a determinism that production does not have.
Between a capable model and a real system there is always a middle layer that has to be designed: the translation of the model’s output into something the system can act on, the handling of data that arrives in the wrong shape, the fallback for when the downstream system does something unexpected. That middle is the actual product. Skipping it is not integration. It is a demo with optimism where the engineering should be.
The reason this trap catches smart teams is that the middle layer is invisible in the demo. In a demo, the inputs are clean and the downstream system is a slide, so the plug appears to fit and everyone concludes the hard work is done. Production removes both comforts at once. The inputs get messy and the downstream system gets real, and the middle layer that was never built is suddenly the only thing standing between a working feature and a stalled one. The teams that ship budget for that layer from the start. The teams that stall keep believing the demo, right up until the cable does not fit.
In the AI Readiness Assessment ($2,500), we look for the missing middle before anyone says the word plug. We identify whether the interface the model needs actually exists, where the target system behaves unpredictably, and what translation layer has to be built for the model to do real work. Naming that gap up front is the difference between a pilot that ships and one that ends the day the cable does not fit.
Nothing worth deploying just plugs in. Build the layer that makes the connection real, or accept that the demo is as far as it goes.
]]>There is a particular kind of pilot failure that leaves no crater. The feature ships, the launch email goes out, and then nothing happens. No outage, no complaint, just usage that flatlines near zero. The team assumes the model needs work. Usually the problem is that the AI was added as a destination instead of built into the tools people already use.
The context is expensive. Most large organizations already spend 60 to 80 percent of their IT budget just maintaining the systems their teams work in every day. Those systems are where the work lives. An AI feature that sits outside them is asking people to leave the place they spend their whole day, which is a request most of them will decline.
A product and UX leader who consults for enterprise software teams gave the cleanest version of this story I have heard. He watched a company decide it needed AI, move all its resourcing to integrate it, and ship. Then he looked at the analytics, using their product-usage tool, and saw the verdict in the data. “We’ll see maybe one or two prompts, and then that’s it. They’re not using AI anymore.”
The AI was integrated in the technical sense. It was there, it worked, it answered. But it did not solve the user’s actual problem inside the flow they already had, so people tried it once or twice and went back to what they knew. His broader pattern was the same across clients: teams “spent a ton of money and a ton of resources to launch something the users don’t really care about,” and users “go right to their own workflows they’re comfortable with.”
That last line is the whole lesson. The competition for an AI feature is not another AI feature. It is the workflow the user already trusts. If your integration asks them to abandon that workflow, the workflow wins, every time, and your analytics show one or two prompts and then silence.
People do not adopt tools on merit. They adopt what reduces friction inside the day they already have. An AI feature buried in a new tab starts every morning losing to the app that is already open. The way to win is not a better prompt box. It is to put the AI inside the tool the person already opens, at the moment they need it, so using it costs no new habit.
That is harder than building the model, which is precisely why pilots skip it. And skipping it is why the usage graph flatlines while the demo still looks great.
There is a measurement lesson buried in the story too. The company only knew the AI had failed because someone looked at real usage data and saw the drop after one or two prompts. Plenty of teams never look. They ship the feature, count the launch as a win, and move on, never noticing that adoption died in week one. If your only signal is that the feature exists and technically works, you will keep declaring victory over things nobody uses. Instrument the actual behavior, watch whether people come back after the first try, and let that number, not the demo, tell you whether the integration landed inside a workflow people trust.
In the AI Readiness Assessment ($2,500), we start from the tools your team already uses, not from a blank interface. We identify where people actually work, what they already trust, and how the AI can live inside that surface instead of beside it. We would rather ship a feature that appears in an app your team already opens than a brilliant one they have to remember to visit.
A feature people have to go find is a feature people forget. Build the AI into the tool that is already open, and adoption stops being a hope.
]]>A pilot can pass every accuracy test and still be dead on arrival. Not because the model is wrong, but because using it means abandoning the workflow the user already lives in. The feature becomes one more tab, one more login, one more place to check, and people quietly route around it. The model was fine. The workflow design never happened.
This is not a rare failure. Roughly 95 percent of AI pilots that stall do so on integration and trust rather than model quality, and workflow is where both of those get decided. A model users have to leave their tools to reach is a model they do not trust enough to bother with.
The founder of a legal-research AI company said the quiet part out loud when asked what came next for the product. His answer was not a better model. It was integration into the places lawyers already work. His phrasing: “you can also directly integrate it in the work where you do the work. So integrations with document management systems, integration with other tools so you end up being able to use the tool where you’re used to do that, as opposed to having to change the way that you do the work.”
That last clause is the entire discipline. “As opposed to having to change the way that you do the work.” The roadmap item was not a capability. It was workflow design, the unglamorous engineering of making the AI show up inside the document management system a lawyer already opens, instead of asking them to visit a new destination and rebuild a habit.
He understood the cost of getting this wrong, because he had watched the raw-model version of the failure. Lawyers who used a general model with no connection to their authoritative systems ended up citing cases that did not exist, and the model doubled down when questioned. The tool that lived nowhere, connected to nothing, produced work that could not be trusted. His product’s whole design answer was to embed the AI in the real workflow and constrain it to a real source of truth, so the output arrived where the work happened and could be clicked back to its origin.
Teams scope the model and forget that the model is useless until it fits a human sequence. Where does the output appear. What did the person do right before, and right after. Which tool do they trust, and does the AI live inside it or beside it. Each of those is a design decision, and skipping them does not make them disappear. It just means the user makes them for you, usually by ignoring the feature.
The best-integrated AI features are almost invisible. They arrive inside the tool the person already uses, at the step where they need it, requiring no new habit. That invisibility is expensive to build and it is exactly the work pilots cut first.
In the AI Readiness Assessment ($2,500), we map the human workflow before we map the model. We trace where the output has to land, which tool the user already trusts, and what step the feature sits inside, so the AI meets people where they work instead of asking them to come find it. Adoption is not an afterthought you bolt on later. It is a design input from the first sketch.
Build the model, and you have a demo. Build the workflow around it, and you have something people actually use.
]]>The usual sequence is backwards. A team builds a pilot, the demo works, everyone gets excited, and only then does someone ask how it connects to the systems the company runs on. By that point the model has been designed as if it lives alone, and the integration has to be reverse-engineered into a thing that was never built to accept it.
The root cause is almost always the same. The data the AI needs is siloed across systems that were never designed to talk to each other. If you discover that after the pilot, you are not integrating, you are excavating. The right time to find those silos is before a single prompt is written.
The most useful planning move is not deciding what to connect. It is deciding what to leave alone. The CEO of a brain-health AI startup made that call out loud. He knew that the richest data lived in enterprise health records, the kind of deep integration that eats years. His decision was to not start there. As he put it, an Epic-type infrastructure “where you have your health care records, we’re not starting with that.”
Instead he began with inputs the product could own directly, wearables and diaries, so the pilot could prove its value without taking on the heaviest integration first. That is planning. He mapped the systems the feature would eventually touch, saw which one would sink the timeline, and deliberately sequenced it for later. The alternative, starting with the deepest integration because it has the best data, is how pilots vanish into a two-year records project and never surface.
He also understood the fragmentation he was routing around. His own description of the problem was a patient filling out the same form “for the millionth time,” then talking to a provider who “haven’t looked at my records yet,” who then has to talk to someone else, and it “gets lost.” He knew that swamp intimately, which is exactly why he chose not to wade into it on day one.
Choosing not to integrate a system in the pilot is not the same as ignoring it. The founder still mapped where the feature had to go eventually, and framed the current version as one piece of a broader ecosystem that would later represent the user to a care provider. The plan named every system, then ordered them by cost and risk. The pilot took the cheapest, highest-signal integration first. The expensive one got a place in the sequence, not a place in the surprise pile.
That is the difference between a plan and a hope. A plan knows the whole map and picks the order. A hope builds the fun part and prays the connections work out.
There is a second benefit to planning integration early, and it is political as much as technical. When you name the two-year records integration up front and schedule it for later, the executive who funded the pilot is not blindsided in month four by a timeline they never agreed to. The hard integration stops being a surprise that reads like failure and becomes a milestone everyone signed off on. Teams that skip this step do not just take on technical risk. They set themselves up to look like they missed something, when in fact the integration was always going to be long. Sequencing it in the open protects both the timeline and the credibility of the people running the pilot.
In the AI Readiness Assessment ($2,500), integration planning comes before the build, not after. We map every system the feature will eventually touch, mark which ones hold data that is siloed and hard to reach, and help sequence the pilot so it proves value on the cheapest integration first. The expensive, multi-year connections get named and scheduled instead of discovered in a panic three months in.
Plan the integration before the pilot and you get to choose your battles. Plan it after and the systems choose for you.
]]>There is a comforting story where the enterprise is a clean slate waiting for a better tool. The reality is closer to a body rejecting a transplant. The old system does not want the new thing, and it has several ways to say no.
Start with the money. In most large organizations, keeping legacy systems running consumes somewhere between 60 and 80 percent of the IT budget. That is the budget already spoken for before anyone funds an AI integration. The resistance is fiscal before it is anything else. There is barely room to keep the lights on, let alone rewire the building.
Sometimes the legacy system is not software at all. An operator brought in to turn around a 60-year-old family-run billboard company walked into a human version of a legacy stack. The business had been family operated for around 55 years, promoting “the cousin, the uncle” instead of someone capable. He arrived as, in his phrase, “young blood,” and hit the response every modernizer knows: “we’ve been doing it this way.”
The most telling detail was the data. He was there to fix the business, and they would not give him visibility into the finances, the “most delicate part.” The system protected its own opacity. You cannot integrate what you are not allowed to see, and enterprises are full of subsystems that guard their data precisely because someone’s authority depends on it staying hidden. That is resistance you will not find in an architecture diagram.
The software version is just as stubborn. A product and UX leader who consults for enterprise software teams described the reflex directly. When you launch new software into an enterprise, the initial reaction “is gonna be negative.” Users “go right to their own workflows they’re comfortable with.” They have muscle memory, and your integration is asking them to override it.
He has watched this sink expensive launches. Teams “spent a ton of money and a ton of resources to launch something the users don’t really care about,” and then watched adoption flatline because the new feature asked people to leave the workflow they trusted. The system resisted not through code but through habit, which is harder to patch.
He also named a structural reason integrations calcify. In one client, a single customer paying about half the revenue could call the head of development and demand a feature, “then everybody else gets a different build and now you’re maintaining multiple builds and it becomes a nightmare.” The enterprise ends up with forked systems, each resistant to a common integration, because the past made promises the present has to keep.
None of this means integration is impossible. It means resistance is data. When a system guards its data, forks its builds, or sends users fleeing back to the old workflow, it is telling you where the real constraints live. Teams that treat that resistance as an obstacle to bulldoze fail. Teams that treat it as a map of what the organization actually values tend to find a path.
In the AI Readiness Assessment ($2,500), we look for the resistance on purpose. We ask which systems will not give up their data easily, which users have a workflow they will defend, and where the org has forked its own platform in ways that block a clean integration. Naming those before you build turns a mid-project surprise into a design constraint you planned around.
The old system is not passive. Respect that it will push back, and design for the push, not against it.
]]>