- 20
- July
"The Money Is in Implementation, Not the Model: Lessons from a $1.5 Billion AI Bet" — the short answer is The largest recent investment in enterprise AI did not go into building a new model — it went into a company whose job is getting AI actually deployed into how organisations work. On 15 July 2026, Anthropic, Blackstone, Hellman & Friedman and Goldman Sachs launched Ode with Anthropic, a joint venture valued at roughly $1.5 billion and dedicated entirely to enterprise AI implementation. This article explains what that deal tells executives weighing an investment in Claude or any other AI platform, and why the lesson is the same one ERP projects have been teaching for decades.
In one line: The market has just put a billion dollars behind the view that the hard, valuable work in enterprise AI is wiring it into real business processes, not deciding which model to use.
What Actually Happened
On 15 July 2026, Anthropic, Blackstone and Hellman & Friedman announced the launch of a new company called Ode with Anthropic — a joint venture valued at roughly $1.5 billion, with Goldman Sachs joining as a fourth anchor investor and several additional institutional investors participating. What this company will do is not build a new language model, not design chips, and not operate data centres. Its business is helping organisations put artificial intelligence into their actual working processes.
The venture started by acquiring Fractional AI, an applied-AI services firm, giving it a team of roughly 100 engineers from day one. Chris Taylor serves as chief executive and Eddie Siegel as chief technologist; both co-founded Fractional AI. The operating principle is described as "Claude-first" — Anthropic technology is used wherever it fits, while products from other providers remain available when a client's requirements call for them.
| Item | What was announced |
|---|---|
| Entity | Ode with Anthropic (launched 15 July 2026) |
| Deal size | Approximately $1.5 billion |
| Anchor investors | Anthropic, Blackstone, Hellman & Friedman and Goldman Sachs |
| Starting point | Acquisition of applied-AI services firm Fractional AI |
| Headcount | Around 100 engineers working as forward-deployed engineers embedded with clients |
| Business model | Enterprise AI services, Claude-first, with other vendors' tools used where the client requires them |
A note before reading on: this article reads the deal as a market signal, not as an advertisement for anyone's services. Grand Linux Solution Co., Ltd. has no business relationship with Ode, Blackstone or Goldman Sachs, and is not an Anthropic-appointed reseller. What interests us is the structural conclusion the deal reflects — one that matches what people who deliver enterprise systems have known for a long time.
The Most Important Sentence in the Story
Eddie Siegel, Ode's chief technologist, put it plainly in interviews: model selection matters, but it is not where the majority of the effort goes. He compared choosing a model to choosing a programming language when you set out to build a piece of software.
The analogy lands, because nobody believes a software project succeeds simply because the right language was picked. Choosing the language is a decision measured in hours on a project measured in months. Everything else — understanding the problem, designing the data, integrating with existing systems, testing, fixing what breaks, training people, and supporting the result after handover — is where the work actually lives.
When a billion dollars of institutional capital is directed at a company that does only the "everything else" part, the market is stating clearly that the everything-else part is the scarce and expensive one.
| Task | What it involves | Knowledge required | Share of effort |
|---|---|---|---|
| Selecting a model or provider | Comparing capability, price and data terms | The vendor landscape | Low — decided once, revisited periodically |
| Understanding the real process | Interviewing users, documenting how work is actually done, finding the undocumented exceptions | The client's business | Very high |
| Preparing and connecting data | Extracting from legacy systems, cleaning, defining access rights | Legacy systems, databases, security | High |
| Integrating with systems in use | APIs, workflow changes, deciding where a human approves | System architecture | High |
| Testing and measurement | Defining what "correct" means, measuring before and after, reviewing failures | Business acceptance criteria | High |
| Training and behaviour change | Teaching users, rewriting procedures, adjusting team metrics | People and organisational culture | High, and routinely underestimated |
| Ongoing support | Chasing wrong outputs, adapting when the process changes | All of the above | Continuous — never finished |
The table deliberately avoids percentages, because the true split varies by organisation. The shape, however, is always the same: one task sits at the top of the sales deck, and six others go unmentioned until the project is under way.
This Lesson Is Not New — ERP Learned It Thirty Years Ago
For anyone who has delivered an enterprise resource planning project, none of the above is news. Two organisations buy the same software, the same release, at a similar price. One is running productively within a year; the other is back in spreadsheets within six months. The difference was never the software. We wrote about this at length in what to do when your organisation starts wanting an ERP, and about selection criteria in how to choose an ERP system.
What is striking today is how closely the failure modes of enterprise AI projects map onto the classic failure modes of ERP projects — almost one for one.
| Classic ERP failure mode | The same thing in an AI project | Shared root cause |
|---|---|---|
| Buy the system first, work out the use later | Buy organisation-wide AI seats, then go hunting for use cases | Starting from the tool instead of the problem |
| Dirty master data makes every report wrong | Incomplete or contradictory inputs make every answer untrustworthy | No single source of truth |
| Users refuse to change and go back to their old files | Staff try it for two weeks and stop because it is slower than the old way | Not designed around the work people actually do |
| No serious UAT, so problems surface at go-live | Only the flattering demo cases are tested; edge cases never are | "Pass" was never defined |
| Executives treat it as an IT project, not a business one | Handed to IT alone while process owners stay out of the room | No business-side owner |
| Knowledge sits with two people; when they leave, it ends | Whoever wrote the prompts and workflows resigns and nobody can maintain them | No handover documentation — see knowledge walking out the door |
| Locked into a vendor with no way out | Business logic embedded inside one provider's proprietary tooling | Process never separated from tool — see vendor lock-in |
Data caution: AI projects differ from ordinary ERP projects in one important way — they usually involve sending data outside the organisation for processing. Before a project starts you must be able to say which data sets may leave, which may not, who approves the decision, and how access is logged. This has to be settled at the beginning rather than shortly before go-live, because getting it wrong early means rebuilding the work rather than adjusting it.
Who Is a Forward-Deployed Engineer, and Why Are They Scarce?
The phrase that recurs throughout coverage of this deal is "forward-deployed engineer" — an engineer who does not sit writing code at their own company, but works inside the client, sees the real process, talks to real users, and builds something that survives real conditions. Reporting on the launch notes that demand for these teams far outstrips supply, and Siegel described the profile as people who can handle a genuinely hard technical problem while also owning a piece of work end to end.
In the world of enterprise systems this person is not a new invention either. It is the consultant sitting on the floor during month-end close; the one who understands why purchase orders in one department need three signatures while another department needs two; the one who knows which format a tax document must take to survive an audit. That knowledge is not in any product manual, and no model knows it until somebody teaches it.
Good news for organisations in Thailand: if the scarcest asset is understanding of the real process, local organisations are not at a disadvantage at all — because the process that must be understood is the Thai one. Tax documentation, procurement regulations and internal approval chains are local knowledge. That is an advantage for in-country teams, not a constraint.
Questions to Ask a Vendor Before You Sign
If the value sits in the deployment, the questions used to screen vendors have to change as well. Asking "which model do you use?" tells you far less than it appears to. The questions below apply equally to AI projects and to enterprise system projects.
| Question | What it measures | Answer to be wary of |
|---|---|---|
| Who will actually sit with our team, and how many days per week? | Whether there are delivery people or only sales people | "We'll assign a team later" |
| How are the acceptance (UAT) criteria written into the contract? | Whether success is defined in writing | "We'll agree that closer to delivery" |
| What is the cutover plan, and what is the rollback plan? | Readiness for the day something breaks | There is no rollback plan |
| Where does our data go, how long is it kept, and who can access it? | Data risk and governance | A vague assurance that "it's secure" |
| If we stop using the service, how do we take our process and data with us? | Degree of vendor lock-in | No clearly documented export format |
| Which metrics will measure the return, and has the baseline been captured? | Seriousness about outcomes — see measuring the ROI of AI investment | Savings figures with no stated source |
| Who supports this after handover, and what documents are handed over? | Sustainability once the project ends | "We'll support as appropriate" |
What This Has to Do With Saeree ERP
To be direct: Saeree ERP is not in the same business as Ode and has no connection to this deal. What we do is enterprise resource planning software and the implementation work that puts it into use in organisations in Thailand. The Saeree ERP AI assistant is still in development and training — it is not a feature we can deliver today, and we would rather say so than imply otherwise.
The conclusion behind the deal, however, is one we can confirm from our own delivery experience: the quality of implementation outweighs the choice of technology. That is why Grand Linux Solution Co., Ltd. works within the ISO/IEC 29110 framework, which requires documented requirements, a test plan, user acceptance testing and a written cutover plan rather than verbal agreement.
Equally important is understanding process specifics in Thailand — tax document formats, purchase order flows, and government procurement rules. Those details decide whether a system is usable in practice. Organisations beginning to look at this may want to start with ERP for small and medium businesses, the broader picture in what an ERP system actually is, and the direction of travel in how AI is making ERP smarter in 2026.
A clear boundary: the ERP system is the organisation's source of truth; AI is an assistant working on top of that truth. The order cannot be reversed. In an organisation whose master data is still scattered across departmental files, adding AI produces answers faster without making them any more correct.
Conclusion
The roughly $1.5 billion Ode with Anthropic deal is not significant because of the amount. It is significant because that money chose a services business rather than a technology one. When several institutional investors of this calibre make the same call at the same time, the implicit conclusion is that model capability is no longer the bottleneck — the bottleneck is the people and processes that carry that capability into daily work.
For organisations setting an AI budget for 2026, the practical translation is direct: spend less time choosing a model, and more on three things — the cleanliness of your source data, the clarity of your acceptance criteria, and the quality of the team that will sit with your staff while the work is built. Those three decide how the project ends. They are also exactly the three that have decided the fate of ERP projects all along.
"Good software plus poor implementation equals a failed project. ERP proved that over thirty years — and someone has now put a billion dollars behind the same conclusion for AI."
- The Saeree ERP team
References
- TechCrunch — Anthropic, Blackstone bet the next trillion-dollar AI business is implementation, not just models (15 July 2026)
- Business Wire — Anthropic, Blackstone, and Hellman & Friedman Introduce Ode with Anthropic, an Enterprise AI Services Firm (official announcement)
- AIwire — launch details for Ode with Anthropic
Information verified on 20 July 2026.
Looking for an ERP system for your organisation?
Talk to a team that does the implementation, not just the sale. Grand Linux Solution Co., Ltd. works within the ISO/IEC 29110 framework, with documented test plans, user acceptance criteria and cutover planning. Free consultation, no obligation.
Request a Free DemoTel 02-347-7730 | sale@grandlinux.com
