Two lanes for agent orchestration

Twelve months ago, the pitch was reuse.

Build agent workflows on a shared platform. Orchestrate multi-step flows. Standardise prompts. Ship faster because the plumbing is already there. That value proposition was real. It still is, for the right class of problem.

What changed is which problems deserve AI in the first place.

When deterministic flows hit a ceiling

On a recent agent platform programme, much of the early work sat in deterministic orchestration. Known steps. Known hand-offs. Known approvals. My job was to support the overall flow and make sure agents fit the architecture.

The honest friction was value. Many of these processes were already optimised. The business could already audit them. Internal audit liked them. Operations trusted them. So the recurring question was not can we automate this? but why bother?

If the flow is mature, AI becomes a cost line with a governance tax. Unless you can point to a step that is genuinely expensive, error-prone, or slow, deterministic agent wrappers struggle to earn their place. You are decorating a highway that already has toll tags.

That is not an argument against platforms. It is an argument against using the platform as a fancy macro runner and calling it transformation.

The non-deterministic shift

Coding agents changed the conversation.

Give a capable model a goal, tools, and a loop. Let it try, fail, adjust, and try again. The value is not follow these twelve steps. The value is find a path to the outcome within guardrails. Open options. Clear objective. Bounded authority.

Enterprise programmes are moving the same direction. Less spec-driven prompt engineering. More loop engineering. Less “write the whole solution.” More write a skill that other agents can call, assess, and reuse around the clock.

That is a different proposition from last year’s deck. Then we talked about workflow templates on a platform. Now we talk about squads of agents with role-based access, data boundaries, tool policies, and an orchestration layer that can route work to the right model at the right cost.

The core promise of AI finally shows up in plain language. You describe the need. You set the goal. The system iterates until it gets there or hits a control.

Governance is the product

None of that works without a serious middle layer.

I see three leaks in almost every mature conversation right now.

Token spend. Teams default to the most expensive model for every task because routing feels risky. Nobody owns the cost curve. Finance hears “AI” and sees a hose, not a dial.

Tool access. Agents that can touch legacy systems, email, ERP, ticketing, or customer data need the same seriousness as a human service account. Except humans sleep. Agents do not.

Cross-company movement. Data classification, residency, segregation of duties, and audit expectations were built for predictable software. Agents are not predictable software.

So the orchestration and governance layer is not a slide at the end of architecture week. It is the product. AI gateway, policy, observability, model routing, skill registry, squad permissions. That is what makes non-deterministic work safe enough to scale.

The business mind switch

The harder part is not cyber or infrastructure. It is stakeholders.

Business leaders were trained on deterministic comfort. Flowcharts. Audit trails. Repeatable outcomes. A demo where the agent takes a different path on Tuesday than Monday feels like a defect, not a feature.

I do not think you win that argument by telling people to “embrace ambiguity.” You win it by showing two lanes on the same platform.

Lane one: the fast lane

Deterministic flows for processes that are mature, regulated, and already trusted. Transparent. Observable. Easy to sign off. This is where you answer why automate at all? with cost, speed, or quality at a specific step.

Lane two: the agent lane

Governed non-deterministic squads for domains that benefit from exploration. Research, drafting, analysis, code, operations triage, use-case discovery. The agent may loop. The platform still logs every tool call, every model choice, every skill version, every escalation.

Same gateway. Same identity model. Same policy engine. Different tolerance for variation in the middle, same demand for evidence at the edge.

That framing helps risk and audit too. You are not replacing controls. You are classifying work by how much autonomy it may earn.

Skills beat monoliths

The practical pattern I like right now is small and reusable.

A business owner describes a use case in conversation. A squad prototypes it in a loop. The output is not only an answer. It is a skill you can review, version, and attach to other agents. Assessed once. Used many times. Available when the human team is not.

That is where the boost is showing up in the field. Not another one-off chatbot. A compounding library of governed capabilities that agents share.

It also gives procurement and compliance something concrete. You are not buying magic. You are approving named skills with owners, scopes, and retirement dates.

What I would design in next

If I were sketching the next revision of a client-owned agent platform, I would insist on five platform decisions up front.

Two-lane intake. Every use case declares deterministic or agent-lane before funding. No lane, no build.
Model routing as policy. Task type, data sensitivity, and budget tier pick the model. Not the developer’s mood.
Tool contracts. Each tool gets identity, rate limits, allowed squads, and logging. No anonymous agent access to production.
Skill lifecycle. Draft, assess, publish, deprecate. Same discipline as APIs, because that is what they are.
Stakeholder narrative. One page for audit on what “non-deterministic with controls” means. Reuse it until people stop asking for a flowchart of the agent’s thoughts.

The technology shift from deterministic orchestration to agent loops is not a rebranding exercise. It is a value shift. The platform either enables both modes safely, or it becomes shelfware with excellent diagrams.

The organisations that get this right will not argue about whether agents are “too random.” They will argue about which goals are worth a loop, and whether the governance layer is strong enough to let those loops run while everyone else sleeps.

Field note from the build-in-public log. NDA-safe, no client names, rounded figures only. If this matches what you are seeing, get in touch.