Agent Orchestration Is Product Infrastructure

An agent can finish a task and still be the wrong system to trust in production.

Completion tells us that a run stopped. It does not tell us whether the agent had the right context, used an authorized tool, verified its result, waited for the right approval, or changed anything a customer actually needed.

That distinction is becoming easier to see in the design of agent platforms. On October 1, 2026, GitHub announced Dynamic Workflows for Copilot CLI and the Copilot app. The workflows are programs: they define stages, combine deterministic operations with agent judgment, run work in sequence or in parallel, pass results between stages, and can pause at a review checkpoint. GitHub’s documentation describes the feature as being in public preview.

The useful shift is not simply that more agents can work at once. It is that orchestration can become an inspectable part of the product.

“The agent ran” is easy to count. It is also a weak product metric.

A run might have searched the wrong source, acted on stale data, retried a non-idempotent operation, or produced an answer that no one used. A successful status can hide all of those cases. Even a correct final answer may have come through an unsafe path.

For web products and analytics, the meaningful question is what changed for the person using the system. Did the requested report become accurate and current? Did a proposed code change pass review and reach its intended state? Did a support action resolve the issue without an unauthorized write? Those outcomes require evidence from more than the final model response.

A workflow gives the team a stable place to define what happens around model reasoning. The agents may investigate or make judgments; the workflow can specify the stages, allowed handoffs, checks, and places where a person must decide.

I would trace each run across a small set of explicit transitions:

1. Context: What request, data scope, and source versions informed the run?
2. Action: Which actor called which tool, with what bounded authority?
3. Verification: What evidence supported the result, and what remained uncertain?
4. Approval: Who or what approved the next consequential step, and against which artifact?
5. Outcome: What state changed, and how was that result confirmed?

Each event needs a stable run identifier, workflow version, stage, actor, timestamp, and references to the relevant artifacts. Tool inputs and outputs should be represented with enough detail to reconstruct a decision, while sensitive content stays governed by the product’s privacy and retention rules. A pointer to a versioned report, diff, or query result is often more useful than copying an entire prompt into a log.

Structured handoffs help make these transitions reviewable. A downstream step can receive a typed finding with its evidence, scope, and uncertainty instead of an unstructured paragraph that silently drops important context. A second agent can challenge that finding, but the system should record what it checked and where it disagreed. “Verified by another agent” is a step in the process, not proof by itself.

This is the same reason observability should connect signals to decisions: logs, metrics, and traces need shared context and a clear action at the end.

A human checkpoint is valuable when the reviewer can see the proposed action, its scope, supporting evidence, and likely consequences before the system continues. For a production write, that may mean showing the exact fields that will change, the resource being changed, and the recovery path if the action is wrong.

The gate should be enforced by the workflow runtime or the product’s authorization layer. A sentence in a prompt asking the agent to “wait for approval” is not a control if the agent can choose to ignore it.

Permissions also need to be visible. GitHub’s documentation says workflow subagents inherit the permission grants of the session that started them, while extension code can run outside those permission prompts. That means reviewing an agent’s response is not enough: teams need to inspect the workflow code, the tools it can call, and the authority those tools carry. The checkpoint should be attached to a specific action and artifact, so the approval record remains meaningful after the run finishes.

For higher-risk changes, an approval policy should include an accountable owner and an exception path. When the workflow lacks context or encounters an unexpected state, it should pause or escalate instead of turning uncertainty into confident completion.

Once the workflow is observable, its metrics can describe product reliability rather than agent activity. I would start with:

• the share of eligible requests that reach a verified, user-relevant outcome;
• policy violations and actions that exceeded their declared scope;
• unresolved or escalated runs, including why they stopped;
• time spent waiting for approval as well as execution time;
• recovery time after a failed or paused run;
• and downstream corrections, reversals, or support contacts.

The denominator matters. If difficult requests are silently excluded, a high completion rate says little. Human approval rate also needs context: frequent approvals may indicate a healthy control for consequential actions, or a workflow that creates too much review work. The metric should help us understand the product, not reward an agent for moving quickly through its gates.

These measures connect naturally to workflow objectives such as correctness, safety, latency, and recovery. I have written more about that in reliable agents need workflow SLOs. The important step is connecting those engineering signals to the outcome the user recognizes.

Prompts, models, and agent strategies will keep changing. The workflow can provide a more durable contract: which context is allowed, which actions are possible, what must be verified, where approval is required, and what counts as success.

Dynamic workflows are one current example of making orchestration explicit. They do not make an agent safe or correct by themselves, and a public-preview feature should be evaluated within its current limits. They do make it easier to ask a better production question: can we reconstruct how the system moved from context to action, approval, and outcome?

Treating orchestration as product infrastructure means designing that path, instrumenting it, and showing its guarantees to the people who rely on it. The agent’s completion status can remain one event in the trace. It should not stand in for the result.

Before an agent acts in production, what would you make observable?