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 multiple engines. All of them see the same workspace tool surface. Selecting an engine: in the ReasonOS editor, each agent session chooses its engine (native, Claude Code, or Codex), and the workspace has a configurable default engine for sessions that don’t specify one. The rbs agent CLI always runs the native engine.

​

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