In 1913, the moving assembly line arrived at Highland Park, Michigan. Ford Motor Company did not invent manufacturing, but it perfected sequence. Every chassis moved forward along a designed path. Each worker performed a defined task. The order was fixed. The rhythm was measured. And, if every station did its part, a finished automobile emerged at the end.
The line was efficient because it assumed stability. Variation was an interruption, not a condition of operation. The car model would not change midstream. The tooling would remain constant. When something had to change, the entire production line stopped. Engineers reconfigured stations. Equipment was updated. Only after the redesign was complete and fully tested did production resume, along a new path.
Nothing about the assembly line was accidental. The path was authored before the work began, and execution meant following it.
In the 1840s, families gathered in Independence, Missouri to start a new life. It was there that families and adventurers would gather to join the wagon train west along the Oregon Trail that stretched from the Missouri River to the Pacific.
The destination was clear enough. The route was not. Rivers shifted. Severe weather caused delays. Wheel hubs broke. Trails forked and disappeared into grass. But no one could stop the continent to retool the terrain. Decisions were made at the edge of the present tense. On the frontier, change did not pause the journey. It simply redirected it. Progress meant adapting to change along the way.
Factories reward sequence. Frontiers reward adjustment.
For a century, we have built most of our digital systems like factories. We define the steps. We model the flow. We encode the dependencies. Even when we insert an LLM into the middle of the loop, the structure remains centralized. A planner selects a tool. The tool runs. The result feeds the next decision.
That is orchestration.
Navigation begins somewhere else. It begins with a goal and an environment that pushes back.
Orchestration or Navigation
Most of what is being built today is orchestration augmented by improved heuristics.
A planner selects a tool. The tool runs. The output becomes input to the next action. The graph branches. The system advances. It may look dynamic, but the dependency structure is still centralized. The intelligence lives in the static control logic.
This is the intellectual descendant of:
Business Process Model and Notation (BPMN)
Business Process Execution Language (BPEL)
Directed Acyclic Graph engines (DAG)
Arazzo Specification
Even when an LLM sits at the center choosing tools, the structure remains authored in advance. We are still drawing the map before the journey begins. And we’re building “runners” that are created to simply travel the path laid out for them, without variation.
That is orchestration.
Orchestration starts with the plan
Orchestration is excellent inside bounded environments.
If service capabilities are known, constraints are defined and stable, and the operating surface is curated to meet the needs of a particular outcome, then pre-set sequencing works. Pipelines are predictable. DAG engines are efficient. BPM systems are auditable. There is a reason enterprises have relied on them for decades.
In closed systems, dependency modeling pays off. But orchestration assumes something critical: the designer knows all the edges of the graph ahead of time.
Orchestration models begin to break down when sequences shift frequently, when capabilities evolve independently, and when no single designer can see the full graph at once.
Navigation begins with a goal
Navigation systems invert the starting point. Instead of modeling the path, they model the destination.
Classic AI planning research understood this well:
STRIPS
Hierarchical Task Network (HTN)
Goal-Oriented Action Planning (GOAP)
Belief-Desire-Intention model (BDI)
More recently, systems like GRAIL push this further into distributed environments.
The pattern is simple and a bit subversive.
Attempt the end goal first.
If blocked, expose the constraint.
Shift attention to what must change.
Retry.
The client does not follow a script. It negotiates obstacles it encounters in the environment. The path is not authored. It is discovered, step by step.
Some modern models push this further by shifting part of the planning burden to the environment itself. The agent attempts a goal. Services respond not just with success or failure, but with predicates that describe what blocks progress. Those predicates become new targets.
In these models, the graph truly does not exist until the goal is attempted. The path emerges from the interaction between agent and ecosystem.
This is navigation across independent systems, not just inside a planner.
Dependency traces versus execution traces
In orchestration, we think in dependency traces. We sketch the graph on an ideal plane. Every branch is pre-imagined. Every edge is defined. The system moves through a structure that exists before execution.
In navigation, we think in execution traces. We begin in the world as it is. We try something. The environment responds. The next step emerges from the exposed constraints.
This is not simply a modeling difference. It is a cognitive difference. Dependency thinking compresses the future into a canonical workflow. Execution thinking preserves branching until the last responsible moment.
In stable systems, collapsing the space is efficient. In evolving systems, collapsing the space prematurely removes optionality.
Navigation inside a box
It is worth noting that navigation is no longer theoretical. Several modern agent frameworks implement goal loops and dynamic replanning. They define actions, preconditions, and goals. They assemble plans at runtime. They retry when blocked.
This is real progress.
But most of these systems still operate inside a bounded capability universe. The action set is registered in advance. The planner knows the available tools. The graph may be dynamic, but it is still curated.
This is navigation inside a box. It is not orchestration. It is a meaningful step forward.
But it is still different from navigating across an open ecosystem where capabilities appear independently, constraints shift without coordination, and no single authority owns the graph.
Bounded navigation shows dynamic planning works. Open navigation requires ecosystems expose constraints clearly. Open ecosystems create precisely this pressure.
When no one owns the graph
Open, distributed systems introduce two forces that orchestration does not handle gracefully: independent capability evolution and independent constraint evolution.
A new service becomes available. A policy changes. A resource limit tightens. A pricing rule shifts. These changes do not propagate from a central authority. They happen because independent members of the ecosystem make their own local modifications.
In orchestration, each of these shifts requires revisiting and likely modifying the pre-defined plan.
In navigation, each shift is simply another condition encountered and dealt with at runtime. Navigation scales because it localizes decision making. The system only needs to understand what blocks the goal right now. It does not need to “see” the entire ecosystem all at once.
This is the same logic that makes hypermedia powerful. The next possible actions are exposed in the context of the last action executed. The client does not need the entire workflow. It needs the current affordances. And the details of those affordances can change at any time.
Choosing the right model
The difference between orchestration and navigation is important. This is not an “either-or” choice, it is a classic trade-off. When designing a system where multiple capabilities are involved, it makes sense to ask:
Who controls the graph?
How often do constraints change?
Can change be scheduled, or does it emerge at runtime?
If a single authority owns the capability graph, constraints are stable, and change can be coordinated, orchestration remains efficient. If capabilities evolve independently, constraints surface unpredictably, and no single designer can see the whole graph, navigation becomes necessary.
The architecture should reflect the terrain.
Architecting for navigation
If we want agents that operate beyond curated static environments, design priorities shift: We need to stop encoding workflows.
Instead, we should start exposing:
Goals as first class affordances.
Preconditions as machine readable constraints.
Effects as observable state transitions.
Retry surfaces that make blocked goals explicit.
Instead of telling the agent what to do next, we let the environment say what is possible next and allow the local intelligence of the agent to deal with it.
This suggests a constraint-driven design model that is still largely missing from today’s agent architectures.
The difference mirrors an older divide in computing.
Early workflow systems resembled factory lines. Each station had a defined role. Material moved along a belt.
Navigation resembles exploration. You move until you encounter resistance. You adjust. You proceed.
Factories require stability.
Exploration assumes change.
Recognizing the terrain
Assembly lines changed the world. They enabled consistency and efficiency at scale. They thrive where the path is stable and variation is rare.
Frontiers demand something else. They reward systems that adapt without stopping. They depend on skilled problem-solvers who can read the terrain.
For decades, most of our software lived inside factories. Workflows were bounded. Capabilities were known. Change could be scheduled.
Today, many of the systems we build operate across organizational boundaries. Services evolve independently. Policies shift without coordination. Constraints can surface at runtime.
AI and agentic systems are finally capable of operating in that variable landscape. Not by precomputing every step, but by responding to conditions as they appear.
The discipline now is not choosing a side. It is learning to recognize the terrain.
If capabilities are centralized, constraints are stable, and variation is rare, build the assembly line. Model the workflow. Optimize the sequence. Design agents to execute precisely and minimize variation.
If capabilities evolve independently, constraints emerge at runtime, and no single authority controls the graph,then design for navigation. Start with the goal. Expose preconditions. Let the path be discovered. Design agents that can evaluate available affordances and select among them at runtime.
There is a time to build the factory and a time to cross the continent. Good engineering begins by knowing which landscape you are standing in.
