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.
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.
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.
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.
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.
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.
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.