What a plan task really produces: a real receipt, annotated

Peragam is in early access, and exactly one task type is live: planning. That is a strange launch post to write in an industry that announces twelve capabilities at a time. But the one capability comes with something the twelve usually lack: a receipt. This post walks through a real one, field by field.

A note on the example first. The receipt below comes from our seeded demo workspace, a fictional company called Northwind that every new environment starts with. It is real platform output produced by a real run. It is not a customer, because we do not have launched customers yet, and we would rather show demo data honestly than dress it up as traction.

What a plan task is

You give Peragam a business idea in plain words. A plan task turns it into a goal tree: up to 100 goals, nested at most 6 levels deep, each with a status and a written rationale. Alongside the tree, the agent may propose up to 25 advisory follow-ups, such as research or build tasks that would advance a leaf goal. Advisory means exactly that: in the current slice, suggestions do not execute anything on their own.

Before the agent starts, the platform freezes your brief into a versioned prompt and records its SHA-256 hash. That happens before any credit is reserved. If you ever dispute what the agent was asked to do, the hash settles it.

The receipt, field by field

When the run finishes, a verifier checks the output. Only then does the platform write the receipt. Here is what the demo receipt says, and what each line means.

Check: output matches plan contract v1. The verifier does not ask the agent whether it did a good job. It parses the raw output against a versioned JSON contract: the goal-tree shape, the node limits, the nesting depth, the follow-up cap, unique titles among siblings, no extra keys. Parsing is binary. The output either satisfies the contract or the task fails.

Goals: 14 goals, 3 levels. What the parser actually found. This is evidence, not summary: the verifier writes what it observed, and a field with nothing observed stays absent. Receipts on this platform never invent evidence to look complete.

Cost: $0.71. Tokens: 12.4k in, 3.1k out. The full model and sandbox cost of the run, in dollars and tokens. You pay in credits, not dollars, but we show the underlying cost anyway. If you are going to trust a platform's pricing, you should get to see what the work costs it.

Credits charged: 1. A plan task weighs one credit, and the charge exists only because the check passed. Settlement is atomic: the credit charge and the verification verdict are one step. Had the contract check failed, this line would read zero and the ledger would hold no charge to refund.

Verified: the timestamp. Written by the platform when the check completed. The agent that produced the plan has no write access to receipts, task status, or the ledger. Done is a verdict it can earn but not declare.

What the check does not prove

Honesty requires the other half. The contract check proves the plan is structurally valid and complete. It does not prove the plan is wise. A goal tree can parse perfectly and still recommend a mediocre strategy, the same way a compiling program can still be wrong. Judging the substance of a plan stays your job, and the receipt is built to make that judgment cheap: the rationale for every goal is right there.

This is the standard we are committing to for every capability that follows. Deploys will verify against a live URL answering with a screenshot captured. Outreach will verify against provider receipts. Each of the eleven remaining task types ships when its verifier does, and not before. The full lifecycle, from brief to isolated machine to settlement, is documented on the product page.

One capability, fully proven, felt like the right way to launch. The alternative was twelve checkmarks we could not stand behind.