The AI Coworkers Who Can’t See
Most teams already work alongside AI agents. One triages the support queue. One drafts code changes for engineers to review. One summarizes the week for the leadership meeting. Next year there will be more of them, and they will do more than draft.
Each of these agents is given instructions and a few relevant documents today to act upon. However, their actions are based upon an incomplete version of the enterprise model. Each has text, but no picture of the organization it is acting in.
People manage this with years of context that was never written down. Agents do not have years. Leaders face the same problem from the other side: they see reports about the organization, not how it actually works. If people and agents are going to share the work, the organization has to become understandable to both.
Every Company Will Build Its Own Software
Every company is about to accumulate a great deal of custom software. Coding agents have made software inexpensive to build, and inference has made it inexpensive to run, so teams will build the tools they need instead of buying them. Each team will build workflows that fit: a hiring pipeline that matches how this company hires, an IT service desk that knows this company’s applications, a change-management process that follows this company’s rules for containing the impact of a failure. The software will not look like Salesforce or ServiceNow out of the box. It will look like the company.
That breaks the usual way AI improves. Frontier models are trained on public practice environments and benchmarks: computer use, common SaaS applications, generic tickets. The result is a strong generalist, but not an agent that knows your Snowflake access process, your change advisory board, or which Slack channel owns a failed deployment.
Once every company has its own software, every company will need a model trained on its own work. The base model is the chassis. The training environment is the road it has to drive on: your tickets, your tools, your approvals, your failure modes. Without that, you are deploying a driver who has never seen your city.
An agent therefore needs two things only the company can provide: an understanding of how its work actually flows, and a way to look a few steps ahead and check what the impact of their action will be before taking it. A record of the current state helps with the first. Only a model of how that state changes provides the second.
What Robotics Already Learned
The organization is the next robot. Robotics faced this problem first. For a long time, a robot was a program: detect this, then do that. It worked on a factory line where nothing changed and failed everywhere else. The real world always had one more case than the program anticipated.
What changed was the idea that a robot should carry a world model: a learned simulation of its surroundings. With one, a robot can predict the consequence of an action before taking it, and plan by imagining the outcome. Yann LeCun’s joint-embedding predictive architectures (JEPA) sharpened the idea: predict the future in a learned, compressed representation, not in raw pixels. A robot reaching for a cup does not need to forecast every reflection on the glass. It needs to know where the cup will be.
An Organization Is a World
An organization has the same structure at a different scale. It has a state: who owns what, what is blocked, what has been promised to whom. It has actions: reassign, reprioritize, ship, escalate. It has dynamics: a change to one team’s on-call schedule shifts the load onto another. And it is only partially observed. No one sees all of it, including the people running it.
If robots needed a world model to leave the factory, agents need one to leave the chat window.
That is what we mean by an organization world model: a representation of the company’s state, learned from the record its people and agents leave as they work, that can predict what happens next and what would happen if something changed.
For the people leading the company, a world model provides line of sight. An org chart shows reporting lines. A dashboard reports results after the fact. Neither shows how the work produced them. With a model of the organization, you can trace a decision, a metric or a customer outcome back through the work, systems and agents that produced it. You can also trace a proposed change forward to see what it will affect and who will feel it.
Logs Are Not a Model
It is tempting to assume the data already exists, and in one sense it does. Every commit, ticket, thread, call and deal is recorded somewhere. But a log is a collection of events. A model is a state that those events update. You can search a log, but only a model can answer a question about the future.
The first thing an organization world model needs is therefore a map: the people, agents, services, accounts and decisions in a company’s tools, connected by the links those tools already hold. That map should be built from the record of the work itself, with secrets removed and nothing overwritten, so any past week can be reconstructed and learned from. And it must respect the same access boundaries as the systems it draws on: no one should see more through the map than their own systems would show them.
The map is the observation. The world model learns from how the map changes over time, the way a robot’s model learns from successive camera frames. Because that record describes how the company actually operates, it should stay under the company’s control.
Build Agents from How Work Flows, Not from Hand-Written Instructions
The usual approach is to give each team a blank chat window and ask them to “build the agent for their job.” That puts the burden on your best people, and it fails for two reasons.
First, any one person’s view of a workflow is a snapshot. They see the tickets they handle and the tools they use. They do not see the path across systems: from Jira to Slack to Okta to the change board to the on-call rotation. That path appears only when you collect the record of work over time, connect it across agents and teams, and reconstruct the actual process.
Second, written instructions capture one person’s judgment on a particular day. That judgment is essential for the hard case and unreliable for the next hundred routine ones. Agents should be built from the accumulated record of how work actually flows, and your experts’ judgment should go where it matters most: reviewing what agents propose and deciding what ships.
The approach that works is a loop: collect the record of work, discover the workflows, build agents for specific roles in them, feed their failures back into the scenarios, and improve the agents. Agents should evolve from evidence instead of being written by hand.
Build Agents Around Processes and Systems, Not People
You do not build an agent that imitates John Smith in IT. You build agents around what the company is made of: applications, products, code repositories, services, processes and technologies.
John Smith goes on leave. The Snowflake access request process does not. The agent responsible for that process should be grounded in how the process is structured, who holds which permissions, and how past requests were resolved, not in an imitation of John Smith’s writing style. John Smith still decides how the process should work. The agent takes the repetitive part of it off their desk.
The same applies to a code repository, a payment service, a change process or a customer onboarding path. Each is a lasting part of the organization, and each can be rehearsed before a new agent or internal tool is allowed to touch live systems.
Rehearsal Before Action
The reason to have a world model is to try things in it before trying them on the organization. We call this rehearsal. A leader describes a change, such as moving billing on-call to a follow-the-sun schedule or assigning an agent to the refunds queue, and the model plays it forward on a copy of the organization’s map many times, each under slightly different starting conditions.
Then someone has to say whether the outcome was good, and the organization defines what good means. It should be possible to state that in a sentence, turn the sentence into explicit checks the organization confirms, and score every rehearsal against those checks the same way each time. The verdict should not depend on anyone’s impression.
Finally, a rehearsal is only as valuable as its track record. When actual results arrive, the forecast that preceded them should be scored. Over time, every answer should carry a calibration: how often answers like it turned out to be right.
Autonomy Is Earned
A world model is also where agents can learn. Reinforcement learning, in which an agent improves by trial and error, works when an agent can try, fail and try again thousands of times. No one wants that happening on their live support queue. A world model of the organization is where it can happen safely.
That is why autonomy should be earned in stages. A new version of an agent should first be tested against scenarios drawn from the organization’s own history, then run in shadow mode beside the current version, where people can see what it would have done, and only then be promoted or rolled back. An improved instruction should be kept only when it outperforms the current one on cases it has not seen, and a person should approve it before it is installed. An agent should act with the access of the person who asked, never more.
Training agents directly against the world model’s measure of a good outcome is the research direction we are most excited about.
What We Won’t Do
A model of an organization is powerful, so it is worth stating plainly what we will not build.
- A model that shows anyone more than their own systems would.
- Results that widen access.
- A simulation of your people.
- A system that scores or ranks individuals.
- A model that has to leave your enterprise boundaries.
What We’re Building
A self-driving enterprise:
- Keeps building custom software for how it works.
- Turns the record of its own work into a working model of itself.
- Tests agents and process changes against that model before they go live.
- Lets its agents improve from the failures they discover.
Leaders get line of sight. The teams deploying agents get a place to rehearse. Both rely on the same world model.
Companies that treat agents as chatbots added onto yesterday’s systems will keep fighting incidents. Companies that treat their organization as something they can simulate, score and train agents against will be the ones that actually become self-driving.
AltFn is building Sapphire, the world model for the self-driving enterprise: one model of how an organization operates, shared by the people who lead it and the agents that work in it. Underneath it, we are building the research to make that model’s predictions trustworthy. People and agents will both do better with a model of the world they share.
If your organization already has people and agents working side by side, we would like to hear from you. Get a demo