Part Three: What Replaces The Boxes?

Part three of a three-part series on the changing architecture of coordination.

In Part One, I argued that AI is changing the economics of coordination. Some of the work that once had to be embedded permanently inside jobs, departments, and reporting relationships can increasingly be assembled around a need. Part Two looked at the other side of that shift. Those structures were carrying much more than the visible work. They were also carrying context, accountability, and the means by which people developed judgment.

That leaves a different question than what the organization chart of the future will look like. How do those capacities stay connected when they no longer sit inside the same organizational container?

Return to the small-business credit decision that opened this series. The application enters digitally. Identity evidence may come from one provider, transaction data from another, fraud signals from another system, and risk assessment from a model. Pricing may happen automatically. Servicing may sit somewhere else entirely. The business owner still experiences one decision.

The old operating model often kept many of the things needed to make that decision coherent relatively close together. The relationship manager knew the customer. The credit team knew the policy. Managers had authority to make exceptions. Records sat inside the institution. People knew where a difficult case could go. A distributed system separates those capacities. That does not eliminate the need for coordination. It changes what has to be coordinated.

The dependency matters more than the box

A department is not coordination. It is one way of connecting expertise to a problem. A reporting line connects authority to a decision. A recurring relationship connects current information to history. A review process connects an unusual case to another perspective. Those are the dependencies coordination has to manage. The structures were mechanisms for managing them.

For much of the Industrial Age, permanent organizational structure handled many of those connections almost automatically. If expertise lived inside the credit department, locating expertise was partly solved by knowing where the department was. If a manager could approve an exception, the reporting structure also located authority. If customers repeatedly dealt with the same people, context accumulated along with the relationship.

As work spreads across people, AI systems, external providers, platforms, and institutions, those connections still have to be made. They simply stop being contained by the same structure.

That changes the design problem. Instead of asking where a piece of work belongs, the system increasingly has to ask what the situation requires. What context changes the meaning of the evidence? What capability is needed? What can the machine do on its own? When does someone else need to enter? Who can change the decision? Who is responsible if the combined system gets it wrong? The more fluid the structure becomes, the more explicit those connections have to become.

Context and capability have to move together

Consider the weakening receivables again. The numbers are real, but the relationship history changes their meaning. The business’s largest customer temporarily extended payment terms during an acquisition while orders remained strong. In the old model, that understanding might have existed largely because somebody remembered it. That is not a sufficient design for a distributed system.

Relevant context has to be able to travel with the work. But this is where an apparently simple technological answer becomes dangerous. If context helps systems make better decisions, the temptation is to collect as much of it as possible. That is not the goal. The goal is sufficient, legitimate context.

The system should know why a piece of information matters to this decision, where it came from, how current it is, whether another source contradicts it, whether it is appropriate to use, and whether the person affected can correct it if it is wrong. That is more demanding than simply making more data available.

It also means preserving enough memory to reconstruct what the system knew when it acted. If the credit decision is challenged six months later, the institution should be able to establish which information was available, which version of a model was used, what assumptions mattered, and what human intervention occurred. Context without memory gives the system a better present but no reliable past.

Capability has to move as well. Traditional organizations often moved the problem toward expertise. A difficult case traveled up a hierarchy, across departments, or into a specialist queue. A more dynamic operating model can increasingly reverse that movement, bringing relevant knowledge, prior cases, analytical tools, external expertise, AI capability, and the appropriate human specialist toward the problem.

That matters because expertise is expensive and frequently scarce. The experienced credit specialist should not have to review every ordinary application. But when the receivables pattern conflicts with other evidence, when the consequence is high, or when the case falls outside what the system has seen before, the operating model should be capable of recognizing that the need has changed and assembling different capability around it.

This is more than routing. Routing asks where the work goes. Coordination asks what the situation now requires.

Less structure requires more explicit authority

Industrial hierarchy often made authority visible. A manager could approve an exception. A senior specialist could reject a recommendation. Someone could stop the process. Distributed systems can make the work more capable while making those boundaries surprisingly hard to see.

A model recommends that the application be declined. A policy engine determines that the score meets the threshold. Another system executes the decision. A human reviewer sees the outcome afterward. Who actually decided, and who could have changed it? Those questions have to be answered before the system is deployed, not after something goes wrong.

Machines need defined boundaries around action. Within ordinary conditions, the system may be able to act without intervention. As uncertainty, contradiction, novelty, or consequence rises, that authority can narrow. At some point the system should lose the right to act alone.

The important question is not whether a human is somewhere in the workflow. It is whether the right human arrives when judgment matters and has enough authority to make a difference. Can that person stop the action? Can the person override it? Can the person reverse it after the fact? Can the system explain what produced the decision well enough for that person to exercise judgment? And can the business owner challenge the information or reasoning when something is wrong?

Those are different tests. An explanation without the ability to challenge the result may provide transparency while leaving the underlying power untouched. A reviewer who can see a flawed decision but cannot change it is not exercising meaningful authority.

Accountability has to hold at the edge

Suppose the application was declined because an outside data provider supplied incorrect information. The provider may be responsible for the data. A model team may be responsible for the scoring system. Another group may own the policy. A servicing platform may deliver the decision.

None of that should require the business owner to reconstruct the architecture in order to get the outcome repaired. Responsibility can be distributed inside the system without becoming fragmented at its edge. Someone still has to own the outcome. That means the person affected needs a route to recourse, and the institution presenting the experience needs enough authority to investigate, reconsider, correct, or repair what the broader system produced.

Less hierarchy for coordination does not mean less accountability. In many cases, it means accountability has to become more explicit, because organizational location no longer makes it obvious.

The system also has to reproduce what it consumes

Most of the capacities described so far can be made more explicit. Context can carry provenance. Authority can be bounded. Escalation can be specified. Accountability can be assigned. Decisions can be recorded. Judgment and trust are harder.

Part Two described the apprenticeship problem created when AI absorbs much of the routine work through which people historically became experienced. That problem becomes part of the operating architecture.

Imagine a junior credit professional looking at the same application. The AI sees weakening receivables and recommends a decline. The junior analyst reaches the same conclusion. An experienced specialist notices the relationship between the payment change and the customer’s acquisition and reaches a different one.

That disagreement contains something valuable. Why did the conclusions diverge? What did the experienced person notice? Was the information available to the model? Did the model have it but interpret it differently? Did both the model and the junior analyst rely too heavily on the same signal?

The future development system can use those moments deliberately. People can make assessments, compare them with machine recommendations, review disagreements with experienced practitioners, and examine consequential cases where human and machine judgment agreed as well. The work system itself becomes part of the learning environment. That does not recreate the old apprenticeship. It creates a different mechanism for producing judgment after some of the work that once produced it has disappeared. The operating model has to replenish judgment at the same time it consumes it.

Trust presents a different problem, because it cannot simply be specified into existence. People who have worked together repeatedly know things about one another that no capability directory fully captures. They know who tends to see risks early, who communicates uncertainty well, who asks for help before a problem becomes dangerous, and whose unusual concern deserves attention. Customers accumulate similar experience with institutions.

That familiarity lowers coordination cost. Not every uncertainty requires verification. Not every exception requires a contract. Not every interaction starts from zero. A highly dynamic organization could optimize much of that away without intending to. Specialists could be assembled perfectly around each case while rarely working together twice. Customers could receive technically excellent service while encountering a different machine, provider, or person at every turn. Expertise could become easier to locate while the relationships through which people learn whose judgment they trust become thinner.

That is why the human layer cannot simply be replaced with better orchestration. The answer is not to preserve every permanent team or every traditional customer relationship. It is to recognize that fluid execution may still need something stable underneath it: professional communities, repeated relationships, mentorship, shared experience, and places where familiarity can accumulate. Technology can support those conditions. It cannot manufacture the trust that eventually grows from them.

A practical test for the new system

The architecture will vary by organization and by decision. But the questions underneath it are becoming clearer. For any consequential process distributed across people, machines, teams, or providers, leaders should be able to answer:

• Does the relevant context travel with the work, and can we tell where it came from, how current it is, and why it may be used?
• Can the system assemble the right human and machine capability when the situation changes?
• Is machine authority explicit, including the conditions under which it ends?
• Can a qualified person stop, override, reverse, or repair the action?
• Can the decision be explained?
• Can it be challenged?
• Is there meaningful recourse?
• Is someone clearly accountable for the outcome?

A system can be extraordinarily efficient and still fail those tests. It can move information quickly while moving the wrong context. It can automate decisions while leaving authority ambiguous. It can connect many capable components while leaving nobody responsible for how they behave together. It can use expertise faster while weakening the processes that create future experts.

That is why the transition is bigger than automating existing workflows. The Industrial Age could bundle context, capability, authority, accountability, memory, learning, and trust inside relatively stable organizational structures. A more distributed, AI-mediated system increasingly separates them. Once separated, they have to be reconnected deliberately.

Part Two ended with the observation that these capacities do not have to remain attached to the structures that once carried them. But they do have to exist somewhere. The point is not to preserve the boxes. It is to make sure the capacities they carried survive what comes next.