A model forsmall-business work

A general AI model can write an estimate. It probably can understand what that estimate changes given all the context in the world. But what about the workflows behind it? The decisions needed to make the changes?

It would know that the crew capable of doing the work is already booked, the likely part is delayed, and moving one visit will displace a customer who has already been rescheduled. It would understand that changing the scope affects the material order, the invoice date, and when the business gets paid.

I think agent traces will become the raw material for that kind of model: a shared model of common small-business workflows, grounded by how a company actually works.

What's an agent trace? Sam Z Liu describes an agent trace as the record of the request, retrieved information, tool calls, actions, output, and feedback produced while an agent works. As agents take on longer jobs, more of the trace records what the agent did rather than what the user said.

The context graph idea gives that history an understandable structure. It connects a decision to the facts available at the time, the usual policy, the exception, the approval, and the reason behind it.

That history is part of an operating model. It needs some representation of:

current state + action → next state

What changed after the agent acted? Which other parts of the business changed with it? Did the eventual outcome match what the agent expected?

A useful trace would preserve the state before the action, the action itself, the resulting changes, the eventual outcome, and any correction a person made along the way. Tool-call logs alone are not enough.

A recent preprint called World of Workflows tested agents in a ServiceNow environment with thousands of business rules and dozens of active workflows. The authors found that the frontier models they tested often missed hidden cascading effects. An action could look locally valid and return a successful response while triggering a constraint violation somewhere else. They call this "dynamics blindness."

Small-business workflows have plenty of their own hidden effects. Scheduling a repair can look successful even though the technician needs a certification the scheduler did not check, the part will not arrive in time, or the change quietly breaks another promise to a customer. Completing the immediate step is different from understanding the state of the business after the step.

Shared patterns, local business

My hypothesis is that a world model for small-business work needs two layers.

One layer could learn common workflow patterns. A service request becomes an estimate. An accepted estimate becomes scheduled work. The work requires some combination of people, equipment, parts, permits, and customer communication before it becomes an invoice and eventually cash.

The other layer would belong to the individual business. Its traces and live systems would describe its customers, employees, equipment, open jobs, policies, and exceptions. It would know which technician can handle an unusual machine, why an old estimate is a poor comparison, and when the owner is willing to make an exception.

This shared layer is still a hypothesis. Common patterns could come from traces contributed intentionally, controlled training environments, and the parts of workflows that can be generalized without exposing a company's customers or judgment. The company-specific layer should remain under the company's control.

A follow-up preprint on enterprise world models has some interesting comments. In a synthetic enterprise benchmark, models trained on historical transitions became less reliable when the active configuration changed. Agents that inspected the current system and recovered its live rules were more robust under those shifts. A useful model cannot be baked once into model weights and assumed to remain correct.

I have written before that the owner is usually the reasoning layer connecting records, experience, and judgment. I also argued in The company that remembers that a pile of transcripts is not memory. Both constraints still apply here. Traces have to be refined, connected to outcomes, corrected, and allowed to expire.

I don't know yet how broad the shared model can become. Plumbing, HVAC, field service, retail, and professional services each have different dynamics. But even a model that understands one family of workflows, then grounds itself in one business's current state, would be far beyond software that merely fills in the next form.

A new service request would begin inside a model that already understands the customer, the open work, the constraints, and the likely consequences of the next action.