Agent Orchestration Patterns: From One-Shots to Autonomous Dev Loops

Stop saying "hey AI, build this"

Most developers using AI agents work the same way: they type a request, the agent writes some code, and that's it. No spec. No review. No structure. It works for small tasks but falls apart on anything real. A typo in the prompt becomes a wrong feature. A vague requirement becomes a wrong implementation. Nobody catches it until it's already deployed.

The fix is not a better model. The fix is orchestration: how you structure the work the agent does, how you hand off between steps, and how you enforce quality without babysitting every line. This tutorial covers four patterns that work, from the simplest to the most autonomous.

Pattern 1: Single-shot

This is the baseline. You write one prompt, the agent does one thing, you check the result. Every developer who has used ChatGPT or Claude has done this. It is the "hello world" of agent orchestration.

The strength is simplicity. No setup, no pipeline, no state to track. You ask for a function, you get a function. The weakness is that it scales terribly. A single-shot agent has no memory of what it just built, no spec to check against, and no review step to catch mistakes. If the task is "write a function that hashes a password," fine. If the task is "add OAuth to the admin dashboard," you will get something that looks right but has subtle gaps.

Pattern 2: Delegation

Delegation is when one agent spawns other agents to work in parallel. Instead of a single agent doing everything sequentially, a parent agent breaks the task into pieces and hands each piece to a child agent. Each child works in isolation with its own context, tools, and terminal session. When all children finish, the parent collects the results.

Think of it like a tech lead assigning tickets to three engineers at the same time. One handles the database migration, one builds the API endpoint, one writes the frontend component. They work simultaneously, and the lead integrates their work when everyone is done.

The advantage over single-shot is parallelism. Three subagents can do three hours of work in one hour. The disadvantage is coordination. If two subagents both modify the same file, you get conflicts. If one subagent produces output the other depends on, you need to sequence them. Delegation works best when the subtasks are genuinely independent: different files, different systems, different domains.

Pattern 3: Pipeline (Assembly Line)

This is where orchestration gets serious. A pipeline breaks the development process into discrete stages, each handled by a specialized agent that does one thing and passes the output to the next stage. The key insight is that each agent has a narrow job and a contract that defines what "done" means.

The best example is fleXX-loop, a three-stage pipeline built for Hermes Agent. It works like this:

1. Spec agent interviews you about a raw idea until the requirements are unambiguous. It researches the codebase first so it never asks you something the code can answer. When the spec is clear, it writes a task file with acceptance criteria (AC-N) and non-goals (NG-N). Each AC is an observable outcome. Each NG is a hard boundary.
2. Build agent picks up the task, implements every acceptance criterion, and pushes a branch. It never touches anything outside the contract. If it finds a bug along the way, it notes it in the report but does not fix it. If something is ambiguous, it stops and asks instead of guessing.
3. Review agent checks out the branch, runs the test suite, reads every changed file, and posts a structured verdict: what must be fixed before merge, what should be fixed, and whether it is safe to merge. It flags scope creep (changes beyond the acceptance criteria) and scope conflicts (an AC that requires crossing an NG).

    flowchart LR
        I[Raw Idea] --> S[Spec Agent]
        S --> T[Task File\nAC-N / NG-N]
        T --> B[Build Agent]
        B --> BR[Branch + Tests]
        BR --> R[Review Agent]
        R --> V{Verdict}
        V -->|Pass| H[Human Merges]
        V -->|Fail| B
        V -->|Blocked| S
  

The contract is what makes this work. The AC-N and NG-N IDs are written once during spec and never changed. Build implements them. Review checks them. If two different agents read the same spec, they ship the same observable behavior because the contract is explicit and immutable.

The human is always the merge button. No agent in the pipeline ever merges its own work. The build agent pushes a branch. The review agent posts a verdict. You decide whether to merge. This is not a limitation; it is a safety boundary. The agent can write code, run tests, and audit quality, but it cannot ship without your approval.

The pipeline also handles task dependencies. Each task has a depends_on field listing the slugs that must be merged first. If task B depends on task A, the build agent skips task B until task A is merged. This lets you chain small tasks into a big feature without manual coordination.

Pattern 4: Event-driven

The pipeline above is powerful, but it still requires someone to say "work the queue" and "review this." Event-driven orchestration removes that. Instead of a human triggering each stage, the system reacts to changes automatically.

The mechanism is git hooks. When you commit a task file that flips to status: agent-ready, a post-commit hook detects the change and fires the build agent. When the build agent pushes a branch, it triggers the review agent as a background process. The verdict arrives in your chat without you asking for it.

This turns the pipeline from a manual process into a reactive system. You write a spec, mark it ready, commit. The build runs. The review runs. You get a verdict. You merge. No polling, no cron jobs, no "hey agent, check if there's work to do." The loop is driven by state changes, not timers.

The critical detail is that this works entirely locally. No VPS, no webhook server, no exposed port. The git hook calls the agent CLI (hermes chat -q) on the same machine where you are coding. This means anyone with the agent installed can run the event-driven loop. You do not need infrastructure. You need a git repo and a hook script.

Cron-based polling is the fallback for unattended machines. If your machine is not always on, or you want the loop to run on a server, you can set up cron jobs that periodically check for ready tasks and unmerged branches. It is less efficient than event-driven because it polls on a timer instead of reacting instantly, but it works when git hooks are not an option.

Which pattern should you use?

Start with single-shot for quick tasks. Use delegation when you have parallel work that does not overlap. Move to a pipeline when correctness matters and you need structure. Go event-driven when the pipeline is working well and you want to remove the manual triggers.

The patterns are not exclusive. You can use single-shot for a quick fix, delegate a research task, and run the event-driven pipeline for a feature, all in the same day. The point is to match the pattern to the task, not to force everything through one approach.