Coding agents on Rebuno

A background coding agent might restart halfway through a task, wait hours for approval, or get review comments on its pull request days later. To continue the task, it needs its working files and the conversation so far.

Here's a design using Rebuno, following an agent asked to fix a bug. After making the edit and passing the tests, its worker runs out of memory and is killed. It resumes, gets approval to open a pull request, and handles a review comment in a later run.

The setup

• Clients start a run for each request from an issue or pull request, and post approval requests.
• The agent service runs the model and tool loop. It owns each session's branch, workspace, and conversation.
• The sandbox and its storage run repository code and preserve the working files.
• Rebuno dispatches executions, checks each call against policy, and records the results. It dispatches an execution again after an interruption or approval.

The agent works with no one watching. Its worker can die halfway through a task, or it can run a command that was never reviewed. Clients start runs through Rebuno so a crashed run is dispatched again and each call is checked against policy before it runs.

Clients start runs and Rebuno dispatches them to the agent. The agent keeps files in the sandbox and conversations in a separate store.

The workspace

The agent edits the code and runs the tests. They pass, and Rebuno records both results. Before the next model call, the worker runs out of memory and is killed. Rebuno dispatches the execution again, and the agent code starts from the beginning.

Recorded calls return their saved results. The edit reports success and the tests report a pass without either running again. If the new worker clones the repository again, the fix is missing and the agent can open a pull request without it. Keep the workspace on a persistent volume or in a sandbox that can stop and resume so the new worker gets the files the first one edited.

Replaying the edit returns its result without changing any files. A fresh checkout is still missing the fix.

The conversation

The agent service stores the conversation outside the worker. Each run loads it at the start and saves it at the end.

If the worker stops after saving but before the execution completes, the next attempt loads a conversation that already includes its own work. Save the conversation the execution started from alongside it, and return that one when the same execution loads again.

Approvals and follow-ups

Opening a pull request needs approval, so the run pauses. The client posts the request on the issue, and the sandbox can stop while it waits. Once a maintainer approves, Rebuno dispatches the execution again. The agent reconnects to the workspace, replays its earlier calls, and opens the pull request.

Later, a reviewer requests another change. The client starts a new execution for the same session, which picks up the workspace and conversation where the last run left off.

Each run in a session starts after the previous run finishes and loads the conversation it saved.

Summary

Rebuno records every model and tool call. It dispatches the execution again after the worker is killed or an approval comes back. The agent code replays the recorded results until it reaches new work. The sandbox can be stopped during the approval wait.

Replay doesn't change the files on disk. The agent service keeps the workspace from the first attempt so the fix is still there. A follow-up starts with only its input and loads the saved conversation. Rebuno handles each execution. The agent service keeps what carries over to the next one.

To learn more about Rebuno, read the docs or visit the repository on GitHub.