Next to your vendors' settings
Next to the vendors' own settings, not in place of them
The coding agents' business plans come with admin settings of their own: managed instructions, permission rules, MCP allowlists, usage analytics. Keep using them. Tempa covers what they leave out, and helps you lock them down.
| Topic | A vendor's own admin settings | With Tempa |
|---|---|---|
| Who it reaches | Developers signed in to that vendor's business plan | Every developer who signs in to Tempa, on a personal, team or company plan |
| Per team | Typically one configuration for the whole organisation | Per organisation, department, team and project, inherited with modes |
| Harnesses | That vendor's own agent | Claude Code, Codex, GitHub Copilot, Gemini CLI and Antigravity from one profile |
| Company context | Allow and deny lists of MCP servers | An MCP proxy that adds the credentials, with a tool allowlist per team |
| Change control | Edited in the vendor's admin console | A Git repository with pull requests, or drafts reviewed and published in Tempa |
| Evidence | Usage analytics for that vendor | Adoption, decisions and work across harnesses, and a hash-chained audit log |
Use both
Tempa reads nothing from your vendor contracts and changes none of their settings. Where a harness offers managed settings, Tempa writes a lock-down pack for your device management: Codex's requirements file and GitHub Copilot's managed settings, so developers cannot switch Tempa's hooks off.
If every developer is on one vendor's enterprise plan and one configuration fits everyone, that vendor's settings may be all you need. Tempa is for the companies where that is not the case.