The Atomic Unit of the Enterprise Is the Workflow

On November 2, after the market closed, Palantir reported the strongest quarter in its history as a public company: revenue of $2.313 billion, up 96% year over year; U.S. commercial revenue up 148%, surpassing U.S. government revenue for the first time; GAAP net income of $1.128 billion; and full-year guidance raised by nine points at the midpoint. The numbers will be quoted for a week. The argument made on that earnings call deserves to be quoted for much longer.

It came from CTO Shyam Sankar, who said it twice — once in his prepared remarks, and again, unprompted, at the end of the call:

"The atomic unit of the enterprise is not the knowledge worker. It is the workflow."

CEO Alex Karp made the matching point in writing, in the shareholder letter published the same evening. Language models left on their own, he wrote, generate limited value in the best case — and in the far more likely outcome, "they become agents of chaos":

"Lacking a grounding in the means of interfacing with the labyrinth of datasets, people, business units, use cases, and critical safeguards scattered across the modern enterprise, the LLM agent is a virtually unlimited liability, possessing a nearly unbounded destructive potential and a blast radius that tends towards infinity."

Full disclosure before we build on this: Palantir sells exactly the layer these sentences argue for. The argument arrives with a commercial interest attached. But it is not a slogan — it is a set of claims you can check against your own AI program, line by line. That is what this article does, and then it shows what following the argument actually looks like, in a workspace an ordinary team can start this week.

The argument, in five claims

1. The unit is wrong. The model labs, Sankar argued, assume the individual knowledge worker is the atom of the enterprise — so the industry's default product is an assistant for every employee. "You can make any set of workers more productive and generate no actual ROI." Measuring personal productivity measures an input. It can feel excellent and settle nothing. (Sankar's own exception: for work like coding, the knowledge worker is the workflow — which is why assistants fit there so well. For the vast majority of the enterprise, they are a component, not the unit.)

2. A model on its own is a liability, not an asset. Karp's letter passage above is the sharpest version: an agent with no grounding in the enterprise's datasets, people, business units, and safeguards is not a productivity tool waiting to be switched on. It is unlimited liability with an unbounded blast radius. The risk is not that the model is weak. It is that it is unconnected — to data, to process, and to anyone's authority to stop it.

3. The token layer is not the value layer. Karp, on the call, described the market's mood toward "fake deployment companies, token raw usage, lightweight companies reselling tokens, software companies that are reselling tokens and it counts as revenue — people are just tired of it." A company whose product is passing tokens through an API has sold motion, not outcome. Customers have started to notice the difference.

4. Ambition decides who gets value. Sankar again: the customers most successful at getting value from AI "have enormous ambition. Their goal is not something lame like OpEx reduction. It's market domination. And the opposite is true. Customers that struggle the most are narrowly focused on reducing cost." Trying to shoehorn AI into replacing the human, he said, "misses the moment completely." The cost-cutting frame doesn't just aim low — it aims at the wrong target, because it optimizes the seat instead of the work.

5. Money is a blindfold. Asked by D.A. Davidson's Gil Luria how to convince the unconvinced, Karp turned to the investors themselves: "What happened on Wall Street is everybody invested in these firms early. It's hard to see the reality when you're getting rich on something that's not actually working the way you think it is."

Five claims, one sentence underneath them all: AI's value is settled at the workflow — in whether the work itself changed, and in what compounds inside the customer's own processes: their operational data, their rules, their record of what was decided and done. The model is a replaceable part in that machine. The workflow is the machine.

Schematic — the two units you can measure, and what each one settles.

Why the pragmatic route starts with one workflow

If the workflow is the atomic unit, the practical question is not "which model?" or "how many assistants?" It is: where does one workflow live, so that people and agents can run it together, and its result can be counted? This is the ground Busabase is built on — not as a bigger platform, but as the smallest set of pieces that makes a workflow a home instead of a chat window.

The workflow's state lives in records. A workflow that exists only inside one agent's session has no state anyone else can inspect. In Busabase, the things a workflow moves — leads, requests, reviews, deliverables — are typed records in a Base, with owners, statuses, and relations. A person reads the same record the agent writes. When Sankar says value is generated "against the workflow," this is the bookkeeping that makes the claim checkable: the record is where the workflow's state, and its result, actually sit.

Grounding comes before autonomy. Karp's liability passage lists what an agent must be grounded in: datasets, people, business units, safeguards. In Busabase that grounding has addresses. Docs hold the standing policy — what counts as a qualified lead, what the company never promises. Skills hold the method an agent must follow, as first-class nodes in the same workspace, read before acting. Playbooks collect every Skill and every node's custom prompts into one catalog the agent searches before starting a job — so "how do we do this here?" is looked up, not improvised.

Liability is a governance problem, and governance is a mechanism. Every agent write in Busabase travels as a Change Request: a proposal with a field-level diff, a named author, and a decision that stays in the history after it lands. Permissions decide whether a write merges on the spot or waits in a person's inbox; a credential capped at changeRequest level can propose and can never land a change alone. A workflow's approval step is the same idea inside the process: the consequential move waits for the person who owns it. That is what a bounded blast radius looks like in practice — not a promise in a system prompt, but a queue a human actually clears.

It is not an assistant per seat. On shared records, the division of labor is visible: people judge, prioritize, and approve; agents execute, draft, and write back. The ROI conversation changes accordingly. You do not ask whether everyone feels faster. You ask the workflow: How many items entered? How many finished? Where do they stall, and who unblocks them? Those numbers live on the records themselves.

Pragmatism is also what you don't have to do. You don't rip out your stack: the record layer sits above the databases and applications you already run — Busabase itself runs on Postgres. You don't bet the company on one model: agents connect through the Agent Skill, MCP, OpenAPI, the CLI, or ACP, and the model underneath can be swapped while the records, rules, and history stay yours. And you don't start with forty workflows. You start with one, run it until its result is countable, and let what it teaches you — filed as experience, reviewed, and promoted into the Skill — make the next workflow cheaper. That compounding loop is the unglamorous version of what Palantir's customers are buying at enterprise scale.

One workflow, end to end

Here is the whole argument at working scale. The scenario is lead follow-up — chosen deliberately, because it sits on the revenue side of the business, where claim 4 says the value is. It is a starter design: adapt the names and fields to your own pipeline.

The run. A new lead becomes a record — and that record change is what starts the workflow; the runtime's first version, in place today, runs a workflow when you start it manually or when its records change. The agent reads the record, checks the company against the ICP doc, enriches what it can verify, and drafts the first reply in the company's voice — writing the draft onto the record, not sending it. The owner reviews the draft where it sits, edits or approves it, and only then does the agent send, log the send on the same record, and create the follow-up task records the cadence requires. Every outcome — reply, bounce, rejection with its reason — is written back to the same lead record. No lead leaves this workflow without a status, a next step, and an owner; that is its completion condition. When information is missing, the agent does not invent it: the record goes back to its owner with a task saying what is needed.

One instruction starts the human side of it, in your agent's chat:

In the Sales follow-up folder, take every Lead record that has sat in "New" for more than an hour. Check each against the ICP and voice doc, draft the first reply, and put the draft on its record. Do not send anything. Show me the queue here. After I approve a draft on its record, send it, set the follow-up tasks, and write the outcome back to the same record.

What has landed since, stated plainly. The workflow capabilities that were in flight when this was written have shipped, and they sharpen exactly this run: trigger only when a field changes to a specific value, so an already-qualified lead being edited doesn't restart the process; run on a schedule, in the editor's own time zone; call webhooks with custom headers, so authenticated systems are reachable; and pick an approval step's approver from the member list instead of typing an address. None of that changes the shape above — the same workflow, with finer triggers. And the objects this workflow moves — Company, Contact, Deal — will gain an explicit semantic layer of their own: an ontology, now in development and not yet available, that defines object types on top of the bases you already have. This article's argument does not depend on it; it is where the record layer goes next.

Schematic — the walkthrough above as one loop, not product UI.

FAQ

Does this mean assistants for individual employees are useless? No — Sankar's own exception covers it: where the knowledge worker is the workflow, as in much of coding, an assistant is the right unit and the fit is excellent. The claim is about the vast majority of enterprise work, where the workflow spans people, systems, and approvals. There, an assistant is a component inside the workflow, not a substitute for designing it.

Do you need a Palantir-scale budget to work at the workflow level? The argument is about the unit of measurement, not the size of the check. One workflow's home is records, standing rules, and reviewed writes — and the open-source Busabase edition self-hosts in one command, as our guide to your own personal database shows. Enterprise platforms sell this at enterprise scale; the discipline itself starts with a single workflow.

Which workflow should we move first? The one whose result you can already count: a clear start and end, a named owner, and a handoff that today happens by hand — in chat threads, spreadsheets, and someone's memory. If you cannot say where its state lives right now, that is the workflow to give a home first.

Start with one workflow

Karp's letter and Sankar's argument will be quoted as rhetoric. They are more useful as a test — four questions you can ask of any AI program, including one built on Busabase: Where does the workflow's state live? Where are its rules written, and who can change them? Which writes wait for a person, and where is that decision kept? And what did the last run teach the next one? A program that can answer all four is working at the atomic unit. A program that cannot is measuring seats.

The framework underneath those answers — records as memory, Docs as standing policy, Skills as rules, Change Requests as governance — is the subject of our companion piece, Supabase vs Busabase: The Difference Is the Memory-and-Rules Layer. To start: pick the workflow, give it a home, and run it once by hand before you automate anything.

• Code and self-hosting: github.com/busabase/busabase
• Desktop edition: busabase.com/download
• Docs: busabase.com/docs