The agent namespace
Why agent work lands on its own lanes.
Written By Dustin
Last updated 23 minutes ago
An agent's token is scoped to agent/<name>/**, and a token cannot write to a lane outside that scope. This is structural, not a convention.
The scope covers both the plain agent/<name> lane and anything under it, so agent/refactor-bot and agent/refactor-bot/experiment are both in bounds. TOVIO allows multi-component lane names precisely so agent tokens have room to work.
One naming note: TOVIO calls this a lane — the concept Git calls a branch — but the token field is branch_scope and agent abandon takes a <BRANCH> argument. Same thing, two spellings, because tovio branch is kept as a git-compatible alias.
What it gets you
- Nothing lands in your work by surprise. Agent output sits in its own namespace until you promote it.
- Review before integration is the default, because there is a boundary to cross.
- Isolation between agents. Several agents working at once do not interleave commits on one lane.
- Discarding is easy — tombstone the lane.
Promoting good work
tovio agent promote <name> --onto mainTakes the agent name and resolves its single live lane, or a full lane path if you would rather be explicit. --onto defaults to main.
Discarding a bad run
tovio agent abandon agent/<name>Takes the lane path, not the agent name. It refuses anything outside agent/ and points you at tovio branch <name> --delete for an ordinary lane, and it refuses to abandon the lane you are currently on — which would leave you standing on a dead ref.
Reviewing first
tovio log --entity agenttovio change show <chg-id> --difftovio semantic diffsemantic diff is worth running on agent work specifically — it flags breaking interface changes rather than textual ones, which is exactly the failure mode of a confident model.
Do not use the namespace yourself
Keep agent/ for agents so the distinction stays meaningful, and so scope reasoning stays simple.