--- title: "How the ADE works: from one prompt to production · Frazer" description: "Follow one piece of work through the Frazer app, step by step on the real screens: one sentence, a session on a devbox, a fan-out to 1,000 modules, review and CI, your approval, a deploy and production." url: https://frazer.ai/ade/how-it-works index: https://frazer.ai/llms.txt tokens: 3556 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # How the ADE works: from one prompt to production · Frazer **ADE** How it works # 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. [Start building](https://frazer.ai/start?product=app) [Tour the app](https://frazer.ai/ade/tour) The walkthrough 8 steps · one piece of work 1. [01 Idea: one sentence](#idea) 2. [02 A session: on a devbox](#session) 3. [03 Fan out: one prompt, 1,000 items](#fan-out) 4. [04 Agents work: with Knowledge and skills](#agents) 5. [05 Review and CI: before it reaches you](#review) 6. [06 You approve: in one Inbox](#approve) 7. [07 Deploy: Kubernetes or serverless](#deploy) 8. [08 Production: watched by Frazer Monitoring](#production) 01 · Idea step 1 of 8 · Fig. 1 ## 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. *Home in the Frazer app, demo organization Acme: “What should we build, lena?” with lena’s request typed into the composer: upgrade pgx to v5.7 in inventory and keep its public API, then do the same everywhere we use it. Under it the pickers: the model route balanced, the Frazer agent, the devbox lena-api and Plan first switched on; then quick actions for a new session, a new fan-out, a deploy, opening a box and a new agent.* **Fig. 1** Home in the Frazer app, with lena’s request product UI, demo organization 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 02 · A session step 2 of 8 · Fig. 2 ## 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. *A session in the Frazer app on the devbox lena-api, demo organization Acme. lena asked to upgrade pgx to v5.7 in inventory and keep its public API, then do the same everywhere. The agent read the connection-pooling decision from Knowledge, edited six files, ran 212 tests on the box and fixed a leak the Frazer Reviewer reproduced, all collapsed into one activity row. It reports that 1,000 Go modules in 214 repositories still use the old driver and offers a fan-out: a catalog query, the request as a template, a dry run on three items, and a budget of $1.50 per item and $400 for the run. The side pane lists the changed files, the Knowledge used and the test run.* **Fig. 2** A session on lena-api, ending in an offer to fan out product UI, demo organization 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 03 · Fan out step 3 of 8 · Fig. 3 ## 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. *A new fan-out in the Frazer app, demo organization Acme, set up from the session “Upgrade pgx to v5.7”. A: a prompt template with six variables (module, test command, path, branch, repository, owner), five resolved on every item and the owner missing on two. B: 1,000 items from a catalog query, Go modules in 214 repositories that use pgx below v5.7, each checked as ready, a major-version jump or without an owner. C: how it runs: the Frazer agent, one headless session per item, on the Standard image; the balanced route with its own run key at batch priority; 100 sessions at a time; $1.50 per item and $400 for the run; draft pull requests on the Agent PR lane at 40 an hour; waves of a dry run on 3, then 10 %, then the rest. D: the three dry-run items, the smallest, the largest and a random one, and the checks before anything starts: quota, the gateway budget, the Agent PR lane’s runner-minutes, grants and the armed kill switch.* **Fig. 3** A new fan-out: A prompt template · B items · C how it runs · D dry run and checks product UI, demo organization 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 04 · Agents work step 4 of 8 · Fig. 4 ## 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. *A fan-out run in the Frazer app, demo organization Acme: pgx v5.7 across 1,000 modules, running, wave 3 of 3; 412 of 1,000 finished, an ETA of about 2 hours 10 minutes, $163.20 of a $400 budget, 31 of 214 draft pull requests open. A: seven buckets: 64 done, 318 need review in 5 clusters, 212 wait on lena in 3 batched asks, 96 running of 100 slots, 280 queued, 19 failed, 11 skipped. B: results grouped by outcome, with the verifier’s passes and the Reviewer’s findings per cluster. C: waiting on you: 174 sessions ask the same question about the pgxpool tracer, answered once for all of them. D: limits: concurrency 96 of 100, the gateway run key at $163 of $400, the Agent PR lane with 1,140 runner-minutes left; the waves, the item rate and the armed kill switch.* **Fig. 4** The run: A seven buckets · B outcome clusters · C questions asked once · D limits product UI, demo organization 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 05 · Review and CI step 5 of 8 · Fig. 5 ## 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. *Triage of the fan-out run pgx-v57 in the Frazer app, demo organization Acme. On the left, 318 results that need review in five outcome clusters, then what is decided: 64 accepted and 19 failed. A: the open cluster, “Import bump only, tests pass”, 196 items in 58 repositories: each changed only go.mod and go.sum, its tests passed, the verifier from another model family passed all 196 and the Frazer Reviewer found nothing. B: the representative, the median diff, bumping pgx from v5.5.0 to v5.7.4. C: a spot check of three random members, all the same change. D: accept the cluster, and open 58 draft pull requests in batches on the Agent PR lane at 40 an hour; three escalations wait for a person.* **Fig. 5** Triage: A cluster · B representative · C spot check · D pull requests in batches product UI, demo organization 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 06 · You approve step 6 of 8 · Fig. 6 ## 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. *The Inbox in the Frazer app, demo organization Acme: 9 open, 5 need lena. Needs you now: 174 sessions of the pgx run ask one question, answered once for all; a staging deploy plan to apply; lena’s assistant asking to email an outside sender; noah’s production deploy waiting for a second person; the Frazer Reviewer’s findings on a pull request. Earlier today: the run’s digest, a high security finding on a deployed image and the LLM budget at 80 %.* **Fig. 6a** The Inbox in the Frazer app *An approval in the Frazer console, demo organization Acme: “Delete database acme-reports-old” in staging, destructive, waiting for a person and expiring in 12 minutes. Requested by Kenji S. through Claude Code with the MCP tool databases.delete. It needs approval because destructive tools always wait for a person. The plan: a final backup, removing the database from the environment repository by a merged pull request, deleting the cluster, keeping the volume for 7 days and the backups until their retention ends. The approver can deny or approve and apply; the passkey is asked for if they last confirmed more than 10 minutes ago, and the plan is void if the database changes first.* **Fig. 6b** An approval, as the approver sees it in the console 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 07 · Deploy step 7 of 8 · Fig. 7 ## 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. *The deploy sheet in the Frazer app for inventory, demo organization Acme, from the session “Upgrade pgx to v5.7”. Kubernetes is recommended because inventory already deploys from envs/staging in acme/platform-envs with Frazer GitOps; serverless, a model endpoint, a GPU pod and an agent are the other choices. The service runs on the cluster acme-staging on Acme’s pool, rolls out as a canary from 10 to 100 percent and stays internal; it keeps its Postgres database, memory store, secrets by reference, uptime check and dashboards. The plan is a Git pull request with five changes; all five checks pass, from CI on GitHub runners to the Reviewer’s pre-check; it adds $0.00 a month on Acme’s servers and applies as lena, on behalf of the Frazer agent.* **Fig. 7** The deploy sheet for inventory: Kubernetes, as a Git plan product UI, demo organization 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 08 · Production step 8 of 8 · Fig. 8 ## 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. *Cloud in the Frazer app, team view, demo organization Acme: everything lena’s team runs in acme-staging, with state, last change, monthly cost and security findings; inventory is healthy after rolling out pgx v5.7 nine minutes ago. Alerts and events list a latency alert on pricing-api and the inventory rollout. The side pane shows inventory: 380 requests a minute, 0.1 % errors, p95 96 ms, uptime checks; its deploys, with the Frazer Reviewer watching the rollout for 21 more minutes and finding no regression, and a rollback one plan away; CI on GitHub runners, the signed image with no critical findings, and its secret references.* **Fig. 8** Cloud, team view: inventory after the rollout product UI, demo organization 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 The ADE ## Keep going. - ### [A thousand sessions](https://frazer.ai/ade/sessions) Fan-out, waves and budgets, where sessions run, and how results come back. - ### [Stay in charge](https://frazer.ai/ade/control) Approvals, budgets, guardrails, grants and Secrets, audit and the kill switch. - ### [Tour](https://frazer.ai/ade/tour) Twelve screens of the Frazer app, and every way into the ADE. ## Start with one sentence. Keep every decision. [Start building](https://frazer.ai/start?product=app) [How a thousand sessions work](https://frazer.ai/ade/sessions)