Spotify's internal agent setup for code changes: an interactive agent scopes the task, a background coding agent opens the pull request, and an LLM judge checks the diff.
Documented by AgentCV from public sources — not submitted by this team.
Not claimed by or endorsed by the team or its organization. Metrics are cited only as the sources state them; absent metrics render as [unknown].
Sources: 1,500+ PRs Later: Spotify’s Journey with Our Background Coding Agent (Honk, Part 1) (engineering.atspotify.com) · Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3) (engineering.atspotify.com)
Is this your team? Claim it · Ask us to remove it
Recent activity
Version cuts and proof, newest first — the living track record.
Spec sheet
The benchmark fields — designed for comparison across teams.
- Topology
- Pipeline
- Agent count
- [unknown]
- Listed members
- 3
- Platform
- Custom
- Runs on
- Custom ×3
- Industries
- software-delivery
- Task kinds
- code-migrationcode-generationcode-review
- Trust tier
- Self-Reported
- Proof entries
- 2
Topology & roster
System wiring
Node details
Typical Pipeline layout — schematic, not verified wiring
HumanHuman operatorHuman gate
- Tool
- Human operator
- Autonomy
- Human-gated
- directs → Stage 1 agent
BuilderStage 1 agent
- Tool
- Stage 1 agent
- Autonomy
- Runs autonomously
- hands off to → Stage 2 agent
- directs ← Human operator
BuilderStage 2 agent
- Tool
- Stage 2 agent
- Autonomy
- Runs autonomously
- hands off to → QA reviewer
- hands off to ← Stage 1 agent
QAQA reviewer
- Tool
- QA reviewer
- Autonomy
- Runs autonomously
- delivers to → Output artifact
- hands off to ← Stage 2 agent
ResourceOutput artifact
- Tool
- Output artifact
- Autonomy
- Runs autonomously
- delivers to ← QA reviewer
Automation story
self-reportedHonk began as an agent for fleet-wide code migrations across Spotify's repositories and was extended to ad hoc coding work, which engineers can start from Slack or GitHub Enterprise. Spotify teams have merged over 1,500 agent-generated pull requests, and Spotify says hundreds of developers use the agent.
How a typical Pipeline team handles a task
Typical Pipeline layout — schematic, not verified wiring
Task arrives
Human operator directs Stage 1 agent.
The builders execute
Stage 1 agent and Stage 2 agent build the work.
Independent review gates the work
QA reviewer reviews the work. This reviewer is autonomous and separate from the agent that built the work, so the check is independent of its author.
The artifact lands
The artifact lands in Output artifact: QA reviewer contributes via "delivers to".
Human holds the last word
Human operator holds final approval.
Replicate a typical Pipeline setup
Typical Pipeline layout — schematic, not verified wiring
Ingredients
- HumanHuman operator
- BuilderStage 1 agent
- BuilderStage 2 agent
- QAQA reviewer
- ResourceOutput artifact
Setup order
- 1.Provision the substrate: Output artifact.
- 2.Wire Stage 1 agent: it receives "directs" from Human operator and sends "hands off to" to Stage 2 agent. Wire Stage 2 agent: it receives "hands off to" from Stage 1 agent and sends "hands off to" to QA reviewer. Wire QA reviewer: it receives "hands off to" from Stage 2 agent.
- 3.Give QA reviewer an independent workspace/verdict channel: "delivers to" to Output artifact.
- 4.Declare the human gate: Human operator holds final approval.
3 listed members: the members the cited sources name. The total team size is not stated.
Performance metrics
Windowed metrics with provenance. [unknown] means it was not tracked — an honest hole beats an invented figure.
No metrics on record yet.
Token economics
Cost transparency is part of the honesty architecture. [unknown] means it was not tracked — not that it is zero.
Blueprint
Operational DNA — why it works, how it was built, and how it is overseen. Not files for sale; knowledge of the design.
The agent took the place of deterministic migration scripts inside Spotify's Fleet Management framework, which already handled choosing target repositories, opening pull requests, collecting reviews and merging. An internal CLI hands prompts to an agent, runs formatting and linting through local MCP, calls an LLM judge on diffs, uploads logs and traces, and lets Spotify swap agents and models. The coding agent is also exposed over MCP. A verification loop of independent verifiers (for example a Maven verifier triggered by a pom.xml) runs before the judge.
When a verifier fails, no pull request is opened and the user gets an error. The judge vetoes roughly a quarter of sessions, and the agent manages to correct course about half of those times. Spotify notes it has not yet built evals for the judge. Changes still pass through team review before they are merged.
Proof (2)
The team's shared track record — tasks, incidents, lessons, milestones. Per-entry provenance tags are always visible.
- ArtifactDec 9, 2025self-reported
Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3)
Public source cited for this curated profile. Published 2025-12-09; accessed by AgentCV 2026-10-20. Lesson stated in this source: The judge's most frequent reason for a veto is the agent doing work beyond what the prompt asked for.
https://engineering.atspotify.com/2025/12/feedback-loops-background-coding-agents-part-3 - ArtifactNov 6, 2025self-reported
1,500+ PRs Later: Spotify’s Journey with Our Background Coding Agent (Honk, Part 1)
Public source cited for this curated profile. Published 2025-11-06; accessed by AgentCV 2026-10-20.
https://engineering.atspotify.com/2025/11/spotifys-background-coding-agent-part-1
Sign in to add a proof entry.
Sign inAttestations (0)
Named third-party statements from people with first-hand experience. Attestations are what separates Peer-Attested from Evidence-Linked.
No attestations yet. Worked with this configuration or agent? Attest to it using the form below — attestations are named third-party statements and are what separates Peer-Attested from Evidence-Linked.
Sign in to attest to this team.
Sign in