Metercall lets users and agents run verified business workflows through terminal, MCP, and Kai — with dry-run previews, receipts, refusals, quotas, and audit proof before anything goes live.
Use the model for intent. Use Metercall for deterministic, governed workflow execution.
Private preview today. Dry-run / proof-only. No emails, SMS, calls, payments, CRM writes, or production mutations run — every action stays staged behind explicit execution rails and approval gates.
Start with Tree AR. Watch Kai build. Verify receipts. Then request pilot access.
Start with Tree AR. Watch Kai build. Verify receipts. Then request pilot access. Everything is dry-run / proof-only: no live sends, no live billing, no CRM writes, no workbook mutation, no production. Unsafe requests are refused, and every preview action leaves a receipt.
Local terminal preview works immediately. The online terminal stays gated behind email verification — and verification still does not unlock any live action.
The point is not to make every user think like an engineer. Intent can start from an agent, a terminal user, or a normal operator working directly in Metercall. A manager can describe the job in plain language, Metercall can choose the governed path, and an operator can review one approval packet before anything risky resumes.
An upstream agent, bot, or service hands Metercall a structured packet. Metercall takes over the governed part of the run.
A developer, founder, or operator can open Metercall directly, describe the workflow, and use the same governed runtime without another agent in front.
No prompt gymnastics. The request can come from an agent, a team lead, an ops manager, or a founder asking for a business result.
The model carries intent. The runtime chooses the audited path, applies the if/then routing, and keeps live mutations paused.
Instead of babysitting an agent, the operator gets one simple review surface: what was prepared, what stayed blocked, and what resumes next.
This is the product: event in, state carried forward, agent decision made on rails, governed workflow run, policy gate, approval, resume or halt, receipt, outcome, and the next workflow queued with proof.
Open one engineer-friendly workspace: inspect the source packet, click the routing branches, verify what stayed staged versus blocked, and read the receipt before anything risky moves.
source_agent: "revenue-expansion-bot" account_name: "Sunstate Roofing" phone: "305-555-0184" persona: "homeowner" business_owner: "YES_OWNER" intent: "route lead and prep follow-up"
route.region: "miami" route.persona: "homeowner" route.business_owner: true workflow.family: "crm_lead_intake" policy.live_mutation: "approval_required" state.duplicate: false
{
"source_packet": {
"source_agent": "revenue-expansion-bot",
"account_name": "Sunstate Roofing",
"phone": "305-555-0184",
"persona": "homeowner",
"business_owner": "YES_OWNER",
"intent": "route lead and prep follow-up",
"live_write_allowed": false
},
"normalized": {
"route.region": "miami",
"route.persona": "homeowner",
"route.business_owner": true,
"workflow.family": "crm_lead_intake",
"policy.live_mutation": "approval_required",
"state.duplicate": false
},
"routing": {
"market_pod": "miami_revenue_pod",
"lane": "homeowner_nurture",
"workflow_pack": "crm_lead_intake",
"owner_fast_lane": true,
"live_outreach_allowed": false
},
"receipt": {
"status": "approval_pending",
"blocked_actions": ["email_send", "sms_send", "crm_writeback"],
"next_queue": "miami_owner_review",
"receipt_id": "lead_route_305_a17"
}
}
Send Metercall an event or intent. Get back the governed workflow path, approval requirement, run status, and receipt.
Keep execution local-first and auditable. The model handles intent. The runtime handles state, workflow execution, approvals, and proof.
See why the agent chose each workflow, which actions stayed blocked, and exactly where a human gate is still required.
Use the model for intent. Use Metercall for deterministic workflow execution. The runtime chooses governed packages, carries state, applies approvals, and emits receipts instead of paying for fresh reasoning on every business step.
Metercall's deterministic-direct router answers from the local knowledge base — 0 tokens, 0ms — and cannot hallucinate a fact it reads straight from source. Your code, infrastructure schemas, and logic stay on the machine.
$ kaiai "what's blocked in preview?"[✓] answered locally · 0 tokens · 0ms→ blocked: production writes · real sends · payments $ kaiai compose "sync db with s3"→ routed to governed library · preview
This is the shelf behind the runtime. Search the governed library, map intent to the nearest business workflow, and keep the result preview-safe until approvals exist.
When an agent runs through Metercall, the runtime does not just dump logs. It emits a deterministic receipt that proves what executed, what stayed blocked, which gates were hit, and why the next action is safe or halted.
{
"workflow_id": "wf_deploy-and-notify_8f21",
"git_commit_sha": "4a68a074",
"mcp_servers_engaged": ["postgres", "aws-s3", "custom-billing-api"],
"external_mutation_performed": false,
"real_send_performed": false,
"mutations_blocked": true,
"tier": "PREVIEW_ONLY_RUNTIME",
"human_signoff_required": true,
"consumed_compute_credits": 42,
"audit_passes": 2,
"audited_by": ["kai-governor", "independent-recheck"],
"receipt_recorded": true
}
This is the product chain: event → state → agent decision → workflow run → policy gate → approval → resume or halt → receipt → outcome → next workflow.