Subagents

For some tasks Rinari delegates part of the work to a subagent: a specialist that runs inside the current turn with a bounded objective and reports back to her as evidence. Rinari decides when to delegate; the result comes back to the main conversation, and she answers in her own voice.

Built-in agents

Agent	Role
explore	Read-only repository exploration: finds files, symbols and conventions, with file:line references.
reviewer	Read-only review of a defined diff, with findings ranked by severity.
debugger	Reproduces a defect and finds its root cause. May run commands, but doesn’t edit project files.
researcher	Technical research with cited evidence from the web and local docs. No local writes by default.
implementer	Implements one bounded task in its own isolated worktree.
verifier	Independently re-runs the named validations, inspects the diff and decides the completion state.

What a subagent inherits

• The parent session’s tools — including MCP, plugin and SSH tools — and its permission ceiling. A subagent never gets broader permissions than its parent.
• Approvals you already granted in the session. New approval requests appear in the parent conversation, with the agent’s name. Cancelling the agent withdraws its pending requests.
• The turn’s budget: what a subagent spends counts toward the turn that spawned it.

Delegation is bounded: limits on how many agents run at once keep it from multiplying, and subagents don’t delegate recursively. A subagent’s own processes and browser profile close when it finishes.

See what an agent did

Agent cards in the timeline have View activity. Expand it to see the agent’s objective, effective permissions, working directory, commands, visible model messages and result. This is observable activity, recorded under the parent turn and rebuilt when history reloads — not private model reasoning.

Models for each agent

By default every agent uses the session’s model. In Settings → Agents you can change that per agent:

• Model — the model this agent uses, or Inherit session;
• Fallback — a model to use if the primary one isn’t available;
• Enabled — turn an agent off;
• Reset — back to the defaults.

For example, a fast model for explore and a stronger one for reviewer. A profile can save its own models per agent; they follow the profile of each conversation. A model without tool calling can’t do much as an agent: check the model’s capabilities before assigning it.

Project agents

A trusted project can define its own agents in .rinari/agents/. For example, .rinari/agents/reviewer.md:

---
name: reviewer
description: Inspect this repository
profile: read-only
tools:
  - fs.read
  - search.*
---
Review the requested changes and return findings.

Leave out profile and tools to inherit them from the session. Role objectives, budgets, concurrency limits and cancellation still apply.

Subagents and the Soul

Only the main agent speaks with Rinari’s Soul. Subagents keep functional role personas, so their reports stay plain.

In the terminal

rinari agents list
rinari agents run reviewer --task "review auth changes"

Running an agent directly is mainly for debugging; in normal work Rinari spawns them herself.