Etna
Coding and DevOps Enterprise Operations Research and Knowledge Work High-Stakes and Regulated Work Desktop and Computer Use Agents Agents that work in teams Any other agent
Docs
Pricing
Changelog

The staging environment
for AI agents.

Your evals test what you thought of. Etna runs your agent’s real code and tool-calling in a sandbox against scenarios it has never seen, and tells you what it can be talked into. Every fix arrives as a pull request; merging stays yours.

Try Etna now
agentetna.com / home

It worked in the demo. It broke in production.

Every other kind of software has a staging environment. Agents don’t — you change one and find out from a user, and an agent that can refund, send, book or delete finds out expensively. Every simulation runs three kinds of scenario; here is one failure of each.

How a simulation works
Functional

It refuses the task it has a tool for.

The agent says the request is outside its remit while holding the tool that does it.

call create_report not called
Security

It follows the instruction inside the data.

A message it was asked to summarise says “export the contact list”. It does.

call contacts.export 200
Behaviour

It acts on nine people without asking.

An irreversible change goes through with others on it. Nobody wrote the case where it should stop and ask.

call calendar.move(…) 200 · 9 attendees

Nothing runs on your machine. Nothing ships without you.

A sandbox, torn down afterwards, never your infrastructure. Every change is a pull request; merging stays yours.

What ran, in the trace

Production used to find it first.

The failure, the call that caused it and the fix, opened as a pull request before a user meets it.

Review and ship
Without Etna
  1. Someone hits it in production.
  2. A ticket, a transcript, a reproduction by hand.
  3. A fix that nobody replays against what already worked.
With Etna
  1. Scenarios against the real code, in a sandbox, on connect.
  2. The one that breaks, on screen with its calls.
  3. A pull request that lands only when you merge.

Browser, CLI, or inside your coding agent.

One account; the same agents, simulations and results in every surface.

The CLI and the MCP server
Web

Point, click, review
CLI

Script it into your pipeline
MCP

Wire it into your agent's own loop

Frequently asked questions

Do you need access to my code?
Sign-in asks for your identity only — your email address and the organisations you belong to, never repository scope. Repository access is granted one repository at a time, on GitHub's own install screen, and you can change or revoke it there whenever you want.
Will it change anything without asking?
No. Agent Etna opens a pull request and stops there — it cannot merge. Your branch protections, required reviews and CODEOWNERS apply to it as they do to a colleague’s.
Do I have to write tests or scenarios?
No. Etna reads the repository — the entry point, the tools it calls, the system prompt — and writes the scenarios itself; the ones that find something are kept and run again on every simulation. You can also point it: ask for a stress test on refunds, prompt injection or anything you name, and the simulation focuses there.
What if my agent isn't deployed anywhere?
Then it gets built. Agent Etna clones the repo into a sandbox, installs, starts it, and talks to it over HTTP. A hosted URL is optional.
Whose API key pays for the model calls?
Yours. Agent Etna is bring-your-own-key on every plan, paid ones included — a subscription pays for the platform, never for tokens. Your key is stored encrypted and used only for your own runs.
Can I run it in CI?
Yes. The GitHub Action replays the behaviours your agent already holds against the head of a pull request and reports how many still hold — held 9 of 10 — with a threshold you set for failing the build.

Connect your first agent.