Coding Agent Overview

ReasonOS ships a coding agent as part of rbs. It is not an editor plugin bolted onto a build tool — the agent, the build system, and the editor share one workspace model, so the agent reasons about your code the same way rbs does: as a graph of targets.

​

What makes it different

​

Graph-first

Most coding agents explore a repository by searching text. The ReasonOS agent starts from the workspace dependency graph instead. It has first-class tools to:

• list and inspect targets (rbs_targets), their dependencies (rbs_deps) and reverse dependencies (rbs_rdeps)
• find which target owns a source file (rbs_owners)
• compute the affected set for a change (rbs_affected)
• navigate the workspace knowledge graph — symbols, communities, impact analysis, and path-finding between code entities (the atlas_* tools)

That means “what breaks if I change this?” is a graph query, not a guess.

​

Build-system-native

The agent builds and tests through rbs, with the same caching and hermeticity you get on the command line:

• rbs_build and rbs_test run real targets and stream real output
• rbs_run / rbs_start / rbs_stop execute and manage long-running targets (dev servers, services) in the background
• rbs_rules and rbs_validate let it author and check BUILD.rbs files against the actual rule catalog before writing them
• external dependency tools let it inspect resolved packages rather than guessing at APIs

When the agent says a change builds and its tests pass, it verified that through the build system — not by eyeballing the diff.

​

Engines

The agent runtime supports several software choices, called agents in the UI and engines in configuration. The model and its account or API key are separate choices. Each engine integrates with the workspace tools. Selecting an agent: use the Agent and AI model choices in AI Work, or the editor’s chat controls. A resumed conversation retains its existing agent and model. The rbs agent CLI uses the built-in engine. Defaults have a scope: Project settings → Default agent selects the starting agent for new branch servers; it does not replace settings on already-running servers. Organization Settings → Agent installation controls installed CLIs. Your account → Personal AI accounts connects your credentials. See AI accounts and keys for branch defaults, browser-local preferences and optional overrides.

​

Where it runs

• Terminal — rbs agent starts an interactive session in your shell: a plain REPL by default, or a full-screen interface with --tui. See Using the agent.
• The ReasonOS editor — the editor connects to your branch node’s server, which hosts agent sessions alongside the language servers and file watchers. Sessions are multi-client: teammates on the same branch see the same node.
• Across the managed application — AI Work opens the agent alongside project pages, cycles and proposals without opening the editor. It still runs on a branch server, with your project permissions.
• Headless — rbs agent "your prompt" runs a single turn and exits, and ai_task targets put agent-driven work (including browser QA tests) directly into the build graph, runnable with rbs run and rbs test.

​

Sessions, memory, and checkpoints

Sessions. A session is one conversation with the agent — its transcript, permission mode, todo list, and background subagents. Editor sessions persist; CLI chats can be saved. Saved chats live in the committed .reasonos/ai/chats/ tree, so they travel with the branch through git rather than living on any one machine. Memory. The agent keeps two durable stores per branch, both committed under .reasonos/ai/:

• Lessons — observations about what worked and what failed in this repository, recorded as it works. Recent lessons are injected into every new session’s context.
• Taste — style preferences for how this codebase likes its code written.

Because both are committed, an agent joining a branch inherits what previous sessions learned there. Long conversations are compacted automatically so a session never runs out of context mid-task. Checkpoints. In the editor, the agent snapshots the workspace’s file state before it starts modifying files. Every checkpoint records exactly what changed, and you can diff against or revert to any checkpoint — so letting the agent work is never a one-way door. See Checkpoints for the full workflow.

​

Learn more