The Use of Knowledge in Organizations

For more than a century, companies have been built around a basic constraint: knowledge is scattered, but decisions still need to be coordinated. The dominant answer was hierarchy. Information moves up. Decisions move down. Managers translate between local detail and centralized control.

That model worked well enough in the industrial era. It is much less suited to a world in which most valuable work happens through language, exceptions, judgment, and context.

Friedrich Hayek made the deeper point almost eighty years ago in The Use of Knowledge in Society: knowledge is not concentrated in one place. It is dispersed across individuals, situations, and moments in time. No central planner can ever fully possess it. Inside organizations, the same problem appears every day. The people closest to the work know things the system does not know, and by the time those insights are formalized, escalated, and translated, much of their value has already been lost.

This is also why Jack Dorsey’s recent note on emerging role types in AI-augmented companies feels directionally right to us. The important shift is not simply that AI makes existing workers more productive. It is that once software can participate in the coordination layer, the organization has to rethink which roles still exist primarily to route information, which roles own improvement, and which roles remain closest to judgment and accountability.

This is one of the core reasons why we have argued for years that the future of enterprise software is not another layer of rigid workflows, but something closer to a navigation system for work.

The Knowledge Problem Inside Organizations

In theory, companies already document how work should happen. They have process manuals, SOPs, workflow diagrams, approval matrices, ticket queues, and enterprise systems. In practice, that still leaves most of the real work outside corporate memory.

The reason is simple: work does not just happen in systems. It happens in threads, emails, side conversations, notes, calls, judgment calls, escalations, and precedent. The most important part of operational execution is often not the happy path but the exception path. That is exactly the part traditional systems are worst at capturing.

We have written before that only a relatively small share of work is cleanly automatable through predefined rules. The rest depends on local knowledge and context. That is not a software failure in the narrow sense. It is a knowledge problem.

Hierarchy Was a Workaround

Once you see the organization through that lens, hierarchy starts to look different. It is not just authority. It is an information-routing mechanism.

Managers historically existed in part because organizations needed people to:

collect local signals from the edge
interpret and summarize those signals
route decisions across teams
maintain coherence across a complex system

That was a rational design for a world in which computers could not understand language, infer context, or learn from precedent.

But it also created well-known limits. The more complexity an organization accumulates, the more layers it adds. The more layers it adds, the slower information flows. And the slower information flows, the harder it becomes to adapt the organization to reality.

This is why modern enterprises often feel simultaneously over-managed and under-informed.

Why AI Changes the Equation

The key shift is not that AI makes individuals more productive. The deeper shift is that modern language models can finally process the medium in which so much organizational knowledge actually lives: language itself.

For the first time, software can continuously ingest and reason over:

unstructured conversations
case histories
notes and approvals
documents and policies
emails and operational traces
structured system data tied to the same work object

That means the organization no longer has to rely entirely on humans to manually broker knowledge from one part of the system to another. Software can now participate in the coordination layer itself.

This does not mean AI replaces expertise. It means AI can increasingly replace part of the old routing overhead that stood between expertise and action.

The old model relies on static maps, manual updates, and predefined routes. The new model looks more like navigation: shared context, live signals, and continuous rerouting based on what is actually happening.

That is why the right analogy is not a workflow builder. It is Google Maps.

Google Maps does not eliminate the driver. It learns from the drivers. People move through the world, create traces, reveal congestion, and by doing so become part of the system that helps route everyone else. The system turns distributed activity into dynamic guidance.

Organizational work is similar. Experts are not outside the system. They are part of the signal that makes the system more intelligent. Every exception they resolve, every judgment they make, every escalation they handle, and every path they take through a case contributes to a richer understanding of how work actually gets done.

This is also why we continue to use the phrase Navigation System for Work. The value is not just in storing knowledge. The value is in dynamically recommending the best next path for the case at hand, based on live context, precedent, and available capabilities.

Memory Is the Missing Layer

To do that well, the organization needs more than documentation. It needs memory.

At a high level, there are two types of memory that matter:

Entity memory: what the organization knows about the relevant objects in the world, such as customers, invoices, contracts, claims, assets, suppliers, tools, and policies
Journey memory: what the organization knows about how work was actually carried out across time, including decisions, activities, escalations, collaborators, and outcomes

Those two layers need to come together in one operational context. A case is never just an object. It is an object in motion. It has a history, a current state, a set of related entities, and a path through the organization.

In Interloom terms, this is why cases, threads, procedures, activities, artifacts, and tools all matter. They are not separate UI primitives. Together, they form the memory substrate from which better coordination becomes possible.

A useful organizational memory combines entity context with the actual journey of work. The system gets stronger when it can connect the object, the trace, and the outcome.

The Organization Becomes Simpler, Not Flatter

Once AI starts to participate in coordination, many people jump too quickly to the claim that hierarchy disappears. We think that is the wrong conclusion.

The better conclusion is that the organization becomes simpler in form, even if not flatter in the simplistic sense.

In most enterprises, there are really two structural dimensions that matter:

a horizontal end-to-end trace, where a claim, dispute, onboarding case, or invoice moves across multiple functions
a vertical capability structure, where specialists build deep expertise in a certain type of task

That was true before AI and remains true after AI. The important difference is that agents now join the same operational system.

A simpler AI-native org shape: one outcome owner across the process, team managers for each capability area, and specialist pools of humans and agents underneath. D3's hierarchy layouts are well-suited for this kind of orchestration chart.

This is where the argument connects directly to our earlier essay on AI-native organizations. That post argued that the org chart itself has to change once agents become real participants in delivery. This essay goes one step further: the reason the org chart changes is that the knowledge-routing problem changes.

From our perspective, there are only two core structural tracks:

1. Vertical Specialists

These are the people or agents who are very good at a specific class of tasks.

In human form, this is the underwriter, claims specialist, compliance reviewer, customer success expert, or operations specialist. In agent form, it is the specialized AI worker with the right model, tool access, operating scope, and guardrails for a narrower set of tasks.

The logic is identical for both: specialization increases quality and efficiency.

2. Horizontal Outcome Managers

These are the owners of the end-to-end result across the process trace.

In Interloom, that often maps most naturally to:

Space managers
Procedure managers
Integration managers

They are not responsible for a single task type. They are responsible for the outcome of the operating environment as a whole.

Rethinking the Roles

This is the part that matters most for the org chart.

In the old model, many roles existed mainly because the organization needed humans to pass information between silos, summarize status, escalate exceptions, and manually coordinate the next action. In the new model, some of that routing work can move into shared memory, recommendations, and agents that operate on the same case context.

That does not eliminate roles. It changes their center of gravity.

The cleanest way to think about it is to separate three kinds of responsibility:

1. Operators in the flow

These are the humans and agents who execute against the live case.

They work inside the process, handle tasks, resolve exceptions, and create the operational trace. In Dorsey’s language, this is closest to the human in the loop. In our language, these are the specialists actually moving the case forward.

2. Outcome owners across the flow

These are the people who understand the work end to end and are accountable for how the full operating environment performs.

They do not just manage a queue. They monitor the full path of work across teams, tools, and agents. They decide where procedures need to change, where escalations belong, and where the system is creating friction or risk. In practice, this often maps to the space manager, procedure manager, or process owner.

3. Capability managers and coaches

These are the leaders responsible for making a specialist capability better over time.

They manage the human team, the agent configuration, the access boundaries, the evaluation criteria, and the feedback loops for a specific domain. This is the closest analogue to Dorsey’s coaching layer. It is also why management does not disappear. Someone still needs to improve the capability, not just supervise the tickets.

The New Middle Management

Once you accept those two tracks, management becomes easier to define.

The manager of the future is not primarily a status-forwarding layer. The manager is the team manager of specialists and the owner of accountability boundaries.

This applies to humans and agents alike.

If an underwriting team contains junior underwriters, senior underwriters, and specialized underwriting agents, someone still needs to manage:

feedback loops
approvals
security and access
quality control
escalation rules
performance expectations

That is why we do not believe AI-native organizations eliminate middle management. They change it. The new middle management is not bureaucracy. It is expert team management for human and agent specialists, combined with clearer ownership of end-to-end outcomes.

Why This Was Always the Direction of Travel

This is also why a discussion like Jack Dorsey’s essay feels more like confirmation than revelation. The critique of hierarchy is justified. But the more practical point is that we have been moving toward this logic for a long time.

We have already argued that search is not enough, that planning is the new search, that software must become adaptive, and that organizations must become AI-native. The next step is simply to say the quiet part out loud: once coordination itself becomes software-assisted, the org chart cannot stay the same.

the real value of AI inside the enterprise is not just answering questions or generating content. It is helping the organization coordinate itself around live knowledge.

Predefined Versus Inferred

This is also why we think inferred systems will outperform predefined systems over time.

A predefined system only gets better when someone updates the rules. An inferred system gets better whenever the organization learns.

Rules-based systems improve until complexity catches up with them. Inferred systems improve as more real-world data, traces, and precedent flow through them.

What Interloom Is Actually Building

Interloom is not just another workflow tool. It is infrastructure for this new organizational layer.

The goal is to help companies:

capture the memory of how work is actually done
route work dynamically across people, agents, and tools
preserve governance and accountability
let specialists focus on tasks where they are strongest
let outcome owners improve the full system over time

For us, that is the practical meaning of AI-native orchestration.

And this is exactly where the next argument begins: if the organization can coordinate more dynamically, then the process itself cannot remain a rigid straight line.

That is why the natural operational follow-up to this essay is From Process to Flywheel.

This essay builds on earlier Interloom thinking about planning and navigation systems for work, AI-native organizations, adaptive automation, and the practical shift from rigid process logic toward flywheels.