Introducing Orchestrations: The Layer That Carries a Ticket from Reported to Shipped

Today we get to share something we have been building alongside our customers for a while, and we are genuinely excited about this one. Orchestrations are live. This is the most significant thing we have shipped since workflows themselves, because it changes the unit Overcut works in: from a task an agent completes to a journey a fleet of agents carries from reported to shipped.

Every team we work with follows the same arc. First a single workflow earns trust: triage that turns a raw bug report into a scoped ticket, RCA that finds the offending change, a coding workflow that opens the fix PR. Then the workflows start talking to each other. Triage finishes by putting a needs-rca label on the ticket, a trigger sees the label, and RCA fires without anyone touching anything. Chains like that run real production journeys today, and watching them work is what convinced us of the next step.

Because once the chain works, your ambitions for it grow. You want the journey itself to be something you can see in one place, instead of reconstructing it from scattered triggers and label conventions across runs that do not know they are related. You want workflows to stay independent, rather than each one carrying hardcoded knowledge of whatever runs downstream. And you want the journey to move in more than one direction, so that a review result which deserves a second RCA pass can arrange one, informed by everything learned since, without a person re-triggering workflows by hand. Label chaining carried our customers a long way. It also has a ceiling, and the most advanced teams were starting to press against it.

Orchestrations are that next step. The journey gets pulled out of the workflows and given a first-class home. Defined in a paragraph, routed by AI, bounded by the engine, supervised by a built-in agent, gated by humans, recorded end to end. This post covers what an orchestration is, the design decisions behind it, one decision we reversed during review, and where it goes next.

Key Takeaways

• An orchestration is defined by intent, a prose goal plus a closed set of allowed workflows, rather than a flowchart. AI decides the route at runtime, and the engine records every step.
• Bounds are enforced by the orchestrator, never by prompts. Allowed workflows, step caps, and human gates are checked in one code path that every route passes through, so violations are impossible rather than unlikely.
• Human approval is not a bolt-on. Every step promotion is a recorded decision, and the approval inbox is simply the set of decisions still pending.
• Working agents never see the orchestration's goal. That reversal, made during design review, is what keeps a workflow inside an orchestration behaving exactly like the same workflow run standalone.

What We Shipped

An orchestration definition is deliberately thin. You write a goal in plain prose, at least a sentence or two describing what "done" means for the item being tracked. You pick the workflows the orchestration is allowed to invoke. Optionally you add routing instructions, human approval gates on specific workflows or on completion, and limits. That is the whole authoring surface. There is no pipeline canvas to wire up, no phase graph, no transition table, and no label conventions tying one workflow's ending to another workflow's trigger.

At runtime, an entry trigger, a new issue, a pull request event, or a manual start, creates an instance: one ticket, one journey. From there the instance moves in a loop. A workflow runs and reports back a structured result: a verdict on whether its own job succeeded, a summary that becomes part of the record, and usually a proposal for what should happen next, with a rationale and a confidence score. That proposal becomes a decision. Rules resolve the easy ones instantly. A built-in supervisor agent reasons about the ambiguous ones. Humans resolve anything gated. Once a decision is approved, the engine checks it against the definition's bounds and starts the next workflow. When a completion proposal passes its gate, the instance is done.

During the design phase, one principle ended up settling most of the arguments we had about scope: the flow is a record, not a plan. You do not draw the path a ticket will take ahead of time. You state the destination and the vehicles, and the system writes down the path actually taken, every proposal, every rejection, every human override, as it happens.

In the vocabulary that has settled around agents this year, an orchestration is how you run a fleet of agents against a single item of work. Each workflow is a specialized agent doing one job with fresh context. The supervisor is the coordinator keeping the fleet pointed at the goal. The gates are the human-in-the-loop checkpoints, and the definition's bounds are the guardrails that make the autonomy bounded in fact rather than in marketing. The shape is the multi-agent orchestration pattern the industry has converged on, with one opinionated addition: the coordination itself leaves a record you can audit.

A Ticket, End to End

Here is what that looks like on a real bug. A customer files an issue. The orchestration's entry trigger matches, an instance is created, and the first workflow, triage, runs. It reports that it reproduced the bug and scoped it, and proposes routing to RCA with high confidence. The proposal is not gated and the confidence clears the auto-approve threshold, which defaults to 0.8, so a rule resolves it without waking anyone. RCA runs, identifies the commit that introduced the regression, and proposes the fix workflow.

The fix workflow is gated, because this team wants a human to approve anything that writes code. The instance parks in a waiting state and the question surfaces on the ticket itself. An engineer replies in a comment, the supervisor reads the reply and resolves the decision on the commenter's behalf, and the fix workflow starts. It opens a PR. From that moment, activity on the PR flows into the same instance: review comments, the merge event, all of it routed to the journey the item already belongs to rather than firing disconnected standalone workflows. After the merge, a completion proposal goes to the completion gate, a human confirms, and the instance closes as Completed.

Nobody routed that ticket. But at every point, someone could have. Comment on the ticket and the supervisor picks it up, re-routes, answers questions, or cancels. Going backward is the same motion as going forward: if the review turns up evidence that the root cause was wrong, the next proposal can be RCA again, carrying everything learned since its first run in the case file, where the old label mechanism would have needed a person to re-trigger workflows by hand and paste context between them. And the whole path is queryable afterward: which workflows ran, what each one concluded, who approved what, and why. Across many tickets, the aggregate view is a board where the columns are the allowed workflows and the cards are instances, which gives an engineering lead the answer to "where is everything?" without asking anyone.

How We Use It Ourselves

We would not ship an autonomy feature we do not run on our own backlog, so here are the two orchestrations working inside Overcut today.

The first is our ticket to PR delivery orchestration. It listens for every newly opened issue, and its goal is to take each ticket from initial triage through the appropriate analysis path and keep going until a pull request exists. Five workflows make up its allowed set: ticket triage, root cause analysis, requirements generation, technical design, and PR creation. The routing instructions read like something you would tell a new team lead: triage everything first, send feature work through requirements and design before implementation, send bug work through RCA and proceed once it produces a concrete fix direction, and pause rather than force progress when information is missing or confidence is low. We tuned its bounds tighter than the defaults, ten steps per instance and each workflow at most twice, and we placed a single gate, approve-design, directly in front of the PR creation workflow. Agents triage, analyze, and design freely; a human signs off on the design before any code gets written. The gate has a discussion agent attached, so that sign-off can be a conversation on the ticket, with the agent able to pull up what earlier steps concluded, rather than a bare yes or no.

The second, our PR review loop, picks up exactly where the first one stops. Every opened or edited pull request enters, and six workflows carry it: PR description, code review, comment validation, comment fixing, re-review, and final approval. This orchestration exists for the motion that used to be hardest, the loop. Review, validate whether the comments genuinely require changes, fix, re-review, and around again until the PR is validated ready, with any single workflow capped at three runs so the cycle can never spin forever. And it is gated precisely where it counts: the fix workflow, the only one that rewrites code, waits for a human's approval before it starts.

Here is that loop finishing on a real pull request in our repo. The re-review summary reports what was resolved and flags one remaining concern, the author replies "approve without it" in a plain GitHub comment, and the loop carries out that decision and files the final approval.

Chained end to end, the two orchestrations mean a ticket filed against Overcut can travel from a fresh report to a merge-ready pull request with humans making exactly three calls along the way: approving the design, approving the fix, and merging the result.

Why There Is No Pipeline Builder

The obvious way to build this feature was a visual workflow-of-workflows: a graph editor where you draw phases and transitions. We wrote that design down and rejected it, for three reasons. Authoring cost is high, because encoding every edge case of a real engineering journey into explicit transitions takes weeks and the result is brittle the first time reality deviates. It is also a commodity. Every workflow engine of the last two decades has a graph builder, and none of that machinery is where the value lives anymore. Routing decisions of the form "given this RCA result, what next?" are exactly what large models are good at, so hand-authoring transition tables duplicates the model's strength in a worse medium.

So we made the routing dynamic and accepted the trade with open eyes: setup cost collapses to writing a paragraph and picking workflows, and predictability decreases. Most of the rest of the design is about paying that predictability back. We also wrote down the condition under which we would revisit the call: if telemetry shows humans overriding the router at a high rate, a hybrid with explicit structure goes back on the table. We think the paragraph will beat the graph, but we would rather measure than argue.

Prompts Guide, the Orchestrator Enforces

Dynamic routing is only tolerable if the boundaries around it are hard. This is where we hold one of our strongest opinions: prompt compliance is probabilistic, and "the AI ignored its instructions" is not an acceptable failure mode for a feature whose pitch is bounded autonomy.

So none of the safety properties live in prompts. The allowed workflow set is a closed list, and it does triple duty: it is the safety boundary the router cannot leave, the vocabulary the supervisor reasons in, and the columns of the board. Every step start in the entire module flows through a single promotion path, and that path re-checks everything against the definition: is the proposed workflow in the allowed set, is the step cap respected, has this workflow hit its repeat limit, does this target require human consent that has actually been given. The defaults are conservative, 20 steps per instance, 3 repeats of any one workflow, 25 concurrent instances, a 24-hour idle timeout, because a definition that says nothing about limits should still be bounded. We consider sane defaults part of the safety story.

Two details here matter more than they look. First, every instance runs against a pinned snapshot of its definition, so editing an orchestration mid-flight cannot change the rules of a journey already underway. Second, a violated bound is never silent. The offending proposal is archived with the bound it violated, and the instance is handed to a human. The system prefers to stop and ask over quietly improvising.

Every Hand-off Is a Decision, and the Inbox Is Free

We modeled decisions as first-class records rather than metadata on steps, and that one choice quietly produced the human-in-the-loop system. Every promotion writes a decision row: what was proposed, by whom, at what confidence, and how it resolved. Superseded and rejected proposals keep their history. Approval queues then came for free: the inbox is, literally, the decisions that are still pending. Audit trail, analytics on how often humans override the router, and the approval UI all fall out of the same table.

Resolution runs in three tiers, cheapest first. Rules handle the unambiguous cases, an ungated proposal above the confidence threshold approves itself. The supervisor, a built-in agent, handles the ambiguous middle: low-confidence proposals, failed runs, stalled instances, and human replies on the ticket. Humans handle everything gated, and here the design is strict in a way we want to be explicit about. A gated workflow skips the supervisor entirely. The supervisor can carry out a human's stated intent, resolving a decision on behalf of a commenter, but its own judgment can never satisfy a gate. There is no prompt in the system that could talk it through one, because gate checks run in the promotion path, outside any model.

Failure gets the same treatment. A workflow run that fails does not fail the journey; it opens a decision with the failure attached, and the resolver, supervisor or human, chooses retry, a different route, or parking the instance. Turning failures into decisions instead of terminal states is a large part of why the loop survives contact with real infrastructure.

That phrase, contact with real infrastructure, is where we would gently point anyone currently assembling this themselves. The coordination loop is the easy part now. A capable model, a while loop, and a few prompt files will demo agents handing work to each other in an afternoon, and the demos are genuinely impressive. Nearly everything that made this module take months sits underneath the loop, where demos never go. Promotions take a row lock so two resolvers cannot start conflicting steps on the same instance. Step records commit before the run dispatches, outbox style, so a crash between the two cannot lose a journey. Every inbound event carries a receipt, so a redelivered message cannot double-route a ticket. Recovery scanners sweep for stuck states every two minutes, idle instances escalate to the supervisor instead of rotting quietly, and admission control queues the two-hundredth concurrent ticket instead of falling over. None of that shows up in a demo video, and all of it is the difference between agents that impress and agents an organization routes its backlog through.

What the Working Agents Are Allowed to Know

The decision we reversed is the one we would flag as the most interesting in the whole design. The original context model injected the orchestration's goal into every workflow run, on the principle that nothing should be hidden from the agent. Design review killed it, for two concrete failure modes.

The first is scope creep. An RCA agent that reads "carry this ticket to a merged PR" has textual license to exceed its step. A goal reads as a mandate, and agents act on mandates. The second is subtler: verdict skew. That same RCA agent, having perfectly identified the root cause, would sometimes report its work as only partially achieved, because the orchestration's goal, a shipped fix, was not yet met. It was grading itself against the journey instead of its step, corrupting the verdict at exactly the point the routing model depends on it.

So the shipped design splits intent from work. Working workflows receive the case file, the accumulated record of what previous steps concluded, but never the orchestration's goal or routing instructions. Only two places see intent: the completion evaluation and the supervisor. The property this buys is one we care about a lot: a workflow invoked by an orchestration behaves exactly like the same workflow triggered standalone. And the property is structural rather than a matter of prompt discipline, because the goal simply is not present in the context the working agent receives. Notice this is the exact inverse of where we started. Label chaining made every workflow carry knowledge of the workflows downstream of it; orchestrations let a workflow carry none, in either direction. The cost is that agents lose ambient awareness of the journey they are part of. We knew that going in, and we took the trade.

The Business Case

We think this release moves the ceiling on what a team can hand to agents, and the value shows up in three places. Setup is one afternoon instead of one quarter, because describing a journey in prose and picking six workflows is radically cheaper than authoring a transition graph, or than encoding the journey into a pile of custom scripts and glue that only one engineer on the team fully understands. Cheap setup is what lets a team run many small orchestrations instead of one monolithic pipeline. Coordination overhead drops, because hand-offs no longer depend on a person noticing an output or on a trigger somebody remembered to wire up, and a journey that needs to loop back on itself becomes a routing decision instead of a small engineering project. We wrote previously about teams using agent orchestration to scale across the SDLC, and the friction between steps was the recurring tax in every pattern.

The third is the one that gets systems past security review: governance you can actually show. Every enterprise conversation about standing up an agentic SDLC eventually arrives at the same questions, who approved this, what can the agents touch, prove it. Orchestrations answer from the schema. Bounds enforced in one auditable code path, approval as recorded decisions, humans on the gates by construction. That is the shape multi-agent development has to take inside an enterprise, and here it is the default rather than a hardening project.

Where This Goes

The near-term roadmap: richer entry triggers, event-driven promotion so an instance can react to the world mid-journey without waiting for a step boundary, concurrent steps so a journey can fan out, and suspend and resume for journeys that pause on external dependencies.

The longer arc is the one we keep building toward. Individual agents got good enough to do real engineering tasks a while ago. The scarce thing now is an operating model: a way for an organization to run a fleet of agents across hundreds of concurrent journeys with bounded autonomy, humans on the gates, and a record that stands up to an auditor. Orchestrations are our bet on what that operating model looks like. Write down the destination, hand the routing to a machine that must stay inside the lines you drew, and keep every decision on the record. We think the next few years of engineering automation will be measured on journeys rather than tasks, and we want Overcut to be the system teams trust to run them.

Orchestrations are live in the product today. If you already run Overcut workflows, open the Orchestrations tab, write a goal, pick your workflows, and put a gate wherever you want a human. If you are new, start for free and you can have your first orchestration routing real tickets the same afternoon, or book a demo and we will walk you through the two we run on our own backlog. Either way, tell us where the router surprises you. That telemetry is how this gets better.