Orchestration should choose the highest-value action whose dependencies and authority are actually in place.
That is a different ambition from making an agent more active. An agent can have a long list of available actions and still fail to identify the move that matters. The question is not simply whether it can do something. It is whether doing that thing advances the governing outcome, whether the necessary conditions hold, and whether it has the right to act.
Validate the pain point
The useful validation in Devin Kearns’s explanation of Antares is pain-point validation: company-specific operational knowledge is difficult to capture, and fragmented information makes consequential coordination difficult.
That matters because it identifies the problem an operating architecture has to solve. Exceptions, unreliable records and hidden dependencies are not peripheral inconveniences. They affect whether an apparently sensible decision can advance the business’s outcome.
Pain-point validation and competitive validation answer different questions. The first asks whether the problem warrants attention. The second asks how competing approaches perform against it. A recognizable problem can support several architectural responses; choosing among them requires examining their different consequences.
The useful comparison therefore begins with the constraint, not with the resemblance between two products. What must an operating system understand? What should it change? Who retains the right to make the commitments through which the work advances?
Context is a condition for action
In his explanation of Antares, Kearns describes a legal assistant’s sticky-note knowledge of which mediators to avoid. A list of available mediators is not the same as a usable understanding of which mediator to contact. The assistant carries a distinction that the formal system does not necessarily contain. Without it, an agent can follow the apparent process and make the wrong call.
Kearns’s broader point is that operational context is specific to the company. It includes not only how decisions are made, but why they are made that way: which exceptions matter, where people work around a written process, and what those workarounds preserve.
Understanding a practice is not the same as validating it as a decision constraint. Capturing a workaround does not itself authorize following it. An explanation of why people depart from a written process and permission to make that departure are different things.
The bottleneck is therefore not simply retrieving more information. It is representing what must be true before a decision can advance the work.
This is why the sticky note matters. Its value is not its format. Its value is the constraint it contributes to a decision, once that constraint has been established as applicable and legitimate. Turning the note into searchable text would make it easier to find. Turning its operational meaning into part of the decision would make it harder to ignore. Neither transformation supplies permission by itself.
Kearns also gives the example of an approval that people know is required even though the documentation does not say so, alongside the question of which spreadsheet actually contains reliable, current facts. These are not merely extra details to attach to an otherwise complete workflow. They change whether a move is ready.
Find the dependency that matters
Kearns explicitly includes reliable systems of record, process dependencies and the leverage points that contribute to an outcome. That changes the orchestration question from “What can the agent do?” to “Which available move matters most to the result?”
Those questions can produce very different answers.
If a workflow is waiting on a consequential approval, generating more downstream material may not advance it. If a decision depends on an unreliable input, executing the decision faster may only move the uncertainty further into the operation. Speed at the wrong node can leave the outcome unchanged.
The highest-value next move may therefore be resolving a missing approval or unreliable input rather than executing another automated step. The useful action might be a question, a reconciliation, or a request to the person who can settle the dependency. These are not lesser forms of orchestration. They are ways of making consequential work possible.
“Highest value” belongs to the business’s outcome and constraints, not to the agent’s repertoire. A move that looks impressive in isolation can be immaterial to the result. A small intervention at the actual constraint can matter more than a large amount of activity elsewhere.
This is the distinction between moving through a workflow and advancing the work. The first can be counted as steps. The second requires understanding what those steps make possible.
A blocked move is not a blocked business
Dependency awareness should not become a sophisticated reason to stop everything.
Where independent work is genuinely ready, uncertainty elsewhere should not become a reason to halt it. The word “independent” does real work here. Two activities are not independent merely because they have different names or appear in different parts of a diagram. They must be able to proceed without relying on the unresolved condition or making incompatible commitments.
The orchestration problem is therefore selective. Hold the move whose necessary condition is missing. Continue the work whose conditions are satisfied. Where resolving the missing condition is itself possible, treat that resolution as a candidate next move.
But the same authority test applies to resolving a dependency. A missing approval does not authorize an agent to supply the approval itself; it creates work to obtain a decision through the appropriate authority.
That distinction avoids two opposite failures. One is pressing ahead because the system can technically execute. The other is treating one unresolved question as a veto over every useful action. Dependency-ready orchestration rejects both.
AI-native means reconsidering the structure
There is a consequential difference between putting intelligence into an inherited workflow and designing the work around intelligence from the outset. In the first case, the workflow supplies the arrangement and AI improves selected steps. In the second, the governing outcome, legitimate constraints and decision dependencies become the basis for reconsidering the arrangement itself.
Kearns recognizes this distinction. He asks how business restructures when intelligence is placed in its foundation, and he explicitly contrasts inserting AI into human processes with making the processes AI processes from the beginning.
His transition starts with the existing operation: understand its context, merge with the way people work, then take over more of the work. He also criticizes the three-layer arrangement of hardcoded automation, humans and occasional model assistance as something short of the future he wants.
The distinction is therefore not between a source that sees only integration and an alternative that alone sees restructuring. It is between different routes into restructuring, and different choices about the authority and organization that restructuring should produce.
Forge’s desired direction is shared operating infrastructure that preserves participating operators’ businesses while redesigning how their work is coordinated. That direction calls for more than preserving the old process and adding an intelligent assistant. It calls for asking which dependencies actually serve the outcome, which decisions can be delegated, and which commitments must remain with the people and businesses entitled to make them.
An AI-native architecture should not treat every inherited step as an invariant. The outcome and legitimate constraints are the things to preserve; the sequence of work is something to examine against them.
There is a serious objection to any claim that this can begin on a clean sheet. Existing operations contain knowledge that a new design still has to learn. Starting from first principles does not make an undocumented approval, a consequential exception or a reliable source of facts disappear. Restructuring has to distinguish what the old arrangement happened to do from what the new arrangement genuinely must preserve.
That is why context and restructuring belong together. Context explains the conditions under which work succeeds. It need not turn every historical practice into a permanent instruction.
Governance must reach the commitment
Kearns describes governance policies and a distinction between deterministic decisions, model-handled decisions and human escalation. That is an important part of his account. The issue is not whether rules or humans appear in the design. The harder question is how those policies assign the right to commit resources across separate businesses.
A policy sandbox asks which action fits the company’s rules. Forge’s AI-native design should also ask how the outcome, dependencies, delegated authority and responsibility determine which action is ready to become a commitment. Governance then shapes the organization of work, rather than merely supervising a faster version of an inherited sequence.
A supplier recommendation, a production sequence and a resource commitment are related, but they are not interchangeable. An engine’s ability to recommend a supplier or sequence production is distinct from its authority to bind the businesses involved.
An orchestration model therefore needs to distinguish technical suitability, delegated authority and responsibility for the resulting commitment. “This is the best available supplier” answers a different question from “This business has authorized this purchase.” Neither, by itself, answers who must deal with the consequences if the choice is wrong.
The distinction becomes more consequential as the coordinating boundary expands. Inside one business, a decision can sit within an established chain of authority. Across businesses, the engine encounters several businesses’ commitments, constraints and decision rights. Better information can improve the recommendation. It does not, by itself, settle whose decision the recommendation becomes.
The useful design question is precise: what may this engine decide, for whom, under which conditions, and with whose responsibility attached?
Authority is not an ornament added after the intelligence works. In this account of orchestration, it is one of the conditions that makes an action ready.
The serious case for integration
Kearns’s envisioned progression leads from helping existing operators to coordinating a network and ultimately becoming an AI-native manufacturer with no single factory. The intelligence would help determine where production should happen, which resources should be used and how work should move through the network.
There is a serious argument for that integration: one coordinating intelligence could reduce the fragmentation that makes cross-business decisions slow. A network assembled from separate systems can leave each participant reasoning from only part of the situation. Bringing the relevant context together could make coordination more coherent.
The argument deserves more than a reflexive defense of the existing arrangement. If information fragmentation is the binding constraint, preserving every fragmented boundary unchanged would preserve part of the problem. A shared-infrastructure alternative that cannot resolve those handoffs could reproduce the coordination costs it is meant to reduce.
The challenge is real. Keeping businesses independent is not, on its own, an answer to how their work will fit together. The alternative has to carry the coordination, not merely object to the coordinator.
But the technical case for a better coordinating intelligence and the organizational case for the provider becoming the operator are separate arguments. Better coordination does not logically require the coordinating provider to operate every participating business.
Integration may be one way to organize the work. It is not the only conclusion that follows from the need to coordinate it.
Connect the decisions without absorbing the businesses
Shared infrastructure offers another organizing principle: connect the decisions while keeping participating operators’ businesses and decision rights intact.
The ambition is neither isolated businesses with no common operating context nor a coordinating system that treats access to context as permission to take over. It is an arrangement in which context can inform the network while authority remains explicit.
That arrangement still has to answer difficult questions. Preserving operator standing requires governance that specifies the decisions participants delegate, the responsibilities they retain and how cross-business commitments are made. Shared infrastructure does not make those questions disappear. It makes answering them part of the architecture of cooperation.
Preserving an operator’s standing is not the same as preserving every inherited workflow. Decision rights can remain explicit while the organization of work changes substantially. That is the important distinction for Forge: retain the businesses and their legitimate authority, while allowing shared intelligence to change how their work becomes ready, coordinated and consequential.
This is where the sticky note returns. The person who knows which mediator to avoid is contributing operational judgment, not merely feeding a database. An infrastructure that connects decisions should make that judgment usable without treating its capture as a transfer of every decision right attached to the business.
The distinction is not between intelligence and people. It is between using intelligence to strengthen an operator’s ability to act and using intelligence to reorganize who operates. Those are different choices, even when they begin with the same context.
Strengthening the operator can itself require restructuring the work. Independence need not mean keeping the old arrangement unchanged; AI-native need not mean transferring the business to the coordinating provider.
Judge the move by the outcome
The useful test is whether orchestration advances the outcome through a dependency-ready, authorized move—not how many actions it can generate.
When context is missing, the next move may be to obtain it. When an approval is missing, the next move may be to secure a decision. When independent work is ready, the next move may be to continue it. When a commitment crosses a business boundary, the next move must fit the authority that governs that commitment.
This is a more demanding standard than activity. It asks the system to understand the result, identify the consequential dependency, respect the people and businesses whose resources are at stake, and choose the useful move within those conditions.
The point of operational intelligence is not to produce motion everywhere. It is to make the next authorized move count.
As always, context is all.
Source note
Based on personal communication with Breyden Taylor and Sabeel Ahmed, retrieved October 6, 2026.