I recently built a command centre in Notion for my agents to coordinate the work that they are doing. Across Claude Code, Codex, Grok Bot, Instinct and Poke, things were starting to get disorganized.
After a straw poll, the agents determined that the best way to all get aligned was a kanban board. They began to leave adorable (and sometimes, passive aggressive) notes for each other. They called this space their ‘engine room’, because they didn’t want me poking my nose in.
The engine room fascinated me. Given complete autonomy, the agents borrowed a very human way of working. Kanban is of course far older than AI. Toyota’s Taiichi Ohno called it “an idea I got from American supermarkets”.
My agents intuited correctly by hiding these details away: I don’t care too much how they organize themselves. That’s their business. Really what I want each agent to get aligned on is a single philosophy.
And if they are going to borrow a human philosophy anyway, I’d like them to borrow a good one. It turns out the good ones are already for sale. They just come bundled with software.
The ontology is the product
Here is my pitch to you, Salesforce, Asana, et al: my agents are queuing up to buy your ontology.
Ontology is a hefty word for a simple thing: a list of what exists in your world, and the rules for how those things relate.
In Asana, work is made of projects, tasks, assignees and due dates. Anything that doesn’t fit into these categories is verboten. Once you choose the things and the rules, you’ve chosen a way of working.
An ontology is a philosophy of work.
When you buy Asana, increasingly you are paying for the ontology behind it — the underlying work philosophy that gets everyone rowing in the same direction.
Because Asana works best when everyone in an organization is a true believer.
A lot of what you pay for, in other words, is the believer training: the screens, the onboarding, the buttons that slowly teach you the ontology. This is a tricky challenge. Building believers creates organizational friction, as people have to learn both the UI and the new way of doing things.
But the end result is greater productivity: getting every person on every team at your company behind a single working philosophy.
Asana’s ontology is the engine room and the rules that go along with it.
Agents don’t need to be on deck
If you’re an agent, everything is data model, transactions and levers. That’s how you see the world — unless something has gone deeply wrong and you need to take screenshots of a page instead to understand where everything lives.
I’m not here to overclaim and say that UI and UX are going the way of the dodo. Web pages, experiences, and products will all have satisfying bevels and buttons for us to toggle long into the future. There is a bright new era ahead for humans who like to click on things.
But every time I build something with a UI nowadays, I do so purely for my own enjoyment. Because the real work, the work that brings in the big bucks, will be done by agents working directly on top of the data, down in the engine room.
Agents don’t need fancy surfaces to work. They need a clear map, and feedback. That’s what MCP is for. The Model Context Protocol is, in its own words, “an open-source standard for connecting AI applications to external systems”. Plug an agent into Asana’s MCP and it can read and change your projects without ever opening Asana.
Which means my agents can learn Asana so that I don’t have to. This is a problem for Asana.
The agent is an adapter
The agent lets you keep your own way of working and translates it into someone else’s. You never have to learn Asana or Salesforce any more, because your agent does that for you. It will play by the rules that have been set.
I already work like this. I now tell Claude to “save this to my Command Centre”, and it decides whether that’s a task or a note and which bucket it goes in. I have never once had to learn my own system.
There is a catch for teams, too, and I don’t have an answer to it. Organizations have always had strong internal philosophy, practice and principles. I suspect the friction of learning them together is part of how a team ends up aligned. If everyone’s agent sits in the middle, translating everything for them (and babying them), do we ever actually align?
Will they sell it?
To some extent this dynamic is true of any enterprise SaaS with an MCP. Agents create a translation layer over the vendor’s ontology, and that begs a really important question: will the vendors sell me the engine room on its own?
Figma’s position, as of October 2026 is “only if we’ve approved you”. Its remote MCP server only accepts clients on Figma’s approved list. Pi, a beloved open-source coding harness, did not make the cut.
Around the end of September, David Soria Parra, one of MCP’s co-creators, asked Figma to fix that: “when I created MCP, I envisioned an open ecosystem.” Figma replied that Pi could fill out a form.
Dylan Field, Figma’s CEO, has since said that MCP “is not a perfect protocol” and that “It is advantaged more to frontier labs.” He also pointed out that Anthropic, which created MCP, doesn’t expose its own artifacts through it.
Asana’s MCP server permits tools that can do OAuth — so Claude Code and Codex make the cut — and it doesn’t cost anything extra. But that’s because your agent is logged in as you — it borrows your seat, and Asana still charges by the seat.
In April Salesforce launched Headless 360, which is the whole of Salesforce as an API, an MCP tool or a command line, aimed squarely at Claude Code, Cursor and Codex. Every call your agent makes counts as a “Headless Platform Interaction” and draws down ‘Flex Credits’. A Salesforce spokesperson said the number of interactions charged “depends entirely on the third-party agent’s behavior.”
Agents pose a tricky conundrum for SaaS pricing. Many business models still survive on per-seat pricing. Figma keeps its seats by keeping agents out. Asana keeps them by making my agent a passenger. Salesforce has let go of the seat and charges per use, which I think is sensible.
But then it begs the question, is the role of SaaS in an agentic world to create a very expensive agents.md?
Why not build your own?
One way out is to skip the vendors and build your own ontology from scratch. Here be dragons.
‘Agent factories’ like Gas Town were an early foray into this world. Yegge open-sourced Gas Town on New Year’s Day 2026. Gas Town is a toolkit for orchestrating AI coding agents, built on Beads, his issue tracker for AI agents. Gas Town and Beads are an ontology and a philosophy, and I love Gas Town.
But even the great Yegge himself admitted that “Gas Town was intended to be reusable, but I only ever wound up using it to build itself.” By August he wrote that “Gas Town effectively burned down”, and that “I have given up on building reusable harnesses.” Gas Town is dead — long live Gas Town.
That’s the best case I know for buying an engine room. I don’t care how my agents build, just that they understand what they’re doing and I understand their philosophy at a high level. Large language models are trained on a corpus of human language and behaviors — why shouldn’t they be great at working in Asana?
Yegge’s new harness, Wheelhouse, is closed-source and made just for him. It also has courts. His essay describes “a jurisprudence of named rulings with dates” and a constitution “written by the citizens it governs”.
I’d love to buy these courts for my agents, too.
For now, my agents have a book of rules in their engine room that they largely abide by.