An agent demo usually fails in production at the seams. One agent delegates too early. Two workers edit the same record. A planner silently abandons a goal after a tool error. A supervisor keeps retrying work that no longer matters. Competent model calls can still produce an incoherent process.

Modern frameworks give these seams approachable names: handoffs, routers, supervisors, shared state, memory, workflow graphs. Those primitives are useful, but their labels can make a system feel more specified than it is. A handoff says that control moved. It does not say why the recipient was eligible, what it committed to do, or who now owns the result.

These are old coordination problems. Contract Net described negotiated task allocation in 1980. Hayes-Roth’s blackboard architecture separated shared domain knowledge from the control problem in 1985. Malone and Crowston organized coordination around dependencies among activities in 1994. Rao and Georgeff formalized the role of beliefs, desires, and intentions in 1995.

A framework primitive and a coordination design answer different questions. Current documentation confirms the vocabulary: OpenAI describes a handoff as delegation to another agent, while LangGraph’s StateGraph has nodes communicate by reading and writing shared state. Neither label, on its own, determines the operating contract for a particular business process. Some frameworks provide additional controls, but teams still have to configure them for the process at hand.

Classical patternCurrent labelThe design contract still requiredContract NetBlackboardBDICoordinationtheoryHandoffs, routers,supervisorsShared state, memory,workspaceState, goals, plansWorkflow graphs anddependenciesAnnouncement and eligibilityBidding and awardResponsibility after delegationActivation conditions and schedulingSeparation of domain statefrom control stateDurable intentionsExplicit reconsideration rulesClassify the dependency firstChoose the coordinationmechanism second
Figure 1 Classical pattern, current framework label, and the design contract that a framework primitive does not provide on its own.

Delegation Needs Selection and Responsibility

A router often chooses the next agent from a rule, a classifier, or a model-generated tool call. That is enough when one specialist is obviously responsible. It is not enough when several workers could perform the task, their availability changes, or the cost of a poor assignment is high.

Smith’s Contract Net protocol treats delegation as negotiation. A manager announces a task. The announcement includes eligibility requirements, a description of the information expected in a bid, and an expiry time. Eligible nodes evaluate the task against their local situation and submit bids. The manager evaluates those bids using criteria specific to the task, then awards a contract. The contractor executes it and reports results. Manager and contractor are roles created by the negotiation, not permanent positions in an organization chart.

That sequence makes several decisions explicit:

  1. Announcement: What work is available, and what context may candidates inspect?
  2. Eligibility: Which workers are allowed to attempt it?
  3. Bidding: What evidence of fit, capacity, or expected cost must they return?
  4. Award: Which criterion decides among acceptable candidates?
  5. Responsibility: Who monitors progress, accepts the result, retries the task, or decomposes it again?

A current handoff API can implement the transfer. It does not necessarily implement this selection process. OpenAI’s documentation, for example, models a handoff as a tool exposed to an agent and allows structured metadata to accompany it. That is a clean runtime primitive. The application still has to decide whether the model may choose any recipient, whether a policy constrains the choice, and what happens when the recipient cannot fulfill the request.

Task assignment is also an accountability boundary. Consider an agent that escalates a refund request. If the handoff records only the next agent name, an audit can show where control went but not why that agent was authorized, which facts shaped the decision, or whether the receiving agent accepted responsibility. The system needs a delegation contract, not another prompt.

Contract Net carries costs. Bidding adds messages, latency, and decision logic. A fixed route is simpler when the dependency is stable and the owner is unambiguous. Dynamic assignment needs explicit announcement, eligibility, selection, and responsibility. A successful tool call covers only the transfer.

Shared State Needs a Control Model

Putting every agent behind the same state object solves an access problem. It does not solve the control problem: who may act next, which changes should wake which workers, and whether a new fact invalidates work already scheduled.

The 1985 blackboard architecture explicitly distinguishes domain and control problems, knowledge, and solutions. Hayes-Roth’s accessible primary treatment, Intelligent Control, shows what that distinction means operationally. Domain specialists contribute to a common memory. Changes create events. An agenda manager identifies actions whose triggering conditions are satisfied. A scheduler rates those actions against a control plan and selects what to execute next. The control plan itself can change as the system learns more about the problem.

The architecture is richer than “agents share a workspace.” It separates at least three concerns:

  • Domain state: facts, hypotheses, partial outputs, and their relationships.
  • Activation: the conditions under which a specialist becomes relevant.
  • Control state: priorities, scheduling decisions, and the strategy for choosing the next action.

A shared-state graph can host all three. LangGraph’s StateGraph defines nodes that communicate by reading shared state and writing partial updates. That says how data moves through the graph. An application still decides whether a write represents a durable fact, an unverified hypothesis, a pending action, or a control signal. It also decides which node becomes runnable and how concurrent updates are reconciled.

Mixing domain and control state is a common source of opaque behavior. Suppose a research agent writes “supplier approved” into the same object that stores “approval review scheduled.” A downstream purchasing agent may interpret either field as permission to act unless the state model gives them different types and transition rules. More memory will not repair that ambiguity. The state needs semantics.

Recent research shows that the blackboard remains a live design option, not merely a historical metaphor. A modern blackboard study describes a central workspace where requests are posted, agents volunteer according to their capabilities, and a coordinator can allocate work without hard-coding every capability in advance. The result does not prove that a blackboard beats every graph or supervisor. It demonstrates that explicit posting, activation, and allocation rules can still structure model-based collaboration.

The procurement question is therefore not “Does the platform have memory?” It is “What does a state change mean, which conditions does it activate, and what control policy chooses among the activated actions?” A demo of several agents reading the same document answers none of those questions.

A Goal Is Not a Commitment

Many agent systems have fields called goals and plans. BDI’s important contribution is the relationship between deliberation and commitment, rather than the vocabulary.

In Rao and Georgeff’s BDI treatment, beliefs represent the agent’s informational state, desires its motivational state, and intentions its chosen course of action. An intention constrains later deliberation. Without that constraint, an agent can repeatedly reopen a decision whenever new information arrives. With unconditional commitment, it can keep pursuing a plan after the reason for the plan has disappeared. The design problem is to choose when reconsideration is justified.

A common implementation gap appears when storing a goal string is expected to make the goal durable. If each model turn receives the current state and freely chooses a new plan, the system has desires and repeated deliberation, but no defined intention policy. It may switch suppliers after approval, abandon a support escalation halfway through, or keep a cancelled task alive because an old message remains in context.

An operational commitment policy should answer four questions:

  • What event creates an intention rather than a tentative option?
  • What evidence counts as progress toward it?
  • Which conditions justify reconsidering or dropping it?
  • Who is authorized to make that change?

Those rules need not reproduce a formal BDI interpreter. They can be ordinary state transitions with guards, timestamps, owners, and audit records. The classical model contributes a design distinction: a goal is something the system may want, while an intention is a course it has selected and will not casually discard.

Long-running business processes expose the stakes. A customer-service agent can improvise wording on every turn. It should not improvise whether a promised replacement is still being sent. Once the process creates an external obligation, persistence and reconsideration become product requirements rather than prompt-engineering details.

Draw Dependencies Before Agents

Agent diagrams tend to begin with roles: researcher, planner, reviewer, writer. Coordination theory starts one level lower. Malone and Crowston define coordination as managing dependencies among activities, then examine mechanisms for handling different dependency types.

Their examples include shared resources, producer-consumer relationships, simultaneity constraints, and task-subtask relationships. Those dependencies lead to different mechanisms. Shared resources may require allocation. A producer-consumer dependency may require sequencing, notification, and tracking. Simultaneous activities need synchronization. A task-subtask relationship needs goal decomposition and result integration.

Map the dependencies before drawing a graph around the framework’s available nodes:

  • Does one activity require another activity’s output?
  • Can several activities claim the same scarce resource or external side effect?
  • Must results arrive in a particular order or at the same time?
  • Is the work a decomposition of one goal, or several independent goals sharing context?
  • Can failure remain local, or does it invalidate downstream work?

Only then choose a mechanism. A deterministic edge may be enough for a prerequisite. A queue and lease may protect a shared resource. A contract-like assignment may fit dynamic ownership. A blackboard may fit opportunistic contributions to an evolving solution. A human approval gate may be the only acceptable mechanism for a consequential side effect.

Workflow graphs make dependencies visible, which is valuable. They do not classify those dependencies for you. Two arrows can look identical while one means “wait for data” and the other means “do not proceed without authorization.” If the implementation represents both as the same state transition, the diagram hides the most important business rule.

What the LLM Made Cheap

Large language models changed the economics of the workers inside these structures. A single general model can interpret an announcement, assess rough eligibility, produce a bid, synthesize shared evidence, or propose a plan without a bespoke symbolic component for every domain. Natural-language interfaces also make it cheaper to add a specialist and to translate between heterogeneous tools.

That flexibility explains why handoffs, supervisors, shared memory, and graph workflows are productive abstractions. A 2026 survey of agentic AI provides a current map of the broader field and its terminology. The historical comparison should not be read as a demand to replace modern frameworks with old software architectures.

What became cheaper was generating and interpreting candidate actions. The cost of an underspecified coordination rule did not disappear. In some settings it increased because a model can produce a plausible action outside the path its designers anticipated. The runtime needs to distinguish what the model may propose from what the system may commit, schedule, or execute.

Each additional agent creates more possible assignments, more shared-state writes, more commitments, and more dependencies. Reliability can decline even when the added agent performs its local task well. The model supplies flexible judgment within those boundaries. The system must encode the boundaries elsewhere too.

Questions for an Orchestration Review

A buyer does not need a lecture on distributed artificial intelligence. They do need precise answers about the business process entrusted to the system. Before approving an orchestration design, ask for these artifacts and decisions:

  1. A dependency map. Each edge should say whether it represents data flow, ordering, shared-resource contention, authorization, decomposition, or result integration.
  2. A delegation contract. For dynamic assignments, document the announcement, eligibility rule, candidate evidence, award rule, expiry behavior, and owner after transfer.
  3. A state model. Separate durable facts, model hypotheses, pending work, permissions, and control signals. Define who can write each category and how conflicts resolve.
  4. An activation and scheduling policy. State what makes work runnable, how competing actions are prioritized, and what prevents duplicate or stale execution.
  5. A commitment policy. Identify when a proposed goal becomes an intention, what progress means, and which events permit reconsideration, cancellation, or escalation.
  6. A side-effect boundary. Mark where the system can spend money, contact a person, change a customer record, or create another external obligation. Define the required authorization at each boundary.
  7. A failure ownership model. Name who detects timeouts, rejects incomplete results, retries safely, compensates for partial effects, and reports unresolved work.
  8. An audit narrative. For a completed case, the system should reconstruct why work was assigned, which facts and policies governed it, when commitments changed, and who authorized consequential actions.

Framework selection comes after these answers. A supervisor architecture may be appropriate when control should remain centralized. A shared workspace may be appropriate when specialists contribute opportunistically. A fixed workflow may be appropriate when the dependency structure is stable and auditability matters more than open-ended adaptation. None is a maturity level above the others.

The strongest vendor answer connects a framework feature to a named process obligation: this handoff enforces eligibility, this state transition records acceptance, this scheduler prevents two workers from claiming the same side effect, this reconsideration rule stops a cancelled goal. “The model decides” is not equivalent evidence.

An agentic systems design review should produce those answers before implementation begins. The framework can then supply runtime primitives against an explicit process contract, with the model used where flexible judgment is actually valuable.