Bring your own keys · zero token markup · runs on your provider bill

AI workflows that finish—
even when you step away.

Turn an objective into a tracked, resumable execution plan. A-to-Mind runs each step, enforces token budgets, and preserves state so you can pause, inspect, and continue without losing context.

$ npx a-to-mind run release-note \
    --repo acme/payments \
    --budget-usd 2 \
    --approval-mode required
import { AtoMind } from '@a-to-mind/sdk';

const run = await new AtoMind().run({
  repo: 'acme/payments',
  budgetUsd: 2,
  approvalMode: 'required',
});

Plan → Approve → Run → Ledger

Every run ships with an immutable execution trace: plans, approvals, model calls, tool calls, costs, retries, and artifacts.

Watch a run — pause at the approval gate

Hit play. The executor runs each step under a signed, least-privilege grant and halts at the Slack write, waiting for your approval before anything externally visible happens. That is the human-in-the-loop guarantee, live.

tokens 0 cost $0.0000 cap $2.00 elapsed 0.0s

SAMPLE RUN — canned data. The production engine executes real workflows through this exact trace format.

What one run looks like

“Monitor competitor pricing every morning, summarize material changes, write a Markdown report, and notify Slack only when thresholds are exceeded.”

Illustrative trace: the figures below are a canned example, not a live or verified run.

objective   Monitor competitor pricing daily and alert on material changes
plan        4 steps · approved policy: read-only + slack.write behind approval gate

step 1      fetch pricing pages          http.read       1,842 tok   $0.004
step 2      extract & diff prices        file.transform    963 tok   $0.003
step 3      summarize material changes   model.call      2,107 tok   $0.006
step 4      write report.md              artifact            0 tok   $0.000
            > threshold hit (+4.2% on 2 SKUs) - slack.notify awaiting approval

result      report.md (sha256 9f2c…e81b) - 15.4s total - $0.013 of $2.00 cap
status      succeeded - full ledger exported to run_01H8X.json
Step through this run on the demo page →

Human-in-the-loop, inside your tools

Approval gates surface where your team already works — no new dashboard required to say yes or no.

Slack approval prompt

A
a-to-mind wants to take an action
Run release-note wants to post to #releases. Approve within the policy window?

CLI approval

$ atomind watch run_01H9K
approval required: slack.write → #releases
$ atomind approve run_01H9K --step post
granted · step resumed · message delivered

Policy, configured in code

Spend caps and a default-deny tool allowlist are part of the run spec — versioned and enforced server-side, not in client code.

{
  "budget":    { "usd": 2, "tokens": 50000, "toolCalls": 20, "retries": 3 },
  "tools":     { "mode": "deny-by-default", "allow": ["http.read", "git.read", "slack.write"] },
  "approvals": { "requiredFor": ["slack.write", "deploy.*"] }
}
const policy = {
  budget:    { usd: 2, tokens: 50000, toolCalls: 20, retries: 3 },
  tools:     { mode: 'deny-by-default', allow: ['http.read', 'git.read', 'slack.write'] },
  approvals: { requiredFor: ['slack.write', 'deploy.*'] },
};

Control guarantees

Approval gates

Every external write, deploy, or publish waits for explicit human approval — enforced server-side, not in client code.

Default-deny tool permissions

The executor can only touch tools on a per-run allowlist you control. Nothing else exists to it.

Hard budget caps

Dollars, tokens, tool calls, elapsed time, and retries have hard ceilings enforced by the platform. Exceeding them fails the run safely.

Durable checkpoints

Runs survive restarts and crashes. Pause, resume, or retry without duplicating external side effects, using idempotency keys throughout.

Audit-grade run ledger

An append-only record of every decision, model call, tool effect, and artifact — exportable as JSON.

Immediate cancel

Cancel and pause are honored server-side, mid-step. Cancellation is itself an audited event.

How it works

StageWhat happens
DefineYou submit an objective, expected artifact, tool allowlist, budget, deadline, and approval policy.
Review planA planner proposes discrete steps. You inspect and approve the plan before anything runs.
Set policySpend caps, tool permissions, and approval gates are locked to the run and versioned.
ExecuteEach step runs under signed, least-privilege grants with its own budget and idempotency key.
EvaluateA separate evaluator checks structured acceptance criteria against artifacts and decides accept / reject / escalate.
Export or resumeGet a full JSON run report, or resume from the last checkpoint after fixing inputs.

Launch templates Read-only

All launch templates listed here are read-only engineering specs. Business packages (Glass-Box, Surface Ledger, Promise Ledger, Adversarial Twin, Hostile Mirror) stay on their playbook URLs until an approved first-party run exists. This table does not sell a notify gate.

TemplateOutputAuthority
Release-note generatorMarkdown notes from a tag rangeRead-only
GitHub Actions security auditFindings plus suggested patchRead-only
Cloudflare deployment reviewDeployment-risk reportRead-only
Pull request reviewReview comments and patch suggestionRead-only
Incident research briefCited decision briefRead-only
Documentation drift auditGaps plus proposed updatesRead-only
Dependency change impact reportAffected services and risksRead-only

Integrations & extensibility

GitHub

Repository reads, PR reviews, and issue analysis. Writes arrive later, behind approval gates.

Cloudflare

Workers, Pages, KV, D1, R2, and DNS inspection. Deployment diagnostics, initially read-only.

Slack

Run notifications, approval requests with one-click decisions, final reports.

Your APIs

Register scoped, schema-validated internal HTTP/OpenAPI endpoints as tools.

CLI & TypeScript SDK

Create runs, watch progress, approve steps, cancel, and export reports from your terminal or code.

Webhooks

Signed events with retries and event IDs for run lifecycle milestones.

Architecture: a state machine, not a chat loop

Tasks are durable state machines, persisted across our global edge network — not fragile chat loops. Execution is bounded by construction: hard limits, validated state transitions, checkpointed progress, and an append-only ledger. If a worker dies mid-run, the run resumes from its last checkpoint. If a step fails, the evaluator classifies why and whether a retry is safe. The same properties make runs diagnosable when they succeed and useful when they fail.

Volatile chat loop

user → model → tool
↓ state kept in memory only
model → tool → model
↓ process crash = everything lost
no checkpoint · no budget · no gate
loses stateuncappedno audit

Edge-persisted state machine

queued → planning → approved
↓ checkpointed on the edge
running (signed grants) ↔ paused
↓ survives restart & resume
succeeded · ledger exported
checkpointingsigned grantsedge executionaudit ledger

What we will not do

Pricing

Usage-based by default. Connect your own model keys and pay providers directly at provider cost. The platform charges for orchestration, governance, and retention — never a token markup.

Free

$0/month
  • Sandbox runs with mocked tools, full trace
  • Execution limits: 1 concurrent run, $2.00 max spend per run
  • 3 run reports kept 7 days, then deleted
  • Community support
Try the sandbox

Pro

$29/month + provider usage
  • Higher execution concurrency and priority capacity
  • Audit ledger kept 90 days (vs 7 on Free)
  • Team roles, shared budgets, spend alerts
  • API, CLI, webhooks
  • Priority support
Talk to us

Hard spend caps are enforced server-side on every tier regardless of plan. No surprise charges: a run that hits its ceiling fails safely with budget_exhausted in the ledger.