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.
\nThey write code, review changes, test the runtime, and investigate failures. Here's how that work fits together.
\nWork starts in GitHub issues, pull requests, or Slack conversations. Clients turn those requests into executions and post updates where the conversation started.
\nThe 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.
\nEach agent is a service that receives work through a webhook. Its prompt, tools, and policy are chosen for a particular job.
\nThe 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.
\nFollow-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.
\nFor 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.
\nIts policy prevents it from approving the pull request, leaving that decision to a person.
\nThe QA agent runs scenarios that test recovery, approvals, replay, and execution limits. When a check fails, it investigates and files a GitHub issue.
\nIt 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.
\nDebugging 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.
\nIt 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.
\nA 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.
\nIt 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.
\nEach agent's policy sets what it can do and which actions need human approval.
\nChanging 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.
\nThe 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.
\nWhen 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.
\nTo learn more about Rebuno, read the docs or visit the repository on GitHub.
","headings":[{"level":2,"text":"Where work comes from","id":"where-work-comes-from"},{"level":2,"text":"The agents","id":"the-agents"},{"level":3,"text":"Code","id":"code"},{"level":3,"text":"Review","id":"review"},{"level":3,"text":"QA","id":"qa"},{"level":3,"text":"Debug","id":"debug"},{"level":3,"text":"Policy","id":"policy"},{"level":2,"text":"What they are allowed to do","id":"what-they-are-allowed-to-do"},{"level":2,"text":"Summary","id":"summary"}]}}