Access: who can do what

Every business needs to control who can do what. In Routario that control is unusually simple: there is one access list, and everyone is on it — the people on your team, the AI agents you build, the API keys you issue, and the field devices (Scouts) you connect. They are all checked the same way, with the same vocabulary.

You manage all of it in one place: Settings → Access.

One list, every kind of actor

The access matrix at Settings → Access shows every actor as a row, with a small chip marking what kind it is — Human, Agent, API, or Scout — and the areas of Routario as columns. Each cell shows what that actor can do in that area.

Administrators show as Owner: they can do everything (more on that below). New actors start with no access — you grant what they need.

Scopes: Read, Write, Execute

Within an area, access climbs a short ladder: — (none) → Read → Write → Execute. What the verbs mean depends on the area:

A feature area — like Deals or Proposals: Read = see it; Write = create and change things in it.
A Flow or an Agent: Read → Write → Execute. Here Execute is the arm verb — the line between a draft and the live thing. You build and edit a flow under Write; turning it live, so it can actually run, needs Execute. That last step is deliberately a person’s to grant.
Memory: Read and Write are independent — you can let something write to Memory without being able to read what is already there (useful for a flow that just files documents away), or the other way around.
Scout devices: instead of a ladder, each device is allowed a specific set of capabilities — speak, capture, and so on.

Granting access: pick an area, not a checkbox maze

You grant access by area, and Routario handles the detail for you. Give a person the “Deals” area and they get the Deals screens. Give an agent the same “Deals” area and it gets the Deals tools it can use in its work. Same intent, expressed at the right grain for each kind of actor — you just pick the area and the level. The step-by-step is in Give a teammate or agent the right access.

What has to be true for an action

An action goes through only when all three of these say yes:

You’re allowed — you (or the agent or key acting) hold the access for it.
Your workspace has the feature — it is included in your plan.
Administrators can do everything — admins sit above the per-area scopes; they are the Owners, and granting access is itself an admin job.

Every denial explains itself

Routario never dead-ends you with a silent “nothing happened”:

For people — a button you lack rights for is shown disabled, with the reason on hover. The keyboard shortcut to create something shows that same reason as a small corner note instead of quietly doing nothing. And if you reach a blocked action another way, you get a clear “ask an administrator” message.
For machines — an API key, an external (MCP) agent, or an agent’s own tool call that is denied comes back as a clear, explanatory error the caller can read and relay. Never silent, never cryptic.

A couple of things worth knowing

Turning something off is not the same as deleting it. Disable an integration, archive an agent, or unpair a device and its access setup is kept — re-enable it and access comes straight back. Only a permanent delete clears access for good, so that a recycled name can’t inherit old permissions.
Every actor is both a holder and a subject. An agent holds access to do its work — and is itself something you grant others access to: you can give a person Read on one specific agent, or Execute to arm it. The same is true of flows. Access runs in both directions.

Questions people ask

I run an agent that has more access than me — can I do more through it?

No — and that’s by design. An agent has its own access, granted separately from yours, so it can be set up to do exactly its job and no more.

When you drive an agent — chatting with it, or running it by hand — it is bounded by both its access and yours: it cannot do anything you could not do yourself. So you can never reach further through an agent than you could on your own; an out-of-scope request simply gets a polite refusal. Agents that run on their own — on a schedule or in response to an event, with no person driving — act with their own access, since there is no person to bound them to. (That’s why it’s worth granting an agent’s access with the same care you’d grant a person’s.)

Does an agent’s write always happen the moment it decides to?

Not by default. An agent’s write access has two tiers: asks first (the default) and unattended. On the asks first tier, the moment the agent wants to change something — create a deal, send a message, update a row — it pauses and asks a person, who can approve the action, edit its details before approving, or decline it. The request arrives as a notification, and the full detail (with the edit option) is on the agent’s run page. Only tools you explicitly move to unattended write without asking.

Do administrators need to be granted access?

No. Administrators (and platform owners) can do everything. They appear as Owner in the matrix and sit above the per-area scopes. Use the matrix to grant access to everyone else.

I gave someone Write but they still can’t see the area — why?

For the ladder areas, Write includes Read, so that is usually not the cause. Memory is the exception: there, Read and Write are separate, so if you want someone to both read and write Memory, switch on both.

How much of Routario is access-controlled?

Access is organised by area — each area has its own Read / Write / Execute, and you hold it per area. You can do what you’ve been granted; administrators can do everything. Where you lack access, the control is shown disabled with the reason (see Every denial explains itself above), so you always know why rather than hitting a silent wall.

Can a new API key or external agent do anything by default?

No. A brand-new key or external (MCP) agent can do nothing until you grant it — it starts fully closed, and you open up exactly the areas it needs. See Connect an AI agent over MCP for how an AI agent connects, or the API overview for other external systems.

Where to go next

Projects and who can see them — the layer above this one: whether a teammate can sign in, and which project’s data they see (the “you don’t have project access yet” screen).
Connect an AI agent over MCP — give an AI agent governed, scoped access to your workspace.
Give a teammate or agent the right access — the step-by-step in Settings → Access.
How Routario thinks — the ideas behind the whole product, including where people fit.
Keep a human in the loop — where people and automations meet.