Every founder we talk to this month can rattle off four or five frontier model names without blinking. Fable 5, GPT-5.6 Sol, Kimi K3, Grok 4.5. Three years ago knowing that list was an edge. Today it is table stakes, because every one of those labs is racing to put the same raw capability in front of anyone with a credit card. The model you pick barely moves the needle this quarter. Who actually wires it into your business does.
Intelligence stopped being the moat
We have covered model routing and testing before, but it is worth stating plainly: the foundational capability behind every one of these releases is converging. Vendors compete on price and context window more than raw reasoning now, and pricing pages change monthly, not yearly. Check Anthropic's current pricing or OpenAI's pricing page against what they showed six months ago and the pattern is clear: capability keeps getting cheaper and more available, not more exclusive. xAI is running the same playbook. This week alone our research desk logged a frontier model made free inside a mainstream coding tool, a challenger model matching an expensive one on a like-for-like dashboard build, and a third model wired straight into a coding agent through open source glue that a hobbyist put together in a weekend. None of that required a research lab. It required someone willing to connect the pieces.
That is the whole shift. If every company can buy the same intelligence, the advantage moves to whoever decides where that intelligence actually belongs inside a specific business, and who builds the bridge to get it there. That is not a model question. It is a deployment question.
The job Palantir built a business on
The term forward deployed engineer got popularized by Palantir, and it is worth understanding why it worked, because the underlying idea is more useful to a 40-person company than to the enterprise it was built for. Palantir's engineers do not sit in an office tuning a model. They go on site, sometimes for weeks, and they sit with the people actually doing the work: the analyst, the ops lead, the person who handles the exception when a process breaks. They are not there to sell software. They are there to learn a business well enough to rebuild a piece of it. See how Palantir positions this on its own product page and the language is all deployment and workflow, not model benchmarks.
That distinction, consulting for software instead of software for everyone, is the whole reason the role exists. A generic platform assumes every company runs sales, fulfillment, or support the same way. They do not. One company runs a ten-step sales process on a lean stack; another runs thirty steps across five tools that never got fully integrated. The difference is not cosmetic. It changes where automation should sit and where a human still needs to make the call.
Three stages, and only one of them is technical
Stage one: map the business reality
Before anyone touches a model, someone has to document how work actually happens today, not how the org chart says it happens. That means sitting with the person who runs the workflow, watching where exceptions get handled off the books, and getting direct access to the systems of record: the CRM, the ERP, the shared inbox that quietly runs half the business. This is the slowest part and the part most software vendors skip entirely, because it does not scale the way a demo does.
Stage two: decide where intelligence belongs
Not every step needs a model. Some of the early AI pilots we have watched operators run failed because everything got routed through an LLM, including steps that were already deterministic and cheap to run with a simple rule. The actual judgment call is narrower than people expect: which two or three steps in a ten-step process are genuinely ambiguous enough to need a model's judgment, and which seven are better solved with an if-then rule or a direct API call. Getting that split wrong is how a pilot turns into a demo that never survives contact with real volume.
Stage three: deploy, then maintain
The last stage is wiring the decision into something that runs without a human babysitting it. That is the difference between a chatbot someone talks to occasionally and an operations layer that acts: reading a lead, checking it against a rule, escalating the ambiguous cases to a person, and closing the loop on the rest. It only works when the system has real access to the tools it needs to act, not just an automation triggered from a spreadsheet.
Why this matters more at 40 people than at 4,000
Enterprise companies can afford a team on site for a year. A 40-person real estate group cannot, and does not need to. What that company needs is the same three-stage discipline compressed into weeks instead of quarters, aimed at the two or three processes actually leaking time and money: the lead that sits for hours before anyone calls it back, the admin task that eats hours every week and never shows up on a P&L line, the follow-up that only happens when someone remembers.
| Enterprise FDE engagement | What a 10-50 person company actually needs |
|---|---|
| Team on site for months | A focused build live in days to weeks |
| Custom ontology and data platform | Direct connections into the tools already in use |
| Internal engineering owns the code after handoff | Client owns 100 percent of the code and files from day one |
| Dedicated staff monitors the system | Agents that run 24 hours a day, 7 days a week, without a shift schedule |
What we are building this quarter
We run a 40-person real estate group ourselves, so this is not theoretical for us. The processes we are prioritizing this quarter are the ones with the clearest exception handling problem: speed to lead, where a five-minute response window is the difference between a live conversation and a cold one, and the recurring admin tasks that quietly consume ten or more hours a week per person without ever getting fixed because nobody owns the fix. Both map directly to a system built on judgment plus deterministic logic, not a chatbot bolted onto the front end.
If you run a company in the same size range, the exercise is the same regardless of which model you eventually pick. Walk your own sales or fulfillment process end to end. Write down every step where a human currently makes a judgment call versus every step that is already a fixed rule nobody has automated yet. That list is the actual spec for what to build. Our automation team builds exactly that kind of system, and if you want to see what it looks like once it is running, our case studies cover real builds across a few different operator businesses.
The assessment is the FDE contract, compressed
Palantir's engineers earn their keep in that first phase: understanding the business before touching a line of code. We built our AI assessment the same way, a fixed-scope engagement for 999 euros that maps your actual workflow, flags where judgment is genuinely needed versus where a rule will do, and hands you a build plan. The fee gets credited against the build if you move forward, so the diagnostic is not a sunk cost. It is the first stage of the same three-stage process Palantir runs at enterprise scale, just priced and timed for a company our size.
None of this requires betting on a single model vendor. It requires someone willing to sit with your actual process the way an on-site engineer would, decide where AI judgment belongs, and build the connective tissue between that decision and the tools you already run on. See the full range of what we build across our products, or if you want a sense of the leaks this kind of mapping usually finds first, run our revenue leak heatmap before your first call. We write about this kind of build regularly on the blog if you want the operator's-eye view before you commit to anything.