The org chart is not a routing table

An org chart tells you where accountability was placed when it was drawn. It does not tell you where work went this morning.

That distinction became harder to ignore after reading OpenAI Economic Research's new report, Work at the Frontier: How AI is expanding what people do at work. The researchers analyzed a random sample of more than 800,000 work-related messages from individual ChatGPT accounts belonging to U.S. users whose self-reported roles came from ChatGPT Business. They mapped each message to work activities in the U.S. Department of Labor's O*NET database, then compared the activity with the occupation attached to the user.

Across the sample, 16.8 percent of work-related messages concerned tasks historically associated with another occupation. Once broadly shared work such as writing, summarizing, and scheduling was removed, the share was 43.5 percent.

The tempting conclusion is that AI is erasing jobs. The report does not establish that. A message is not a completed task, a good outcome, an hour saved, or a specialist displaced. The study cannot observe whether the answer was used, reviewed, or quietly abandoned. Its sample covers eight occupation groups and is not representative of the entire workforce.

What it does show is more operationally interesting: people are attempting work across old boundaries before titles, processes, and accountability models have caught up.

The org chart is becoming a poor routing table.

The observation is movement, not replacement

The report separates messages into generic work, work within the user's occupation, and work associated with another occupation. Generic activity accounts for 61.5 percent of the sample. Within-occupation work accounts for 21.8 percent. Cross-occupation work accounts for the remaining 16.8 percent.

The denominator matters. “Nearly half” describes the 43.5 percent share among occupation-specific messages after generic work is excluded. It does not mean that nearly half of every worker's day has moved into another profession.

Even with that correction, the pattern is uneven enough to matter. Cross-occupation work is a majority of occupation-specific messages for customer-experience, design, human-resources, legal, and marketing users. Engineering behaves differently. Only 18.5 percent of engineering users' messages involve work associated with other fields, while engineering tasks account for 7.4 percent of messages among workers in the seven other groups. Troubleshooting software and technical systems travels particularly widely.

Some roles are importing many unfamiliar tasks. Others are exporting pieces of their practice. Marketing does both.

This is not a clean transfer of an entire occupation. Tasks are moving at different rates because they have different interfaces. Drafting a first pass at copy is easy to express in a prompt. Accepting liability for a contract is not. Asking for a database query is cheap. Knowing whether the result should influence a financial decision remains attached to context, evidence, and consequence.

AI lowers the cost of attempting a task before it lowers the cost of being wrong about it.

A handoff used to carry hidden information

Organizations complain about handoffs because handoffs are slow. They also carry more information than most workflow diagrams admit.

Sending a problem to a specialist says at least five things:

1. This task belongs to a body of practice with known failure modes.
2. The recipient is expected to recognize exceptions the requester cannot name.
3. The recipient has access to tools or data that may not be broadly available.
4. Someone knows who is accountable for reviewing the result.
5. The organization accepts the cost and delay of that route because the consequence justifies it.

An AI assistant can remove the visible handoff while dropping all five signals. The person nearest the problem can now produce a plausible artifact without waiting for another team. That is genuinely useful. It is also how a local speed improvement can become an organizational ambiguity.

I encountered a smaller version of this problem while building D4U7. The difficult part of asynchronous work was not moving text between people. It was preserving why a decision existed, which evidence travelled with it, whose dissent remained unresolved, and what the next person was allowed to do. Faster transfer without that envelope produced faster confusion.

AI-assisted crossover needs the same envelope. The artifact is not enough.

The missing object is a task passport

My working model is a task passport: a small, durable record that travels with work when the person performing it, the tools used, or the responsible domain changes.

The passport is not a giant approval form. It should be cheap for ordinary work and become more demanding only as uncertainty or consequence rises. Its purpose is to preserve the information that an informal specialist handoff used to provide.

The key word is eligible. A model can help someone perform work outside a historical role without granting that person every authority associated with the role. A marketer may diagnose a broken tracking script and propose a patch. That does not automatically authorize production access. A developer may compare contract language and surface unusual clauses. That does not make the legal consequence theirs to accept.

This was the line I eventually made explicit in V0M3: generated text remained a proposal until an eligible review changed its state. The important part was not distrusting every output. It was refusing to let the production mechanism silently decide who could make something canonical.

Review should follow consequence, not authorship

Most review systems are organized around artifact type or team ownership. Code goes to engineering. Copy goes to marketing. Contracts go to legal. That routing weakens when one person and an assistant can produce all three during the same piece of work.

A consequence-based review model asks different questions:

• Does this change public behavior?
• Can it spend money, expose data, create liability, or alter a user promise?
• Is the outcome reversible?
• Does it rely on evidence the requester cannot independently assess?
• Is there a hard policy that must remain outside the model's discretion?
• What would an expert notice that a generally capable person might not?

Role based

Send the artifact back to its traditional department

Familiar ownership is easy to explain, but every cross-functional attempt recreates a queue even when the consequence is small and the work is easy to verify.

Consequence based

Send the risky decision to an eligible reviewer

Low-consequence work can stay local, while irreversible, regulated, or weakly evidenced decisions still reach the specialist boundary that protects them.

The practical unit of routing becomes the decision, not the file. One document may contain a factual summary that needs source verification, a pricing recommendation that needs commercial approval, and a privacy claim that needs policy review. Sending the whole document through one department either over-reviews harmless text or under-reviews the dangerous sentence.

This is where claim-level provenance and typed effects stop being academic neatness. They let a system route the narrow part that crosses a consequential boundary.

The diagram is deliberately small. Most work should not require a ceremony. The passport becomes valuable because it gives the system enough structure to know when ceremony is warranted.

Specialists do not disappear; their leverage changes

The report is careful not to interpret task crossover as occupation disappearance. That restraint is justified.

When routine attempts become cheap, specialists spend less time being the only person who can produce a first draft. Their higher-leverage work moves toward boundary design, exception handling, verification, and teaching the organization what failure looks like.

A security engineer can publish a safe diagnostic path and define which findings require escalation. A lawyer can turn recurring review concerns into clauses, checklists, and non-negotiable constraints. A designer can encode accessibility and interaction requirements in components and tests. A finance specialist can define the assumptions and reconciliation checks that make a model useful.

This is not merely “experts review AI output.” That would turn specialists into exhausted approval queues. The better move is for experts to build reviewable interfaces to their practice:

• Examples of valid and invalid work.
• Tests that catch common failure modes.
• Evidence requirements for consequential claims.
• Explicit safe operating ranges.
• Escalation conditions for ambiguous cases.
• Receipts that improve the next attempt.

The specialist becomes partly a maintainer of the boundary through which work travels.

That idea has been hiding in software engineering for years. A deep module lets many callers use a capability without understanding its internal complexity, but the interface does not pretend the complexity vanished. It concentrates the difficult decisions behind a contract. AI makes that pattern relevant to organizational expertise, not only code.

Small teams expose the shape first

Among users in the middle half of message volume, the report finds that cross-occupation messages fall from 18.9 percent in workspaces with 2 to 5 seats to 16.3 percent in workspaces with 101 or more seats. The pattern is descriptive, and it is not monotonic among the heaviest users. Workspace seats are also not the same thing as company size.

Still, the proposed explanation is credible: people in smaller organizations have fewer specialists immediately available, so the person who encounters a problem is more likely to attempt it.

Small teams therefore reveal both the upside and the missing infrastructure early. A founder can move from customer research to a pricing model to a landing-page fix without waiting for three functions. The cycle is fast because context stays local. The risk is that the same person may not know which assumptions deserve specialist scrutiny.

Large organizations have the opposite failure mode. They possess expertise but hide it behind queues, ticket forms, and departmental ownership. If AI simply helps employees bypass those routes, the organization loses control. If every AI-assisted task must re-enter the old queue, it loses the speed.

The useful design keeps local execution and makes expert constraints portable.

The measurement layer can easily overclaim

This study is unusually useful because its limitations point directly at what a production system would need to measure next.

The unit is a message. A message does not reveal the duration of the task, the quality of the answer, whether the user had prior expertise, whether the artifact was accepted, or whether another person reviewed it. The occupational mapping is also a model-mediated classification against historical O*NET activities. A request can contain several tasks but receives one primary activity.

Those limitations do not invalidate the crossover signal. They prevent it from being confused with value.

An organization measuring its own task movement should resist the easy dashboard:

Employees completed 4,000 tasks outside their roles this month.

That number may describe 4,000 prompts, 800 abandoned drafts, 200 accepted results, and three expensive mistakes. Counting attempts rewards boundary crossing even when it creates rework elsewhere.

I would measure the path instead:

• How often did a person attempt work outside their established domain?
• Which attempts were accepted without revision?
• Which required specialist correction, and what kind?
• How much waiting time disappeared?
• How much review time moved downstream?
• Which errors escaped because the old handoff was removed?
• Which specialist rules became reusable after repeated reviews?
• Did the worker become more capable, or merely more dependent on an opaque answer?

The outcome is not maximum crossover. It is the largest safe expansion of local capability with visible review cost.

I want to test the routing model, not merely name it

The next useful step is a small instrumented trial.

I would start with a mixed backlog of software maintenance tasks: copy changes, accessibility fixes, analytics questions, dependency updates, data corrections, support replies, and a few security-sensitive operations. Each task would receive a passport before execution. The passport would record origin role, inferred domain, consequence class, eligible tools, evidence requirements, reviewer, and reversibility.

An AI-assisted worker could attempt any low-consequence task and propose work for higher-consequence cases. A deterministic policy would route only the consequential decision to a specialist. Every result would end with an acceptance, revision, rejection, or escalation receipt.

The experiment would compare three routes:

1. Traditional ownership: every task goes to the historically responsible role.
2. Unrestricted crossover: the nearest worker attempts and accepts the task with AI assistance.
3. Passport routing: the nearest worker attempts the task, while authority and review follow consequence.

The useful measures would be end-to-end time, specialist interruption time, revision depth, escaped defects, evidence completeness, and the number of review rules that became reusable. I would also track work that the system correctly refused to keep local.

The third route should not be assumed to win. Passport overhead may cost more than it saves for small tasks. Specialists may disagree about consequence classes. Workers may omit context they do not know is important. Those failures are the point of the trial. A routing model earns trust by showing where it breaks.

N17Q already gives me part of the machinery: proposals are distinct from effects, policies bind authority close to execution, and receipts preserve what happened. The new piece is organizational rather than technical. The trace needs to show not only which tool acted, but which practice the task borrowed from and why the accepting reviewer was eligible.

The role will lag the task graph

Job descriptions change slowly because they are agreements about hiring, compensation, status, and accountability. Task routing can change every morning.

That lag is not automatically bad. Stable roles preserve expertise and make responsibility legible. The mistake is assuming the role map describes the live flow of work after general-purpose assistance makes unfamiliar tasks cheap to attempt.

The emerging system needs two views at once:

• A stable accountability map that names owners, expertise, and non-delegable authority.
• A live task graph that shows where work is actually attempted, reviewed, revised, and accepted.

The distance between them is useful information. It reveals where people are waiting unnecessarily, where expertise needs a better interface, where authority has become ambiguous, and where a new role may already exist in practice before anyone has named it.

The report's most important result is not that 43.5 percent figure by itself. It is evidence that workers can now explore new task combinations faster than organizations can rewrite their boundaries.

That is a routing problem.

The org chart should remain an accountability map. It was never built to be the runtime.