Give a teammate or agent the right access
When someone joins your team, you build a new agent, or you issue an API key, you decide what it’s allowed to touch. You do that in one place — the access matrix.
For the model behind it (what the scopes mean, how denials work), see Access: who can do what. This page is the click-path.
Open the access matrix
Section titled “Open the access matrix”Go to Settings → Access. You’ll see every actor as a row — people, agents, API keys, and Scout devices, each with a chip showing its kind (Human / Agent / API / Scout) — and the areas of Routario as columns. Each cell shows what that actor can already do; administrators show as Owner.
Grant access to a person or an API key
Section titled “Grant access to a person or an API key”- Find the row for the person or API key and open it.
- You’ll see one line per area. For each area you want to grant, set the level:
- a dropdown — — (none), Read, Write, or, for Flows and Agents, Execute;
- for Memory, two separate switches — Read and Write — since those are independent.
- Save. That’s it — access takes effect immediately.
Everything starts at no access, so you only ever turn things on.
Agents and Scouts are edited where they live
Section titled “Agents and Scouts are edited where they live”The matrix shows every actor’s access, but agents and devices are scoped on their own screens (so you set them up alongside the rest of their configuration):
- Open an Agent row and you’re taken to that agent’s Configure page, where you choose the tools (areas) it may use in its work.
- Open a Scout row and you’re taken to Scout settings, where you choose the capabilities that device is allowed.
In every case you’re picking an area and a level — the matrix just sends you to the right editor.
For an agent, the write level comes in two flavours: Read & write (asks first) — the default — asks a person to approve, edit, or decline a write before it happens (the run pauses and waits if you triggered it directly; if a flow triggered the agent, it proposes the write and keeps going instead, since a flow step can’t sit and wait); Read & write (unattended) lets it write without asking. Start with asks first and upgrade a tool to unattended once you trust how the agent uses it. See How agents ask before they write for the full mechanics of both cases.
What the levels mean
Section titled “What the levels mean”- Read — see it. Write — create and change things in it.
- Execute (Flows and Agents only) — arm it: turn the draft into the live thing that can run.
- Memory — Read and Write are separate; grant either or both.
A few worked examples
Section titled “A few worked examples”- A new teammate on Deals: open their row, set the Deals area to Write (which includes Read). They can now see and manage deals.
- An API key that only files data: set a table to Write but leave Read off where the area allows it — the key can add rows without reading existing ones. (Memory works the same way: Write without Read.)
- Make a flow live: grant Execute on that flow to the person who should be allowed to arm it.
Where to go next
Section titled “Where to go next”- Access: who can do what — the model behind the matrix, and the questions people ask.
- Projects and who can see them — why a new teammate sees “no project access,” and how to add them to a project.
- How agents ask before they write — what “asks first” actually does, in both the interactive and flow-invoked case.
- Keep a human in the loop — assigning decisions to the right people.
- Branch on an AI decision — what agents and flows actually do once they’re armed.