Agents babysitting agents

Late in July 2026, an engineer here reviewed and approved three of a teammate's four open pull requests, then asked whether he should hit merge or leave that to the author.

Neither of them wrote the code in those PRs. Neither did most of the reviewing. When coding agents open the majority of your pull requests, the scarce resource stops being code and becomes attention, and three engineers on our team, with no shared plan, each solved that the same way: assign a second agent to babysit the first one's work.

The shape is easy to copy, but more complex to make safe to run. We use a machine-readable surface for supervision, a narrow scope, and credentials the babysitter can't leak.

The work that's left after the code is written

TARS, our autonomous coding agent, is a terminal UI for launching and monitoring agent sessions against the WorkOS monorepo: you give it a prompt and it spins up a cloud agent that writes the code, then opens a pull request once the builds and tests have run. Claude Code and Devin are in rotation here too. The writing part is handled.

Everything after the PR appears is not. CI goes red on a flake. A review bot leaves a dozen inline comments. A human reviewer asks for a rename. The branch drifts behind main and needs a rebase. Each item takes two minutes and none of them require thought. They just arrive asynchronously, across six open PRs, all day.

That's the job now. Shepherding.

Cursor published its own version of this curve: in December 2025, cloud agents authored roughly one in ten PRs merged to the Cursor monorepo, and by July 2026 they wrote more than half. Cursor's framing is that the development environment is a product whose users are agents. The review pipeline has the same users, and almost nobody treats it that way yet.

Three setups, one shape

The most compact version: point Devin at the pull requests Claude Code opened and let it drive them toward merge through the Devin MCP. One agent's output becomes another agent's inbox.

The second: a /babysit slash command that polls the PR after the coding agent creates it. The agent opens the PR, the babysitter sits on it, waiting for the next thing that needs an answer.

The third started as a browser tab. Keep the PR page open and auto-refreshing, and start a reviewer agent the instant a new PR appears. That automation went haywire and got switched off within a day. What replaced it is narrower and duller: Cursor Automations that auto-fix review-bot and other inline comments on one repo's PRs.

None of it is tied to a particular harness. The babysitter can be Claude Tag, or a team agent built on Atlas, our agent platform, where you add the app to a Slack workspace and give agents skills, memory, and integrations. The choreography matters more than the choreographer.

A babysitter can only drive what exposes a machine-readable surface

The pattern has a hard prerequisite, and TARS ran into it directly. Its Ink terminal UI was originally the only way to drive it, so scripts and agent harnesses had no way to create or monitor a session at all. A tool that only speaks to a human's eyes cannot be babysat.

The fix was a headless command surface where every stdout record is one JSON object on one line:

# Create a session and stream events until it becomes idle or terminates
tars session create --prompt "Fix the failing test" --wait

--wait and --follow stream events by polling with deduplication on event ID, and stop once the session terminates, completes, or goes idle after agent activity.

The stream emits records like command.status, command.retry, session.created, session.event, and session.status, and followed streams retry temporary network, rate-limit, and server failures with capped exponential backoff.

Making autonomous PR babysitting safe

Three things make it survivable. Scope: auto-fixing inline review comments on one repo is a much smaller promise than watching every PR and acting on it. And visibility: the TARS session list shows status, age, active time, token usage, cost, and the linked PR URL in one view, so when a babysitter starts spinning, the cost column tells you.

The third is treating a babysitter's inbox like untrusted text. Review-bot comments, CI logs, replies from other agents. That is what it reads all day, and it reads them while holding a token that can push commits.

You can narrow your likelihood of token exposure by keeping the credential out of the agent's process entirely. Relay proxies the agent's calls through WorkOS and swaps in the provider credential at the boundary, so there is no window in which a token exists inside the agent's process and no context for a poisoned comment to leak it from.

Start with the chore you hate most

You don't need a platform to try this. Take the PR chore you resent most (rerunning the flaky test, clearing review-bot nits) and give exactly that job to one agent pointed at a tool that speaks JSON. Scope it to a single repo. Watch the cost column for a week. Get the token out of its context before you widen its mandate.

If you'd rather not assemble the harness yourself, that's most of what we packaged into Atlas: describe the teammate you want, give it a name, a job, and only the tools it needs, then @mention it like anyone else on the team.

It reaches 300+ tools out of the box plus anything with an API, and installing it is one click and a Slack permissions screen, with nothing to deploy.