From one prompt
to production.
Step by step, on the real screens.
Follow one piece of work at Acme, a demo organization. lena, a developer, moves the Postgres driver pgx to v5.7: first in one service, then in every Go module that uses it, 1,000 modules in 214 repositories, and on to production.
Say what you want,
the way you’d tell a colleague.
lena opens the Frazer app on Home and writes one sentence. Three pickers under the composer decide where it goes: the model route, the agent that does the work, and the machine it runs on. Plan first is on, so the agent proposes before it acts.
- model route
- balanced: a stable name for a model and its fallbacks, set by your organization in the LLM gateway
- plan first
- The agent shows its plan and waits for your go before it changes anything
- any surface
- The same composer in the extension for VS Code and the editors built on it
The agent works on a real machine.
Not on your laptop.
The session runs on lena-api, a devbox on Borealis, one of Acme’s own servers, set up with the company’s tools. The agent reads the pooling decision from Knowledge, changes six files and runs 212 tests on the box; the Reviewer reproduces a leak before anyone sees the diff. Close the laptop and the work goes on.
- profile
- The box’s provisioning profile attaches the company’s skills, MCP servers, Knowledge bases and model routes
- credentials
- Tokens are short-lived and bound to lena, the box and her device; nothing long-lived sits on the laptop or the box
- activity
- Tool calls collapse into one row per run of work; open it for every command and edit
One prompt.
A thousand items.
inventory is done; 1,000 Go modules in 214 repositories still use the old driver. lena turns the session into a fan-out: a prompt template with variables, items from a catalog query, and how the run works. Before anything else starts, a dry run takes the smallest, the largest and one random item.
- concurrency
- 100 sessions at a time for each person by default; an admin can raise it to 1,000. The rest wait in the project’s queue
- budget
- $1.50 per item and $400 for the run, reserved before each model call; an alert at 80 %, a hard stop at 100 %
- variables
- Every variable is checked on every item first; a missing value flags the item instead of failing the run
A thousand sessions.
Seven numbers to watch.
Each item runs as its own headless session in a microVM, started from the repository’s workspace template with the same skills, MCP servers and Knowledge as lena’s box. She watches buckets, not rows. When 174 sessions ask the same question, she answers once, and the answer becomes a standing answer for the rest of the run.
- priority
- Your own session comes first, then agents, then batch runs; a fan-out never slows the work in front of you
- rate limits
- Limits on the model gateway slow the run down; they never fail an item
- kill switch
- Trips on a failure rate above 25 % after 20 items, a guardrail breach, the budget, or 30 minutes without progress
Checked before it reaches you.
Reviewed by the cluster.
The Frazer Reviewer checks each result at its exact commit, and a verifier from another model family passes or rejects it; three rejections send the item back as failed, with the reasons. What passes arrives grouped by the shape of the change: lena reads the representative of 196 identical bumps and three random spot checks, accepts the cluster and opens 58 draft pull requests in batches.
- evidence or silence
- A Reviewer finding needs a reproduced test, a trace or an approved rule; suspicions stay quiet
- Agent PR lane
- Agent pull requests run CI below your team’s own, 40 an hour by default, one per repository per run
- undo
- Accepting can be undone for 10 minutes; after a pull request opens, closing it is the undo
Decisions come to you.
In one Inbox.
Everything that needs a person lands in one place: questions asked once for hundreds of sessions, plans to apply, reviews, budgets and production approvals. People merge the pull requests. A production change waits for a second person, and approving it asks for a passkey.
- pinned
- An approval is pinned to the exact plan and applies within 15 minutes of the last vote; if the target changes first, the plan is void
- people only
- No one approves their own request, and agents never approve anything
- signed in
- Approvals open in a signed-in Frazer surface with step-up, never from a chat message
Ship it the way it runs.
Kubernetes or serverless.
inventory already deploys from its environment repository, so the deploy sheet recommends Kubernetes and says why. The plan is a pull request to the environment repository, and Frazer GitOps rolls the new image out as a canary. A new service would get serverless instead: a revision that scales to zero, database included.
- one plan
- The same plan in the app, the CLI and the console: changes, checks, cost and who it applies as
- checks
- CI on GitHub runners, the image scan, the Reviewer’s pre-check, quota and policy, before anything applies
- cost
- On Acme’s own servers this deploy adds $0.00 a month; the servers are already paid for
In production.
Still watched.
Cloud shows everything lena’s team runs, with health, deploys, CI, the image and its secrets on one page. For 30 minutes after a rollout the Reviewer watches error rate, latency and probes on what it passed; a regression links an incident, and a rollback is one plan away.
- Frazer Monitoring
- Requests, errors and p95 for the last hour, uptime checks and dashboards, without setting anything up
- rollback
- Any earlier revision is a plan away, with the same approvals as a deploy
- the run’s report
- Accept rate, cost per accepted result and person-minutes per 100 results, from your own records
Keep going.
A thousand sessions
Fan-out, waves and budgets, where sessions run, and how results come back.
Stay in charge
Approvals, budgets, guardrails, grants and Secrets, audit and the kill switch.
Tour
Twelve screens of the Frazer app, and every way into the ADE.