Who this documentation is for
Tetrate Agent Router serves evaluators, developers, and operators differently. This page sends each reader to the right place.
Three kinds of reader
Decision maker
Weighing whether the platform fits the organisation, usually during a proof-of-concept or trial.
"Where does our data go, and what will this cost us?"
Builder
Building against the platform's request-routing surface from applications or agent frameworks.
"How do I route requests, handle fallbacks, and push observability data?"
Platform owner
Running the platform: models, providers, users, budgets, SSO, and audit.
"How do I govern access, onboard teams, and keep the platform healthy?"
One reader may fill more than one of these roles, especially in a smaller team. Pick whichever role matches the task at hand.
If the platform is new, here is the one-line version: Tetrate Agent Router is a self-hosted AI gateway that puts every AI request your organisation makes through a single path you can govern, observe, and trust. The Product overview tells the fuller story in a couple of minutes.
For evaluators
If you're evaluating the platform
You're here to decide whether Tetrate Agent Router belongs in your stack, very likely during a proof-of-concept or trial. You care less about which button to click and more about whether the platform answers the questions your organisation will ask before it commits.
Those questions usually come down to these:
- Where does our data go? All AI traffic flows through a data plane that runs inside your own environment, so payloads, prompts, and credentials never leave your network. The Architecture Overview shows the request path, and Compliance covers data residency, retention, and the controls behind them.
- Can we control and predict cost? Spend is tracked per team and per key, with budgets and rate limits enforced inline rather than reconciled after the fact. The Product overview frames the cost story, and the operator guides show it in practice.
- How hard is integration, and are we locked in? Applications target one endpoint using API shapes they already use, and providers can be added or swapped as a configuration change. Supported APIs lists exactly what the gateway speaks.
- Will it scale to our traffic? Sizing and scale covers throughput, resource sizing, and the deployment footprint.
- What does running it actually require? Prerequisites lists what you need in place before installation on AWS, Azure, or GCP.
A focused way to spend the first hour:
- Read the Product overview for what the platform is and the problems it solves.
- Skim the Architecture Overview to see where it sits and where your data lives.
- Scan Platform Capabilities for the depth behind each feature.
- Check Compliance and Sizing and scale for the due-diligence answers.
- Run a Console quickstart to watch a real request route end to end.
Decision makers who won't touch the platform directly can stop after the first three. The rest of this page is for the people who will build with it or run it.
Two applications, two roles
One platform, two different roles
Day-to-day work on the platform splits across two hands-on roles, each tied to one of its user-facing applications.
| Role | Primary application | Use the docs to learn how to... |
|---|---|---|
| Developer | Agent Router Console | Route requests across providers, manage API keys, integrate the gateway with your applications, aggregate MCP servers, and observe AI traffic |
| Platform operator | Admin Dashboard | Provision models and providers, govern access, audit usage, configure SSO, manage budgets, and run the platform across environments |
There's a third role, the installer, but it's a phase rather than a separate person. The installer is usually the platform operator during initial setup, sometimes joined by a platform engineer who provisions the underlying Kubernetes cluster. That work (standing up the data plane, configuring SSO, onboarding the first administrators) lives in Get started and is mostly done once per environment.
Developers
If you build against the platform's request-routing surface, this is you. Typical work includes integrating Agent Router into an application or agent framework, deciding how requests should fall back when a primary provider is unavailable, splitting traffic between models to manage cost or trial alternatives, and instrumenting your application to see what the gateway is actually doing under load.
You'll spend almost all your time in the Agent Router Console. That's where you issue API keys, author routing policies, assemble MCP profiles, and test prompts in the Playground. You rarely need the Admin Dashboard, though you may inherit credentials, model allowances, and budget caps that an operator set there.
Questions you probably arrive with:
- How is a request routed when more than one provider can serve it?
- What happens when the primary provider returns an error or times out?
- How do I bring my own provider credentials (BYOK) into a routing chain?
- How do I push observability data to an existing OpenTelemetry collector?
- How do I aggregate several MCP servers behind one endpoint for Claude Code, Cursor, or VS Code?
Your goal-driven content lives in the Guides for Developers section. Each guide opens with the goal and when it applies, then walks the end-to-end steps to reach it.
Platform operators
If you own the platform itself, this is you. You decide which models are available across the organisation, which upstream AI providers are wired in, who can use the platform, and how spending and access are controlled. You're also the one on call when something needs to be changed, audited, or explained to a stakeholder.
You'll work mostly in the Admin Dashboard, which exposes the model catalogue, provider configuration, user and group management, audit logs, announcements, instance settings, and the SSO configuration that drives login across the platform. You may dip into the Console too, but usually just to check behaviour from a developer's point of view rather than as daily work.
Questions you probably arrive with:
- How do I introduce new models or providers, and retire existing ones?
- How do I onboard developers, and issue or revoke API keys?
- How do I govern MCP servers, including the OAuth client lifecycle?
- How do I audit platform activity, and what events are recorded?
- How do I integrate single sign-on with our existing corporate identity provider?
- How do I manage multiple instances, for example separate development and production environments, coherently?
Your content lives in the Guides for Platform Operators section, with the same goal-first structure as the developer guides.
Installer (a phase, not a role)
Installation is a one-off activity that usually falls to the platform operator, sometimes with help from a platform engineer who owns the target Kubernetes cluster. The work covers provisioning the data plane in your cloud of choice, installing the gateway, wiring up SSO, and onboarding the first administrators.
Because installation runs in sequence and is time-bound, the material is collected in the Get started section rather than scattered through the role guides. Once installation is done, the same operator typically moves on to Guides for Platform Operators to start governing the running system.
Where to start
Where to start
Where you start depends on how familiar you are with the platform and which role you match.
Evaluating the platform
Follow the first-hour tour: product overview, architecture, capabilities, compliance and sizing references, then finish with a quickstart. The Reference section holds the rest of the due-diligence detail, including gateway behaviour and the glossary.
New to Tetrate Agent Router
Finish the About section (product overview, architecture, key concepts), skim Get started to understand prerequisites, then move to the guides section for your role.
Developer joining an existing deployment
Start with the Guides for Developers section. The Console quickstart is the fastest path from zero to a working request.
Operator picking up an existing deployment
The Admin quickstart gives a guided tour of the Admin Dashboard. From there, Guides for Platform Operators covers the recurring tasks in goal-driven detail.
Looking something up
For exact API surfaces, gateway edge cases, OpenTelemetry metric names, audit event schemas, or definitions of platform-specific terms, head to the Reference section. It is built to be searched and skimmed, not read in order.