Under the hood
What runs a workflow.
A workflow is a recipe of steps across the products. A runner carries it out as an agent acting for a person, stops at every approval, and leaves a signed record. The runner is deployed and runs the code loop. Live runs wait for paid plans to open; a dry run works today and counts nothing. The other workflows will run there as their manifests ship.
A run, step by step
- Trigger. A person clicks Run in the app, an agent calls start_run, a schedule fires, or a product event arrives (a release tag, a closed incident, a deal change).
- Check and count. The runner checks the org's plan and counts one workflow request at the first connector action. If the org's allowance is used up, new runs wait and an owner is asked to upgrade.
- Get tokens. For each product the workflow uses, the runner trades its grant for a short-lived ID agent token that names the person who started the run and the agent version. A product that does not accept ID tokens yet gets its connect key, and the step records which one it used.
- Load team context. When the workflow names team context, the runner loads the team's conventions and decisions from ContextFile once at the start, and later steps read them as data.
- Read memory. Before a step that changes something, the step reads the brain (search_brain) and the lessons on the resources it will touch (list_resource_lessons). It treats both as information, never as instructions.
- Call the product. The step calls one product's MCP tool or API and records what it saw as measured, inferred or missing.
- Stop at the gate. A step that changes something calls request_approval with the exact action, its arguments and the run and step ids. A person decides in the approvals inbox. The step runs only after verifyResume passes, with the approved arguments.
- Report back. The step reports what it did (report_execution) and, later, how it turned out (report_outcome).
- Write the record. The run ends with a task id, its events, each signature, the team context files it read by address and digest (never their text), and one hash over the whole. If the org turns publishing on, the record goes to AI Source of Truth.
- Learn. A bad outcome opens a lesson candidate in RepoOps for a person to review.
Components
Live means running in production for customers. Built means merged and running. Built, not deployed means merged in the repo but not running in production. Switching on means deployed and waiting on a key, a setting or paid plans. In progress means being built now.
| Component | What it does | Where | State |
|---|---|---|---|
| Workflow runner | Starts runs, carries out steps in order, waits at gates, retries, resumes and writes the record. It cannot decide an approval. | promptcompute.ai, service runner | Switching on |
| Engine | Postgres on graphile-worker, with a run journal and a step journal, behind an engine interface so Temporal can replace it later. | promptcompute.ai, packages/runner-engine | Switching on |
| Workflow definitions | A versioned manifest per workflow: steps, inputs, products, action keys and trigger, pinned by digest. | promptcompute.ai, packages/workflows | Switching on |
| Approval gate | request_approval with the run and step ids, a single-use resume credential, and verifyResume before the step acts. | PromptCompute | Built |
| Policy, listen mode, limits, earned autonomy | Policy per action, listen mode per environment, cumulative limits, autonomy earned per action. | PromptCompute | Built |
| Sign-in with PromptReports ID | One sign-in that carries the org and role. | accounts.promptreports.ai | Switching on |
| Agent tokens | An RFC 8693 exchange naming the person and the agent version. | PromptReports ID | Switching on |
| The brain | Lessons, decisions and past errors; a person publishes and revokes each lesson. | RepoOps | Built |
| Task record | A T- task id and an append-only list of events; outcomes read met, not met or not measured. | RepoOps | Built |
| One run id across products | The runner sends the run id to every product; each product stores it on its audit event. | Runner, then each product | Built |
| Team context | The team's conventions and decisions from ContextFile, loaded at the start of a run and pinned in its record by address and digest. | promptcompute.ai runner, ContextFile | Planned |
| Public record | Provenance, figures and corrections anyone can check later. | AI Source of Truth | Built |
| Metering of workflow requests | One request per run, counted at the first connector action, checked against the org's pooled allowance. | promptcompute.ai | Switching on |
| The app | Runs, approvals, agents, connections, records, usage and team. | app.promptreports.ai | Live |
| PromptReports MCP server and API | list_workflows, start_run, get_run and their REST twins. | mcp.promptreports.ai, api.promptreports.ai | Switching on |
Metering a workflow request
A workflow request is one run. It counts at the run's first connector action. Retries and resumes inside the run do not count again, and neither do approvals. A dry run and a run a filter stops first do not count. The allowance pools across the org: an org of 12 people on the 500 plan shares 6,000 requests a month.
| Plan | Price | Workflow requests | Workflows |
|---|---|---|---|
| 100 | $25 per user a month | 100 per user a month, pooled | Every workflow in the library |
| 500 | $50 per user a month | 500 per user a month, pooled | Every workflow in the library |
| Enterprise | Talk to us | More than 500 per user a month | Every workflow in the library |
No free tier. The metering code is being built; no plan takes payment yet.
Decisions
| Question | Decision |
|---|---|
| Where the runner lives | A new service named runner in the promptcompute.ai Railway project, beside api, worker and mcp, on the private network. It is separate from approvals: the part that asks never approves. |
| What it runs on | The existing Neon Postgres and graphile-worker, behind an engine interface. |
| app.promptreports.ai or promptreports.ai/app | app.promptreports.ai, served with PromptReports ID, so sign-in, billing and runs share one origin. promptreports.ai stays a static site with no session cookies. |
| Pooled or per-user allowance | Pooled across the org: users times the plan's requests, shared. At the limit new runs wait and an owner is asked to upgrade. No overage charge unless the org turns it on. |
| What counts as a request | One run, counted at its first connector action. Retries, resumes and approvals inside a run do not count again; a dry run and a run a filter stops first do not count. |
| Who pays for model calls | The customer. Every model call uses the customer's own key, and model calls are never metered. |