Skip to content

PATTERN Cited by 4 sources

Dispatcher–Coding-Agent–Closer

Definition

A three-part loop for putting recurring, predictable engineering maintenance work (KTLO — "keep the lights on") on autopilot with a coding agent, while keeping a human at the merge gate:

  1. Dispatcher — a scheduled/event-driven job that finds the work. It queries a ticket system (Jira) for eligible work items and, for each one, triggers a coding-agent run with the work-item key passed as context. It fans out across every eligible item and runs agents in parallel. Nobody has to remember to invoke anything: the work finds the agent.
  2. Coding Agent — a thin prompt that reads the work item, loads a codebase-specific skill, verifies the current state, makes the bounded change, runs the repo's required checks, and — only if checks pass — opens a draft/normal pull request. The domain knowledge lives in the versioned skill, not the prompt (separation of concerns).
  3. Closer — comments the PR link on the work item, labels it as automated (so every automated change stays queryable), and — after a human merges — the item closes (often automatically post-deploy). The closer duties are sometimes folded into the tail of the coding-agent step.

The human stays in the loop at review, not at startup: the loop removes the repetitive start-up toil (finding eligible work, reconstructing history, locating every usage, preparing the first safe change), and the engineer makes the final merge call.

Why

Recurring maintenance work — stale feature-flag cleanup, vulnerability remediation, dependency bumps, flaky-test triage, doc fixes — shares a shape: the steps are known and written down somewhere, but each instance "requires codebase-specific knowledge that isn't easy to automate with a script and it competes with everything else on the backlog." (Source: sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines) A static script can't carry the judgment; a human keeps losing the prioritization fight. An agent loaded with a codebase-specific skill bridges that gap, and the dispatcher removes the "remember to run it" tax.

Shape / mechanism

  • Work item as the agent's prompt. The ticket carries structured context (e.g. flag name, final value, type, gate state; or CVE, package, advisory) so the agent starts from resolved cross-system state, not a blank search. See work-item-as-agent-prompt.
  • Trigger. A schedule (cron / Rovo Studio automation rule) or a status transition on the work item fires the agent with a custom system prompt.
  • Parallel fan-out. One agent run per eligible item, concurrently — throughput scales with the queue, not with a human.
  • Thin prompt, rich skill. The prompt is a small harness that loads a skill and reports a one-line result; the reusable, reviewable skill holds the how-to. Same skill runs whether triggered by the pipeline or interactively. ("The prompts are the system.")
  • Verify before mutating. The agent confirms the current codebase state before editing; if reality disagrees with the ticket, it stops and reports. (patterns/verify-before-changing-code)
  • Checks gate the PR. Lint / type-check / tests must pass before a PR opens; on unfixable failure the agent stops and reports rather than opening a broken PR.
  • Least-privilege per step. Each pipeline step declares its own OAuth scopes (read:repository, write:repository, write:pullrequest) and branch restrictions prevent direct pushes to main — bounding blast radius if a run goes wrong. (concepts/least-privileged-access)
  • Everything in-repo, reviewed like code. Pipeline definition, prompts, model/tool config, and skills all live in the repository and go through code review.

When to reach for it

Best fit: maintenance work with reliable ticket context, a bounded code change, and clear validation. Feature-flag cleanup and vulnerability remediation met those conditions; dependency updates, documentation fixes, and remediation work are named as candidates. Poor fit: open-ended feature work, changes without a crisp definition of done, or work whose validation can't be automated.

Relationship to closed-loop remediation

patterns/closed-loop-remediation removes the human per instance (detect → act → log, no human in the loop). This pattern deliberately keeps the human at the merge gate — the agent prepares the change and opens a PR, but an engineer reviews and merges. It is the human-gated sibling of closed-loop remediation: full automation of the toil, human authority over the merge.

Seen in

  • sources/2026-08-28-atlassian-agentic-automation-in-practice-putting-standard-engineering-work-on-autopilot — canonical wiki instance and the source of the "Dispatcher → Coding Agent → Closer" name. Worked example: vulnerability remediation. Each stage is a versioned Bitbucket Agentic Pipeline step invoking Rovo Dev non-interactively; the coding agent carries a fix-vulnerability decision-tree skill. Reported: 120+ vulnerabilities resolved, 55+ automated PRs merged, 95% first-run merge rate (May–July 2026).
  • sources/2026-09-24-atlassian-how-we-automated-feature-flag-cleanup-with-agentic-pipelines — second independent instance: stale feature-flag cleanup. A scheduled Rovo Studio rule (dispatcher) queries Jira for eligible stale-flag tickets and fans out one coding-agent pipeline per ticket; the agent loads a feature-flag-cleanup skill, verifies the flag's state, inlines the surviving branch, removes dead code, runs checks, opens a PR, and comments/labels the ticket (closer). In production since April 2026, run monthly. Confirms the architecture generalizes beyond vulnerabilities and promotes it from a single-source framing to a reusable named pattern.

  • sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in — precursor instance (KTLO chores in the Jira repo). A daily heuristic cron emits one Jira work item per stale flag with pre-resolved cross-system state; a status transition triggers the agent, which dispatches a three-tier skill fallback chain and opens a draft PR for human review. Reported: 500+ merged stale-flag PRs in 70 days; ~80% reduction in flaky-test eng hours. This is the dispatcher/trigger + coding-agent halves before Atlassian named the three-part loop.

  • sources/2026-09-30-cloudflare-detect-and-send-production-issues-straight-to-your-agent — detection-triggered variant: a live error signal is the dispatcher. Cloudflare Workers Issues groups repeated exceptions / 5xx / error logs into one root-cause issue, then an Automation fires when the issue crosses an occurrence threshold (or returns after a quiet period) and hands the packaged failure context — error, source-mapped stack trace, leading/trailing logs+traces, Worker version, and app context — straight to a coding agent (Claude Code / Cursor / Devin), a generic webhook, or chat/incident tooling. The coding agent investigates (querying deeper logs/traces via the Cloudflare MCP server), proposes code + test changes, and opens a PR; the human closes by reviewing the PR, deploying, and marking the issue resolved. The novelty vs. the Atlassian instances: the dispatcher is not a scheduled ticket query but a production error detector — "the work finds the agent" specialized to the failure finds the agent. Dogfooded on Workflows → two edge-case bugs found and fixed within a day, routed to Cloudflare OS as the agent. Same three-part shape, error-signal trigger.

Last updated · 766 distilled / 2,225 read