➜ nextos / teams — agents inside the OS, governed: 403 model_forbidden, checked three times
Governance, enforced.
Not just written down.
Agents run inside NextOS, the operating system in your browser tab, using the same files and apps as anything else on it. Building a site and a team of departments for one business? That story now lives on the business hub. This page is for running those agents at a team’s scale, or against your own application.
A policy page nobody can actually violate. An admin sets what the team may use — providers, models, a locked default, MCP servers, skills — and every run in NextOS is checked against it at the moment it would matter, not just displayed back at the person who set it.
- roles
- 3
- invite links
- 7-day
- per seat / mo
- $28
- enforcement checks
- 3
a mock of the real console (Settings > Governance) — not live data
00Everything on this side
Five pages,
one thing they're all built on.
- agents
Every app is an agent; the assistant orchestrates across them
- the model plane
One model choice, every agent follows - or pin a specific one
- the gateway
An OpenAI-compatible endpoint that routes across five providers
- governance
Budgets, approvals, audit and SSO - for the person signing the cheque
- security
Data flows, encryption, retention and sub-processors
01How enforcement works
Three checks,
not one policy page.
The rules themselves live in one small, dependency-free module, evaluated identically on the server and in the browser — so what a tab shows you before you hit run is the same rule the server enforces after.
The gateway checks first
Every call to /v1/chat/completions resolves the caller’s effective policy and checks the requested model against it before anything is sent to a provider. A forbidden model gets a 403 model_forbidden back, not a silent substitution.
Run creation checks again
Starting or forking an agent run (from an app, a schedule, or the gateway’s inbound door) checks the same policy before the job is even enqueued. The refusal reads the same way everywhere: “your team’s policy does not allow provider/model.”
The runner checks a third time
Right before a background step actually builds a provider adapter, the runner re-fetches the account’s policy and checks again. A schedule enqueued under an older, looser policy — or a job record hand-edited in storage — still can’t run a model the current policy forbids.
02Invites, roles and seats
Bound to an email,
not a link anyone can forward.
There is no mail infrastructure to trust or misconfigure: an admin shares a link, and it only works for the address it was issued to. Everything else about membership follows the same plain rules.
- An invite link is bound to one email address and expires in 7 days — a leaked link is useless to anyone signed in as someone else
- Three roles: owner, admin, member. Owners and admins can invite, set policy, and change roles; members consume what’s allowed
- An org can never drop to zero owners — the last owner can’t be demoted or removed, only replaced
- A member with no Teams plan of their own inherits the org owner’s plan and seat pool while they’re in the org — nothing is written to their own billing record
- Governance can hold a per-member override that replaces the team policy for just that person, without touching everyone else’s
one policy · checked three times