Ontollo Blog

The cheapest tokens are the ones you don't have to use

Tiffany To — Tue, 08 Sep 2026 19:45:10 GMT

What I love about AI transformation right now is that everyone is sharing lessons learned - not just the wins, and lately it’s all about the eye popping bills!

As every company across nearly every industry seeks to empower their teams, guardrails are hard to set on tokens as every user aims to push the edges of what’s possible, often with the latest, most expensive models.

In parallel, the sovereignty conversation running through enterprise tech right now is bringing up many important AI architecture stack decisions, but isout of reach for most of the operators I talk to. They will never own a GPU cluster. Control has to come from somewhere else.

In this post, I’ll cover:

Why the recent AI failures are failures of economics, not capability
Why the standard answer, own your own infrastructure, doesn’t work for most organizations
Where control actually sits and the ownership question that separates real control from a change of landlord

I want to start with the failures, because they are the least ideological evidence available.

The projects that worked and still failed

In August, Canva told investors it expected roughly 20% revenue growth for 2026 rather than the 30% it had planned on, according to Fortune, after its AI features turned out to cost far more to run than the company had modeled. Users loved the features. That was the problem.

Uber ran through its entire 2026 AI coding budget in about four months after rolling Claude Code out to thousands of engineers, and CTO Praveen Neppalli Naga has since said the company is "coming to the end of the so-called tokenmaxxing era" (Fortune, August 2026). Adoption was the success metric. Adoption broke the budget.

Neither of those is a failed AI project. The technology worked as designed in both cases. What nobody owned was the economics underneath it, and that turns out to be a separate thing you have to own on purpose. The FinOps Foundation's State of FinOps 2026 puts scale on how new this is: 98% of practitioners now manage AI spend, up from 31% two years ago. A discipline built to govern reserved cloud instances is now forecasting token consumption.

Software companies hit this first because they shipped AI to millions of users first. Physical operations in industries like energy, construction, and infrastructure are not exempt, they are just behind but not by far

Sovereignty, as currently written, is a big-company product

David Vellante and Amit Eyal Govrin laid out the sharpest version of the argument I have read in SiliconANGLE's Breaking Analysis this month. Vendors want progress measured in tokens and model calls, which are their revenue metrics rather than anyone's business outcome. The alternative they describe is control: over routing, over policy, over the ability to change providers without rebuilding the application. Their line for it is "Cheap is a price. Sovereign is a position." I think that is exactly right.

Now look at who the examples are: Uber, Canva, Microsoft, and the Swiss federal research system, which trained its own open model on a national supercomputer. Every one of them could write a check for GPUs and build out their own infrastructure stack.

The reality for most operators is that they cannot afford to do that, and they shouldn’t try. For them, the practical version of the SiliconANGLE argument is not "own your infrastructure." It is a harder question: If the floor of the stack is going to be rented no matter what, which layer is worth owning outright?

The routing decision is a knowledge problem

Vellante and Govrin get close to the answer and then move past it. In one paragraph on context management, they sketch an agent that queries a knowledge graph for just-in-time state instead of re-deriving the situation from scratch, and note that it would produce more deterministic results on a fraction of the tokens. Then the piece moves on to gateways and routing policy.

That paragraph is the whole thing, for an operator.

Everyone is converging on routing as the control point, and Stripe's $7.5 billion for OpenRouter this month says where the industry thinks the leverage is. But a router only decides which model gets the work. It has no opinion about what the work is. Ask it whether a question about a delayed switchgear delivery is routine or load-bearing and it cannot know, so the safe default is to follow set algorithms.

That is not a pricing failure. It is an ignorance tax, paid per request, forever.

The reason I’m not neutral here is because I have built one of these before. My platform teams at Atlassian began our work on Teamwork Graph, the context layer that powers Atlassian's AI more than 5 years before GenAI became hot. Teamwork Graph was meant to build a complete picture of the SDLC for an organization from across many tools and systems of record so analytics on where the bottlenecks were could be clearer to diagnose and address. When GenAI came along, the Teamwork Graph not only made every query response get better, but with fewer tokens, because an agent that knows how a piece of work connects to everything around it does not have to re-derive the company on every prompt. If you’re curious, I wrote about what that taught me when we started Ontollo in my last blog.

So here is the claim I would defend. An ontology, a plain definition of what the things in a business are and how they relate, is usually described as setting the ceiling on what AI can eventually do for a company. But it also sets the floor on what that AI costs to run.

Owning the decision is not the same as owning the layer

Nobody has pushed the own-your-alpha argument harder than Alex Karp, CEO of Palantir. As Vellante and Govrin summarize his position, a company should control its compute, its models and the value created from its own proprietary knowledge, and consumption pricing on frontier models works as a tax on the enterprise. Palantir has built a lot of what that requires: orchestration, governance, deployment, and an ontology. That last item is not a simple technology feature - it requires understanding of the business, workflows and some amount of FDE integration and data hygiene that cannot be avoided. Investment in this, though, creates value for clients exactly where the leverage sits.

Vellante and Govrin's objection is not to the advice. Rather, it’s to the route. Karp's solution runs open-weight models on GPUs in a data center the customer controls, underneath an operating layer that is Palantir's and is not open. Their read is that this swaps one dependency for a harder one: the meter goes away, and what replaces it is a layer that is considerably more expensive to leave than a contract is. They argue the sovereign version of the same advice would run on something inspectable and forkable, so that the crown jewels are actually held rather than deposited.

That objection is worth taking seriously by anyone selling into this, and I include Ontollo in that. A model of how a business's work connects is only an asset if the business can take it somewhere else. In my last post, I included a question that every organization should ask their provider – and this article really stresses the importance of it: If you decide to change platforms in three years, does the model of how your business runs and own work connects come with it?

What should not be rented

Underneath our customers' operations, Ontollo maintains a deterministic layer that tracks what is true in the business rather than a model guessing at it. AI reasons on top of it, inside boundaries the customer sets, and every output carries a trail showing how it got there. I used to call the trail a compliance feature, but it really isn’t. It is what lets a company argue about its own AI spend from a position of fact.

None of this argues against renting frontier capability. For most operators, that is the only reasonable option.

Instead, I’d argue that there are three things that should not be rented alongside it.

The model of how your company's own work connects.
The policy that decides which work is worth an expensive answer. That is a business judgment about what matters operationally, and it is strange to let it be made by default.
The record of how an answer was reached. Without it, nobody can audit what the AI actually did, which means nobody can tell an inflated bill from a necessary one.

The firms that come out of the next two years ahead will not be the ones who negotiated the best rate per million tokens. They will be the ones who could tell, in advance, which questions were worth the expensive answer.

Noah and I are building that layer for operators who are never going to own a data center, and we think it belongs to the operator. If you are in the middle of one of these vendor conversations right now and interested to see how Ontollo could make an impact, we’d be happy to give you a completely customized demo tailored to your exact business case.

Your system of record can't tell you when it's wrong

Tiffany To — Fri, 21 Aug 2026 00:59:08 GMT

I left Atlassian this year to join Noah Wasmer as co-founder and CEO of Ontollo. We had built together before, infrastructure systems for F500 at VMware and a project management platform to serve 300K customers at Atlassian. The mission he was already working on was one I'd spent the last six years preparing for without knowing it.

The work I'm proudest of leading at Atlassian is the Teamwork Graph, the context layer underneath Atlassian’s AI offering that lets it reason about how work is connected across functions and different systems of record. Building it with our teams and customers taught me something I haven't been able to stop seeing since. Most large organizations don't have a data problem. They have a system of record compatibility problem, and siloed workflows have relied on human glue for decades until agents came to crash the party.

Illustration of the Atlassian Teamwork Graph (Source)

Meanwhile, Noah was seeing this same challenge but in very different industries outside the Atlassian ecosystem where the work product was physical not digital - energy grids, agriculture, and healthcare,. The AI gains of the last few years have landed almost entirely with people who work in front of screens. The people running sites, plants, farms and fleets are still waiting, and not because AI can't help them, but because AI needs a current picture of what's actually happening, and for most physical businesses that picture doesn't exist in a way agents can access.

I didn't initially have the construction industry on my radar, but that immediately changed when I attended the BuiltWorlds Construction Tech Conference in Chicago last month. I went mostly to learn, and spent two days listening to people describe a problem I had spent six years inside of. Different vocabulary, same shape. Everyone had the data. Almost nobody could act on it.

I'm new to this industry. The operators I talk to every week know things about delivering a project that I may not fully understand for years. But I have built the layer operators across so many industries are now racing to architect and build, and there's a step in the sequence that I keep seeing skipped.

Where systems of record fall short

Construction's systems of record are a real achievement, and I want to be precise about what they're good at, because the argument I'm making isn't that they failed.

A record answers one question extremely well: what happened. Who submitted the RFI, when it was approved, which drawing is current, who signed off. On a project generating tens of thousands of documents, answering that reliably is the difference between a defensible position and a claim you lose. That capability was hard to build and it took a long time to adopt.

It's also, structurally, a description of the past.

The blind spot

Here's the thing about a system of record that took me a while to appreciate at Atlassian, and that I think matters more in construction than it did in software.

A record is only as current as the last person who updated it. And it has no way of knowing when that was long enough ago to matter.

Jira never told us a ticket's status was stale. It told us the status. If a team had stopped updating a board three weeks earlier, that board looked exactly as confident on day twenty-one as it had on day one. The data was clean, the system was working as designed, and the picture was wrong. Nothing in the architecture could flag it, because a record stores what it was told, not whether what it was told is still true.

Construction runs a version of this problem with much higher stakes. The schedule says one thing. The field is doing another. The gap between them isn't a data quality issue, it's a timing issue, and it hides in the open quietly.

The Navigant Construction Forum studied 1,362 projects containing more than a million RFIs, and found that more than one in five never received an answer at all. That research is from 2013 and the tooling has improved a great deal since. But look at what the finding describes, because the shape of it hasn't changed.

Every one of those RFIs sat in a system that knew it existed. It had a date, a recipient, a status. The record was complete and correct by its own standards. What it could not do was tell anyone that one of those open items was holding up a crew, or that its own picture of the project had drifted from what was happening on site.

The missing middle layer

This is where the sequence matters, and where I think the industry is trying to skip a step.

Everyone is now attaching agents to systems of record. That produces something genuinely useful. An agent can search, summarize and draft against what the record contains, and that saves real hours. At Atlassian, that class of automation was the first thing that worked for us - removing the toil from many tasks.

But an agent acting on a record inherits the record's blind spot. It will act confidently on information that stopped being true two weeks ago, and it won't hesitate, because nothing in its inputs signals doubt. Automating action on a stale picture doesn't fix the picture. It gets you to the wrong place faster.

What has to come first is a continuously current model of the work. At Ontollo, we call it a system of reality: a layer that maintains a live picture of what's actually happening, understands how the pieces relate to each other, and, critically, knows where its own picture has gone stale.

Ontollo System of Reality, showing signals, business drivers ,and knowledge being transformed into action

That last part is the piece I'd underline. A system of reality can tell you that the schedule and the field haven't agreed in over a week, that a submittal status hasn't been touched since the material shipped, that this part of the project is currently running on assumptions. A system of record structurally cannot do this. It has no representation of its own currency.

A system of record tells you what happened.
A system of reality tells you what's true right now, and where it isn't sure.
A system of execution acts on that.

The order isn't a preference. Execution without reality is confident action on outdated facts, which on a jobsite is more expensive than no action at all.

Why this doesn't arrive as a feature

The reasonable counterargument is that the platforms are building this now. Agent builders, custom skills, teach-the-AI-your-process. Give it eighteen months.

Having done it once, I don't think this is mainly a technical problem.

A live model of the work requires deciding what the objects are, which relationships are load-bearing, and what a change in one implies for another. At Atlassian those decisions took us years, and they were specific to how our company operated. Nobody outside could have made them for us, and they wouldn't have transferred cleanly to another company.

The same is true here, only more so. A self-perform contractor and a construction manager at risk don't have the same model of how their work connects. Neither of them has the one that ships in the box.

It also requires capture where the work happens. A picture of reality that depends on someone walking back to the trailer to type is stale before it's entered, which is why voice and scanning on mobile aren't conveniences in this design. They're load-bearing.

So the question isn't whether this model gets built. It's who builds it and who owns it afterward. The firms that get real value from AI on their projects won't be the ones running the most agents. They'll be the ones with a current, connected picture of their own work, owned by them.

Three questions worth asking

If you're evaluating AI products right now, the feature list won't separate the options. Everyone has agents, pre-built workflows and orchestration. These three questions will tell you more than any demo:

Can it tell me when its own information is out of date?
Can it tell me what a delay on one thing means for the rest of the project, or only that the delay happened?
If we move platforms in three years, does the model of how our work connects come with us?

I'd push hardest on the first one, because it's the one nobody expects and the answers are revealing. A system that can't tell you where it's uncertain is asking you to trust all of it equally, and no operator I've met trusts their systems that evenly.

None of this argues against systems of record. They're exactly the right place for records. It argues that a record was never designed to be a live picture of the work, and that treating it as one, then automating on top of it, is how a firm ends up with an immaculate account of a project it can't steer.

That live picture is what we're building at Ontollo, and we think it belongs to the builder.

If any of this resonates or there's something you'd challenge, I'd love to hear your thoughts.

Introducing Ontollo: A note from our co-founders

Tiffany To — Tue, 11 Aug 2026 18:37:49 GMT

Noah and I are excited to introduce you to Ontollo and wanted to share the story as to how we got here.

Noah and I have spent our combined 40-year careers doing one thing over and over: building new market categories from scratch, and leading the teams behind some of the most successful infrastructure and product companies out there, VMware, Atlassian, Apple. We've also each built successful startups from the ground up. That combination, knowing what it takes to build a category and knowing what it takes to build a company, is exactly what led us to start Ontollo.

We talked to dozens of customers who were struggling to make AI actually work inside their companies, particularly operations companies. That's what convinced us of the mission: unleashing the potential of AI for the mission critical needs of operators in construction, energy, infrastructure, and healthcare. Physical AI is not just about robots.

Lost in the physical AI conversation are the existing machines, systems and sensors that power today's companies. Imagine making sense of all your physical assets to achieve business, strategic and operational efficiencies -- that's the mission of Ontollo.

AI misallocating equipment or personnel, failing to validate a safety compliance standard, or hallucinating a project's financials is disastrous. These are the businesses that build, run, and grow the world, and they deserve AI they can actually trust, not AI that guesses.

We've spent the last year heads-down turning that mission into product and co-building with a small cohort of design partners, and are excited to scale these solutions to a broader set of partners across construction, energy, infrastructure and agribusiness.

So, what is Ontollo? We're the operational knowledge graph for asset-heavy operators. In simple terms, we give AI a real, trustworthy picture of how a physical operation actually works, so it can reason across the disconnected systems these companies run on (CRM, ERP, spreadsheets, sensors) instead of guessing from one system at a time.

We're not bolting a chatbot onto your data. We're building a System of Reality that AI can safely act, governed underneath, reasoning on top, with a full pedigree on every output. That's the same discipline we learned building infrastructure products that enterprises actually trust, and it's exactly what the enterprise buyers we sell to need before they'll put AI in the middle of mission-critical work.

- Noah and Tiffany

If you're interested in seeing Ontollo for yourself, our team is ready to give you a completely personalized demo tailored to your top business priorities.

Click here to request a demo.