5K

Background Agent with CI Feedback

Runs the agent in the background on its own branch and uses CI results as feedback to patch failures until green or blocked

validated in production Updated 2026-10-13 By Nikola Balic (@nibzard) Based on Quinn Slack
View .md Edit on GitHub
Add to Pack
or

Saved locally in this browser for now.

Cite This Pattern
APA 
Nikola Balic (@nibzard) (2026). Background Agent with CI Feedback. In *Awesome Agentic Patterns*. Retrieved October 14, 2026, from https://agentic-patterns.com/patterns/background-agent-ci
BibTeX 
@misc{agentic_patterns_background-agent-ci,
  title = {Background Agent with CI Feedback},
  author = {Nikola Balic (@nibzard)},
  year = {2026},
  howpublished = {\url{https://agentic-patterns.com/patterns/background-agent-ci}},
  note = {Awesome Agentic Patterns}
}

Use when

  • Long-running refactors or dependency upgrades
  • Developers wait and poll for CI results
  • CI gives objective pass or fail signals

Avoid when

  • No reliable CI suite exists
  • Task needs frequent human decisions during the work

Problem

Long-running refactors and flaky-fix cycles force developers into synchronous supervision. When the agent must wait on tests, build jobs, and deployment checks, human attention gets wasted on polling instead of decision-making. This bottleneck is worse in distributed teams where CI feedback arrives minutes later and context-switch cost is high.

Solution

Run the agent asynchronously in the background with CI as the objective feedback channel. The agent pushes a branch, waits for CI results, patches failures, and repeats until policy-defined stopping conditions are met. Users are only pulled back in for approvals, ambiguous failures, or final review.

Production implementations include GitHub Agentic Workflows, Cursor Background Agent, and OpenHands. On the Amp side this shows up as Orbs: cloud machines per thread that keep working after you disconnect (Amp Orbs docs). This pattern is about running the whole retry loop unattended in the background, not about designing the agent and repo so CI output is usable feedback.

Key mechanics:

  • Branch-per-task isolation (often via cloud-based execution or git worktrees).
  • CI log ingestion into structured failure signals.
  • Partial feedback: start patching from early failure subsets before the full suite finishes.
  • Retry budget and stop rules to avoid infinite churn.
  • Notification on terminal states (green, blocked, needs-human).

Example (flow)

sequenceDiagram Dev->>Agent: "Upgrade to React 19" Agent->>Git: push branch react19-upgrade Agent-->>CI: trigger tests CI-->>Agent: 12 failures Agent->>Files: patch imports Agent-->>CI: re-run CI-->>Agent: ✅ all green Agent-->>Dev: PR ready

How to use it

  • Start with deterministic tasks: dependency upgrades, lint migrations, flaky test triage.
  • Define retry budgets (max_attempts, max_runtime) and escalation triggers.
  • Use safe defaults: read-only permissions where possible, draft PRs for AI-generated changes.
  • Keep artifact links in notifications so humans can review failures quickly.
  • Gate merge on CI plus at least one human approval for high-risk repos.
  • Consider durable execution mechanisms (Temporal, LangGraph) for long-running tasks.

Trade-offs

  • Pros: Better developer focus, lower waiting time, and tighter CI-driven iteration loops.
  • Cons: Requires robust task lifecycle management, failure triage logic, and notification discipline.

References

Source