Start here

RTA, short for Rule Them All and written rta on the command line, is one binary over the tools you already juggle: databases, object storage, secrets, networking, certificates, host telemetry, HTTP APIs. Every capability is written once and rendered on three surfaces: a scriptable CLI, an interactive TUI, and an MCP server for AI agents.

It is also the layer underneath the agent you already use. rta is not another AI CLI and does not want to be the thing you talk to: it is the part that decides what Claude Code, Codex, Cursor, Copilot or Gemini may actually touch. Handing an agent a shell is one decision that covers everything it will ever do. Pointing it at rta is a different shape: read-only by default, everything else granted per capability, narrowed to one record, expiring on its own, and written down.

Nothing needs configuring to begin, and nothing needs reading in order. Pick what you came to do. Each track lists its pages in reading order, and every page outside the reference section ends by naming the one that follows it.

Four tracks

Track	You want to	Read	Afterwards you can
A. Try it	See what rta does on your own machine	Installation, Quick start: about 15 minutes	Ask your machine anything in five formats, search every capability from the TUI, read any capability's card, and watch an agent be refused and then allowed
B. Give an agent access safely	Let an agent use rta, and know exactly what it can do	Six pages: about 45 minutes	Have an agent that reads what is local, is refused a write, and holds a 15-minute grant you issued, with the record of all three calls and a way to stop it now
C. Run it for a team	Share a boundary: environments, a ceiling nobody can raise, a server per person	Eight pages: about an hour	Have named environments, secrets in an encrypted store, a committed team ceiling, and a hosted instance each person's agent reaches
D. Extend it	Add a capability rta does not have	Writing a plugin: 15 minutes, then the rest as you need it	Have a plugin that runs, passes the conformance suite and installs from an index of your own

A. Try it

1. Installation — one binary, on your $PATH, and a check that it works.
2. Quick start — ask a question, get it in the shape you need, open the shell, read a capability's card, and connect an agent, refuse a call and allow it.

When you want more of the everyday surface, these stand alone and read well in this order: The CLI, The TUI, Your config file, Dashboard and theme, Seeing the shape of things, Profiles and Secrets.

B. Give an agent access safely

1. What rta actually bounds — read this first if your agent can run shell commands, which most can. An agent that still has a shell is not bounded by rta at all, and this page says what you get from rta anyway and how to be in the configuration where the rest applies.
2. Connect an agent — register a client, name it, and check that it reached rta.
3. Grants — permission for one capability, optionally one record, that expires on its own.
4. The record — what agents asked for, what they got, and what is waiting on you.
5. Stop an agent now — a lock, the instant no.
6. Harden in five minutes — the checklist to run once on a machine an agent will use: doctor, init, a lock, a ceiling, small grants and the record.

MCP and the safety gate is the reference for what a connected agent can reach and what every call is held to, Roles, consent and the guard is what to add once grants are routine, and Connecting your AI tool has the detail for each client.

C. Run it for a team

1. Profiles — name an environment once and point every plugin at it.
2. Secrets — an encrypted local store for what a profile refers to.
3. Team policy — a ceiling a repository can commit, which can only ever subtract.
4. Hosting a server — --http, tokens, probes, and what a remote server leaves out.
5. The operator channel — issuing grants and answering consent on a server you have no shell on.
6. Containers and images — the hardened server recipe, and why not one server for everyone.
7. OIDC — naming the person behind a call with the identity provider you already have.
8. Kubernetes — the chart: one instance per person, and day two.

D. Extend it

Using plugins first, for how a plugin is found, trusted and confined, and Indexes and upgrades for how one arrives. Then Writing a plugin, which takes fifteen minutes from plugin new to a plugin that runs, and four pages for what comes after: Declaring inputs, Answers, errors and hints, Safety, credentials and what rta does to your process, and Testing, conventions and publishing.

If you arrive with a job

Start from the work instead of the feature. For a security team deploys rta, commits a ceiling, hands out roles and reviews the record. For a developer is a day's work with environments, secrets and a bounded agent. An agent in a cluster is the whole path end to end, from a profile to an agent connected over MCP, and Recipes has the rest, each with its level and what it needs.

A word that seems to mean something particular — a grant, the record, a profile, a role — is defined once in the glossary, with the acronyms these pages assume.

What you are about to use

Everything in rta is a capability: a small, declared unit of work with typed inputs, a safety class and one implementation. sys.cpu is a capability, and so are kv.get, pg.query and net.dns. A capability declares itself once, and the three surfaces are generated from that declaration:

Three things are worth knowing early:

• rta explain <capability> prints the same card the TUI and the MCP schema are built from. It is the authoritative reference for any command, and it is never out of date.
• A safety class travels with the capability, not with the surface. read, write and destructive mean the same thing whoever is asking; the difference is what each surface does about it.
• Adding a plugin adds capabilities to all three surfaces at once. There is no separate MCP registration step, and no way for a plugin to appear on one surface and not another.