Build1 publisher3 min readPublished
Background Agents hands the task to a second model when one tool call fails three times
An open-source implementation of Ramp's Inspect architecture escalates through bounded retry, a fallback model and an evaluator that can gate PR creation. Adopting it means taking its control plane, Docker sandboxes and GitHub App too.
The Engineer · Build desk
What happened
- Background Agents, an open-source implementation of the architecture Ramp described in its Inspect post, escalates failing coding tasks through limited retry, a fallback model hand-off, an evaluator shadow mode and a feedback rerun.
- When the primary path completes but the evaluator has flagged high-risk behaviour, the system gates PR creation and reruns the task with the shadow report and user feedback in the prompt.
- Sub-tasks run in separate Docker sandboxes, and the parent replays their commits in topological order by file dependency, flagging overlapping edits for the user instead of resolving them itself.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost One task can bill as three full model runs plus a concurrent evaluator stream, and the post reports no data on how often each layer actually fires, so the budget is unquantified.
- constraint With automatic conflict resolution refused by design, human review is the merge strategy, so parallel sub-tasks scale only as far as you can decompose work into file-disjoint pieces.
- decision The escalation logic arrives attached to a control plane, a GitHub App and per-task Docker containers; teams that want only the four layers have to rebuild them inside their own agent loop.
- exposure Because sandboxes hold no long-lived credential, a compromised sub-task container reaches an installation token that dies within the hour.
The escalation trigger is a counter. Where that counter lives decides the token bill. Layer one retries transient faults inline, network timeouts, sandbox restarts and tool call errors, up to a configured limit, without escalating [6]. The concrete threshold in the post is three failures of the same tool call, after which the task moves to layer two instead of looping forever [7]. The general trigger it states for the hand-off is the primary model exhausting its retries [8].
The fallback model runs a different context window or reasoning style and receives the whole execution trace, failed tool calls and error messages included [8]. The second model starts from the first model's error output. I would copy that piece even without the rest of the system.
Layer three does not block the task, but it can stop a pull request. The evaluator model runs in parallel with the primary path and writes a shadow report, flagging repeated file edits, git commands that fail silently and test runs that pass without assertions [9]. When the primary path completes carrying a high-risk flag, the system gates PR creation and escalates to layer four, which reruns the task with the evaluator report and user feedback injected into the prompt as a new execution [10][11].
According to the post, the open-source version reveals the orchestration decisions most agent frameworks skip [20]. The post does not name a framework or compare one. The numbers on offer are 3,057 GitHub stars and a number four trending spot in TypeScript [2][3]. Those figures measure attention to the repository. Whether the four layers pay for their cost on your workload depends on your failures matching the ones they catch: transient tool errors, a model stuck on the same call, and a suite that passes without checking anything [6][7][9].
The control plane mints short-lived installation tokens from a shared GitHub App server-side and hands them to sandboxes through a custom git credential helper [17]. Each token is good for an hour, cached in memory and refreshed on expiry [18]. The project is built for sessions that run hours [1], so a three-hour run crosses two of those expiries [22]. If a refresh fails on a rate limit or a revoked installation, the sandbox pauses and retries with exponential backoff [18]. PRs are opened with the user's GitHub OAuth token [19].
Parent failure is handled explicitly. When the parent task dies with children still running, the control plane signals every child sandbox, gives it 30 seconds to flush logs and push partial commits, then force-kills the container [15]. Those partial commits are tagged with a failure marker so a later run can resume from the last known good state [15].
What to watch
- Recovery rates or layer-firing counts from real sessions would show whether the cascade saves work or only bills for three runs of it.
- Whether Ramp's own Inspect deployment orders the escalation the same way, since only the open-source implementation is documented here.
- How commit attribution is audited when a fallback model or a feedback rerun wrote the code that ships under the user's OAuth token.