Scout: Scheduled and Background Coding Agents Compared — Routines, Symphony, Copilot, ADK

Summary

Four background-agent offerings landed in roughly two weeks, and they are not the same product shape. Anthropic Routines is a hosted scheduler/webhook surface that runs full Claude Code cloud sessions on a schedule, on HTTP POST, or on GitHub events — a research-preview feature attached to existing Pro/Max/Team/Enterprise plans, drawing down the same subscription usage interactive sessions consume [1][2]. OpenAI Symphony is an Apache-2.0 specification — SPEC.md with an Elixir reference implementation — that turns an issue tracker (Linear, in the reference impl) into the control plane for Codex agents pulled per ticket [3][4]. GitHub Copilot Coding Agent has been on this track since May 2025: trigger is issue assignment, runtime is GitHub Actions, output is a draft PR; the agent’s commits are authored by Copilot with the task initiator as co-author and link back to session logs [5][6][7]. Google ADK Go 1.0 is not a scheduler at all but the durable-execution substrate underneath: RequireConfirmation HITL gates, OpenTelemetry tracing, A2A protocol support, and a DatabaseSessionService that lets agents pause for days and resume from SQLite or Cloud SQL without context loss [8][9]. The four offers segment on the axis of who orchestrates: Routines is a hosted runner, Symphony is a written spec, Copilot is an issue-driven workflow, ADK is a framework. Mixing them is the practical move, not picking one.

Key Findings

1. The orchestration model differs more than the marketing suggests

Each vendor positions its release as “background coding agents,” but the orchestration primitives diverge sharply.

Routines is event-driven and cron-style at the same time: a routine carries one or more triggers attached to a saved prompt + repository + connector bundle, and each matching event spawns a fresh Claude Code cloud session [1]. The three trigger types are Scheduled (hourly to weekly, with custom cron via /schedule update and a one-hour minimum interval), API (per-routine /fire endpoint, bearer token, optional text payload), and GitHub (pull_request.* and release.* events with author/title/branch/label filters) [1]. A single routine can combine all three. The cloud session has no permission-mode picker and no approval prompts during a run — what the routine can touch is locked down at creation time via the connector list, environment network allowlist, and the Allow unrestricted branch pushes toggle [1].

Symphony is fundamentally different. The SPEC.md describes Symphony as “a scheduler/runner and tracker reader” — not an agent, not a model, not a UI [4]. Each open issue on a monitored board (Linear in the reference implementation) becomes an isolated workspace; the orchestrator polls the tracker, creates a workspace per issue, launches a Codex subprocess (codex app-server by default), and streams turn events back as the agent works [4]. InfoQ captured the intent verbatim from OpenAI: “Each engineer would open a few Codex sessions, assign tasks, review the output, steer the agent, and repeat. In practice, most people could comfortably manage three to five sessions at a time before context switching became painful” [3]. The board is the work backlog; humans manage the board, not the agents.

Copilot Coding Agent sits on a third axis: issue-assignment as the only first-class trigger, GitHub Actions as the runtime, draft PR as the output artifact. Per GitHub’s announcement, the agent “spins up a secure and fully customizable development environment powered by GitHub Actions” the moment an issue is assigned to it [6]. Subsequent @copilot mentions in PR comments steer the running session [5]. There is no cron, no webhook, no API endpoint — the issue tracker is the schedule, and GitHub Actions is the durable substrate.

ADK Go 1.0 isn’t a scheduler. It’s the durable-execution framework underneath whichever scheduling surface you build on top. The published onboarding-agent tutorial demonstrates the shape: a session pauses for days while an employee signs documents, then resumes when a webhook fires a state_delta, with the container scaled to zero in between [9]. The runtime mechanics are explicit state machines (START → WELCOME_SENT → DOCUMENTS_SIGNED → …), DatabaseSessionService persistence to SQLite or Cloud SQL, atomic state_delta transitions, and RequireConfirmation for HITL gates [8][9]. You bring your own trigger.

The practitioner read: these are complementary, not competing, primitives. Routines is a hosted runner; Symphony is a written contract for how a tracker-driven orchestrator should behave; Copilot is an issue-assignment workflow; ADK is a durable-execution framework. A team that runs a nightly Claude Code routine to triage GitHub issues, hands triaged issues off to Copilot for implementation, and uses an ADK-based service to coordinate cross-system follow-ups is doing the right thing — not converging on one vendor.

2. Governance primitives — HITL gates, approval UX, identity

This is where the offerings differentiate sharply, and where 2026-H2 deployment decisions will live.

Routines runs without per-action approval. The Anthropic docs are explicit: “Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run” [1]. All gating is up-front — at routine creation time, you pick the repositories, the network access level (Trusted by default with a curated package-manager allowlist), the connectors the run is allowed to call, and whether the routine may push to non-claude/ branches [1]. Identity is the user who created the routine: “Routines belong to your individual claude.ai account… Anything a routine does through your connected GitHub identity or connectors appears as you: commits and pull requests carry your GitHub user, and Slack messages, Linear tickets, or other connector actions use your linked accounts” [1]. The audit trail is the session URL returned by the /fire endpoint and the run-list on the routine detail page [1]. Team and Enterprise admins can disable routines org-wide via a single toggle [1].

Symphony’s HITL posture is intentionally unprescribed. The SPEC.md states implementations “are expected to document their trust and safety posture explicitly. This specification does not require a single approval, sandbox, or operator-confirmation policy” [4]. Documented options range from auto-approving all command/file-change requests to surfacing approvals to a human operator to failing any run that requires user input. The one hard rule is procedural: “A run MUST NOT stall indefinitely waiting for user input” [4]. InfoQ surfaces the editorial framing for review gates: “a human developer remains responsible for reviewing these generated issues before Symphony assigns them for execution” [3]. Identity is whatever the implementer wires into the codex app-server command and the Linear API token — the spec leaves this to the deployer.

Copilot’s identity model is the most explicit of the four. Every commit is authored by Copilot, with the human who assigned the issue as co-author [7]. As of March 2026, every commit message carries an Agent-Logs-Url trailer linking back to the agent’s session logs, so an auditor reading the PR history can pivot directly to the agent’s reasoning [7]. Cloud-agent commits are signed [6]. GitHub’s published governance controls around the agent are workflow-shaped rather than scan-shaped: branch-push restrictions on what the agent can write to, configurable network access during the run, required human approval before any CI/CD workflows run on the agent’s PR, and reviewer separation — “the developer who asks the agent to open a pull request cannot be the one to approve it” [6]. Whatever GitHub Advanced Security primitives (CodeQL, secret scanning, dependency review) a repo has already enabled run on the agent’s PR the same way they would on any other PR; those scans are repo-configured GHAS features, not a coding-agent-specific bundle [5].

ADK Go’s HITL is a primitive, not a workflow. RequireConfirmation flags a tool call as needing human approval; execution pauses until the approval arrives — aligning with Google’s published Safe AI Framework guidelines [8]. The framework provides the mechanic; the deployer designs the surface on which the approval happens.

The governance read: Copilot is the path of least resistance for teams whose threat model centres on proving which agent did what, when, and under whose request — the combination of commit attribution, session-log trailer, signed commits, and the GitHub-workflow gating controls makes for the most complete published provenance story across the four. Routines is acceptable for teams comfortable with up-front sandboxing as the gating model (no per-action approval). Symphony pushes the governance design onto the implementer. ADK gives you the building blocks but expects you to assemble the policy.

3. Pricing — programmatic-only meters vs included-in-subscription

The cost model splits the four cleanly.

Routines draws down the same subscription usage interactive sessions consume: “Routines draw down subscription usage the same way interactive sessions do” [1]. The Anthropic docs add a daily routine-run cap per account on top of the normal subscription limit, with one-off (single-fire) schedules exempt from the routine cap but still consuming subscription usage [1]. Routines is available on Pro, Max, Team, and Enterprise plans [1].

This intersects with Anthropic’s 2026-06-15 metering change, covered in the Edition 12 dispatch [10]. The metering change moves the Agent SDK, headless Claude Code, GitHub Actions integrations, and third-party frameworks onto a separate dedicated credit pool — Pro $20 / Max 5x $100 / Max 20x $200 in nominal dollars, spent at API rates, non-rolling [10]. The current Routines documentation describes draw against “subscription usage” rather than the programmatic credit pool [1]; public guidance on whether Routines runs land in the programmatic pool or the interactive pool after 2026-06-15 remains thin. The honest answer for a team planning H2 capacity is to model both possibilities and re-check the documentation on 2026-06-16.

Symphony is free. Apache 2.0 reference implementation, self-hosted, no SaaS [4][3]. The cost is Codex tokens consumed by however many parallel agents you run — Symphony is the supervisor, not a billing surface.

Copilot Coding Agent is included in existing Copilot plans. Per GitHub Docs: “Within your monthly usage allowance for GitHub Actions and premium requests, you can ask Copilot cloud agent to work on coding tasks without incurring any additional costs” [5]. The agent is available on Pro, Pro+, Business, and Enterprise [5]. Effective 2026-06-01, Copilot is transitioning from premium-request units to token-priced AI Credits [16], with token consumption (input, output, cached) billed at per-model rates published in GitHub’s pricing reference [11]. Code completions and next-edit suggestions remain unlimited; agent runs come out of the credit allotment [11].

The same calendar fortnight has Anthropic separating programmatic from interactive usage on 2026-06-15 [10] and GitHub moving Copilot to usage-based billing on 2026-06-01 [11]. Both vendors are restructuring individual-tier pricing on the agent-workload assumption in adjacent calendar weeks.

ADK Go is free as a framework. You pay for whatever Gemini / Vertex AI tokens your agents consume, plus whatever runtime infrastructure (Cloud Run, Cloud SQL for the DatabaseSessionService, Cloud Trace for observability) you provision [8][9]. Public guidance on exact token pricing for production ADK workloads is the same Vertex AI rate card; no special “ADK” line item exists.

The pricing read: if your workload is a few scheduled runs a day, mostly read-shaped, writing a draft PR occasionally — Routines and Copilot Coding Agent are subscription-included and the cost-per-task is bundled into the plan you already pay for. If your workload is continuous parallel agents chewing through a 200-ticket backlog — Symphony plus paid Codex API usage and Copilot’s post-2026-06-01 token meter both put you on a transparent per-token rate, but at materially different unit prices. ADK is the only framework that lets you self-host the substrate end-to-end if hosted runtimes are off the table.

4. Ecosystem hooks — AGENTS.md, CLAUDE.md, MCP, A2A

Project-context files have converged faster than the schedulers have. The Linux Foundation launched the Agentic AI Foundation in December 2025 with AGENTS.md, MCP, and goose as anchor projects [12]. AGENTS.md is now the cross-vendor convention, adopted across Codex, Cursor, Gemini CLI, Jules, Factory, GitHub Copilot, VS Code, Amp, and others — over 60,000 repos at last count [13]. CLAUDE.md is Anthropic’s stricter superset (hierarchical files, path-scoped rules, import system, user-level overrides). GEMINI.md is Google’s. None of these is the same file as Symphony’s WORKFLOW.md, which is a Symphony-internal specification for the policy a workflow follows, distinct from the AGENTS.md context-file convention [4].

Compatibility breaks down concretely:

• Routines runs Claude Code cloud sessions and therefore reads CLAUDE.md natively; whether Claude Code now reads AGENTS.md fallbacks within Routines isn’t called out separately in the documentation, but Claude Code’s general behavior is to prefer CLAUDE.md when present. Connectors are MCP servers — any MCP integration you’ve added to your claude.ai account is available inside the routine session [1].
• Symphony is Codex-only at the protocol layer (the spec is hard-coded against the codex app-server JSON-RPC). Codex itself reads AGENTS.md. The orchestrator’s policy lives in a separate file called WORKFLOW.md per the spec [4]; this is intra-Symphony configuration, not an AGENTS.md substitute. Symphony has been ported to Claude Code with GitHub Issues by an external developer [3], but that’s a community fork, not the reference implementation.
• Copilot Coding Agent has supported AGENTS.md (including nested files) since August 2025, alongside .github/copilot-instructions.md, .github/instructions/**.instructions.md, CLAUDE.md, and GEMINI.md [14]. The agent treats these as context; AGENTS.md is documented as a strong instruction file but Copilot doesn’t grant it the strict-authority status Claude Code grants CLAUDE.md.
• ADK Go 1.0 does not ingest AGENTS.md or CLAUDE.md as such; agents are defined in YAML with command-line tooling and the policy lives in the framework, not in a markdown file at the repo root [8]. Where ADK does converge with the cross-vendor protocol layer is A2A: Agent2Agent reached v1.0 on 2026-03-12, transferred to Linux Foundation governance, and now has SDKs in Python, Go, Java, JavaScript, and .NET [15]. ADK Go ships native A2A and handles event ordering and response aggregation between Go, Java, and Python agents automatically [8].

Disambiguating the protocol soup: A2A here is the Linux Foundation Agent2Agent specification, originally contributed by Google [15]. It is distinct from A2UI (Google’s generative-UI standard for agents, separate spec) and from Anthropic’s MCP (Model Context Protocol, agent-to-tool integration rather than agent-to-agent). The published A2A documentation positions A2A as complementary to MCP rather than overlapping: MCP is how an agent talks to a tool; A2A is how two opaque agents talk to each other [15].

5. The Symphony asterisk — Linear-only, Codex-coupled

Symphony’s marketing framing positions it as turning a project-management tool into the control plane, but the published spec is narrower than the framing. Per SPEC.md, the only supported tracker is Linear: “Current supported value: linear” for tracker.kind [4]. Jira and GitHub Issues are not in the spec; community ports exist (notably the Claude Code + GitHub Issues fork [3]) but those are downstream. Similarly, the reference implementation runs codex app-server as the agent — the spec is explicit that “the Codex app-server protocol for the targeted Codex version is the source of truth” [4] and includes Codex-specific fields like codex.approval_policy, codex.thread_sandbox, and codex.turn_sandbox_policy.

For teams whose project-management is Linear and whose model preference is Codex, this is fine. For teams on Jira / Azure Boards / GitHub Issues / Asana / Plane / Shortcut who want Claude Code or Gemini in the agent slot, the Symphony spec is a starting point for your own implementation, not a drop-in. The fact that an external developer ported it to Claude Code + GitHub Issues in a fortnight [3] is a credit to the spec’s portability, but it’s also a signal that the reference implementation is narrower than the marketing.

OpenAI’s own framing of Symphony’s status is unambiguous and worth quoting directly. InfoQ paraphrases it well: “Another notable aspect of Symphony is that it is not a complex supervision system, but rather a SPEC.md file describing the problem and its solution that every organization can use to create its own orchestrator” [3]. OpenAI is not offering Symphony as a SaaS, will not maintain it as a product, and reported a sixfold jump in merged pull requests on internal teams during Symphony’s first three weeks [3]. Whether that number generalises to external teams without OpenAI’s internal Codex tuning and review culture remains untested in public reporting.

6. ADK is the substrate, not the surface

The four offerings get grouped together because they shipped in the same fortnight, but ADK Go 1.0 is not a peer to Routines, Symphony, or Copilot Coding Agent. It’s the durable-execution layer underneath whichever scheduling surface a team picks.

The published onboarding-agent tutorial walks through what makes ADK Go specifically useful for long-running coding-agent workflows: explicit state machines with named states (START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED); DatabaseSessionService persistence to SQLite or Cloud SQL so the session survives container restarts; atomic state_delta transitions inside tool invocations; webhook-driven resumption with scale-to-zero between events [9]. The tutorial is explicit about why this matters versus naive long-running agents: prompt pollution (chat history bloat after hundreds of turns confuses reasoning), token cost explosion (replaying weeks of chat multiplies inference cost), and hallucination over idle time (models fabricate intermediate steps after long pauses) [9].

For coding-agent teams specifically, the substrate matters in three places: (a) when a scheduled run hits a long-running step like a multi-hour bisection or a large refactor that needs human approval mid-flight; (b) when a workflow needs to coordinate across multiple agents (Go, Python, Java) via A2A; (c) when production observability requires structured OpenTelemetry traces rather than tail-the-logs debugging [8]. Routines, Symphony, and Copilot each handle pieces of this implicitly; ADK lets you assemble it explicitly.

7. The matrix

Practical Implications

The 2026-H2 hosting choice for scheduled / background coding agents segments on five practical axes:

1. If your project-management is GitHub Issues and your model preference is GPT or open-question: Copilot Coding Agent is the path of least resistance. The pricing is bundled (token-priced from 2026-06-01), the identity model is the most mature, and issue-assignment is a one-click UX. The cost is being locked to Copilot’s model selection and to GitHub-native triggers.

2. If you’re a Claude Code shop and want a hosted scheduler today: Routines is the closest thing to a turnkey solution. The catch is that the up-front sandboxing model assumes you can fully scope the connector / network / branch-push permissions at routine creation, with no per-action approval during runs. Plan for the 2026-06-15 metering change: model whether your routine workloads land in the interactive subscription pool or the programmatic credit pool, since current documentation describes Routines as drawing on subscription usage but the metering change reclassifies “programmatic” workloads broadly. Recheck the docs on 2026-06-16.

3. If your project-management is Linear and your model preference is Codex, and you want to self-host: Symphony is the spec to implement. Apache 2.0, Elixir reference implementation, and OpenAI is explicit that it will not offer this as a SaaS. You own the operational burden of running the orchestrator, but the cost is just Codex API usage.

4. If you’re orchestrating across Go/Java/Python agents or need multi-day durable execution: ADK Go 1.0 plus A2A is the substrate. Build your scheduler on top of it (cron, Cloud Scheduler, Eventarc — your call). Use RequireConfirmation for HITL gates and DatabaseSessionService for pause/resume. The downside: no out-of-the-box scheduler — you wire the trigger surface yourself.

5. For many teams, the practical answer is likely to be mixed. A nightly Routines-triggered Claude Code triage pass that hands the highest-confidence issues to Copilot Coding Agent for implementation, with an ADK-based service brokering cross-system A2A coordination for the complex multi-agent jobs, is a coherent architecture. The four offerings are not competing for the same slot.

Two governance-layer recommendations worth surfacing regardless of which vendor you pick:

• The identity primitive matters more than the framing. Copilot’s model — commits authored by Copilot, the human listed as co-author, a session-log URL embedded in the commit trailer, and signed commits [7] — is the most complete published provenance story across the four. Routines appears weakest on agent-distinct provenance: actions are attributed to the creator’s connected accounts, so every commit looks like it came from a person who may not even have been at a keyboard [1]. If your auditor cares about who-did-what, Routines pushes the work onto your internal logging.

• Budget for the 2026-06-01 / 2026-06-15 calendar collision. Both GitHub Copilot’s transition to usage-based billing (2026-06-01) and Anthropic’s programmatic-usage separation (2026-06-15) land inside two weeks of each other. Either vendor’s pricing model on June 16 will be materially different from May 31. Model the post-transition cost before committing scheduled-agent workloads to either platform at scale.

Open Questions

• Whether Anthropic Routines runs land in the new programmatic credit pool or the interactive subscription pool after 2026-06-15 — Anthropic’s current Routines documentation describes draw against subscription usage, but the 2026-06-15 metering change reclassifies programmatic usage broadly. Public guidance on which side of the line Routines sits remains thin.
• Whether the Symphony port to Claude Code + GitHub Issues referenced in InfoQ’s coverage will be folded into the official SPEC.md or remain a community fork, and whether OpenAI plans first-party Jira / GitHub Issues / Azure Boards adapters or expects the community to write them.
• Whether the GitHub-style governance bundle for cloud coding agents (signed commits, session-log trailers, reviewer separation, pre-CI workflow approval, configurable network access) gets replicated by other vendors. As of this reporting, no equivalent end-to-end provenance + workflow-gating bundle ships in the Anthropic, OpenAI, or Google flows; individual primitives (e.g. ADK’s RequireConfirmation, Routines’ creation-time scoping) exist but don’t compose into the same auditor-readable shape.
• How A2A adoption interacts with MCP in production — both protocols are Linux Foundation governed, both have growing SDKs, and they’re positioned as complementary, but no production case study comparing the operational complexity of running both layers in the same agent system has been published yet.
• Whether ADK Go’s DatabaseSessionService pattern (pause for days, resume from SQLite, scale to zero) generalises to coding-agent workloads that need to hold a worktree-locked filesystem state across the pause. The published tutorial uses an onboarding agent where state is fully serialisable; coding agents with active git worktrees are a harder case.

Sources

1. Anthropic — Automate work with routines (Claude Code docs)
2. InfoQ — Anthropic Introduces Routines for Claude Code Automation
3. InfoQ — OpenAI Open-Sources Symphony, a SPEC.md for Autonomous Coding Agent Orchestration
4. GitHub — openai/symphony repository (SPEC.md and Elixir reference implementation)
5. GitHub Docs — About GitHub Copilot cloud agent
6. GitHub Blog — Meet the new coding agent (May 2025 announcement)
7. GitHub Changelog — Trace any Copilot coding agent commit to its session logs (March 2026)
8. Google Developers Blog — ADK Go 1.0 Arrives!
9. Google Developers Blog — Build long-running AI agents that pause, resume, and never lose context with ADK
10. The Register — Anthropic tosses agents into the API billing pool
11. GitHub Docs — Models and pricing for GitHub Copilot
12. Linux Foundation — Announces Formation of the Agentic AI Foundation
13. AGENTS.md — open format reference
14. GitHub Changelog — Copilot coding agent now supports AGENTS.md custom instructions (August 2025)
15. GitHub — a2aproject/A2A protocol repository (Linux Foundation)
16. GitHub Blog — GitHub Copilot is moving to usage-based billing