These agents run on the runtime they're building

The agents that build Rebuno run on Rebuno. Each task is an execution, with tool calls recorded as steps and checked against policy before they run. The agents depend on the same kernel they help develop.

They write code, review changes, test the runtime, and investigate failures. Here's how that work fits together.

Clients submit work to the kernel, which dispatches it to the agents. The agents call models and tools, and the kernel records their steps.

Where work comes from

Work starts in GitHub issues, pull requests, or Slack conversations. Clients turn those requests into executions and post updates where the conversation started.

The GitHub client responds to webhook events. In Slack, a message starts the run, and the thread shows its progress and asks for approval when an action needs it.

The agents

Each agent is a service that receives work through a webhook. Its prompt, tools, and policy are chosen for a particular job.

Code

The coding agent takes an issue or a comment and works on it in its own worktree and branch. It edits files, runs tests, and commits changes as it goes.

Follow-up requests reuse the branch and conversation from the same session. When asked to open a pull request, the agent waits for human approval before submitting it.

The coding agent edits its worktree, uses GitHub for issues and pull requests, and can spawn sub-agents for complex tasks.

Review

For a review, the agent checks out the proposed commit, reads the diff, and runs tests relevant to the changes. It posts its findings as inline comments on the pull request.

Its policy prevents it from approving the pull request, leaving that decision to a person.

The review agent works from a checkout of the proposed changes and sends its findings back to GitHub.

QA

The QA agent runs scenarios that test recovery, approvals, replay, and execution limits. When a check fails, it investigates and files a GitHub issue.

It needs a separate cluster to break, with its own replicas and database. Scripted agents run as executions on that cluster. QA can kill replicas, cut network connections, or wipe the database there while its own execution keeps running on the cluster that dispatched it.

QA uses cluster controls to cause failures and kernel tools to check what happens to the test runs.

Debug

Debugging starts with an execution ID. The agent reads the run's events and steps, then checks container logs and source code to work out what failed.

It has read-only access to these sources, so it can investigate a live incident without modifying the system. It reports the cause and recommends a fix.

The execution record shows which calls ran and how they ended. Logs and source code help explain the failure.

Policy

A policy can block an action through one tool and leave another route open. The policy agent looks for those gaps before the policy is used in production.

It runs under the policy it's testing and probes actions that should be denied. Each probe goes to the kernel as a step, but the tool never performs the action. The agent collects the decisions into a report showing which attempts were allowed, denied, or held for approval.

The kernel evaluates each attempt under the policy being tested. The tools return its decision without carrying out the action.

What they are allowed to do

Each agent's policy sets what it can do and which actions need human approval.

Changing what an agent is allowed to do means updating its policy. The kernel enforces those rules outside the agent, regardless of what its prompt says.

Summary

The agents that build Rebuno run as ordinary executions on it. A coding task might restart after a crash or wait for approval to open a pull request.

When a run fails, we can inspect its recorded calls, results, and policy decisions to understand what happened. Those runs give us feedback on the runtime as we build it.

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