Skip to main content
app.pome.sh is the web view for everything you run with Pome: the agents you register, the twin sessions they run against, the runs themselves, and the judge handoff for each one. pome run records to the dashboard by default. Local copies of the artifacts (events.jsonl, score.json, state snapshots) also land on disk under runs/<task>/<run-id>/.

​
What you find

Navigation is a left sidebar. Home sits on its own at the top — the workspace overview: metric tiles, a 7-day evals trend, your agents, and a rail of runs that need attention. Everything else is grouped: Signing in drops you on Agents. Documentation is a link in the sidebar footer, next to your plan and account — not a nav item.

​
Agents

Where you land, and the entry point to per-agent reliability rather than a roster. One card per registered agent; open one and you get Tasks, Runs, Clones, and Settings tabs. The drill-down asks the reliability question one level at a time:
  • Agent → the tasks it is graded on, and how it does on each.
  • Task → every trial of that task, so a result you cannot reproduce reads as a pass rate instead of a green checkmark.
  • Trial → one run: its trace, its score, its judge handoff.
Once a task goes green, the run-set that fixed it can be compared against the baseline run-set it replaced, side by side. A workspace with no agents yet shows the getting-started checklist instead: install the coach skills, connect the MCP, paste the quickstart prompt.

​
Runs

A run is a single task execution. The run page shows:
  • The full trace. Every tool call the agent made, in order: one row per LLM turn — model, tokens in and out, latency — with the tool calls nested under the turn that made them. Any agent that exports OTLP spans gets this, whatever framework it is built on.
  • The journal: the twin side of the same run, one row per call your agent made into the twin. Select a call that wrote and the step inspector opens a State diff — the twin’s state before and after that one call — alongside its request and response.
  • The score against the task’s acceptance criteria.
  • The judge handoff. A concise summary plus an actionable suggestion to fix or improve the agent. Use it as the next prompt back to your coding agent.

​
Twins

A catalog of twins, with a monitor for the sessions you start from it. The page opens on the catalog, grouped by category — Dev tools, Fintech, Communication, Project management — and searchable. A twin whose runtime is mounted in the cloud is marked available and can be selected; the rest are coming soon. Available today: GitHub, Stripe, Slack, Gmail, Linear, one page each under Digital twins. Select one and Start session boots it. Loading the page never starts a session on its own — sessions are real backend resources that cost money, so nothing spins up until you ask for it. One twin per session for now. A running session shows up above the catalog, and the Running stat at the top of the page counts them. Open one for the endpoints you point your agent at: the MCP URL, the API URL, and the bearer token every /s/<session-id>/… request carries. Stopping the session tears down the sandbox. Session lifecycle is also driven from the CLI via pome session create / list / stop.

​
How runs end up here

Anything that talks to the backend lands on the dashboard:
  • pome run <task> from the CLI.
  • Coach-driven runs over the Pome MCP — the pome-run-task skill, or any MCP client calling run_task and finalize_run itself.
  • Any agent you have registered with pome register agent, once it makes scored runs.
The CLI uses the API key from the macOS Keychain (preferred on macOS), ~/.pome/credentials.json (other OSes or when Keychain is unavailable), or POME_API_KEY (CI). See Quickstart for the login flow.

​
Open it

Or follow the dashboard link pome register agent prints when it registers the agent.

​
Next

Quickstart

Install the coach skills, connect the MCP, and put your first scored run on the dashboard.

CLI reference

pome run, pome register agent, pome session, and the auth env vars.