What is a reefpod?

A reefpod is a portable, versioned AI-agent package. It bundles the directive, model, inputs, tools, budget, and definition of “done” to run an AI workflow safely and repeatably. It also produces a verifiable record of what happened.

Prompt vs. script vs. reefpod

A prompt tells an AI what to say. A script tells a computer what to do. A reefpod declares an AI workflow: which runtime and model it uses, what inputs it accepts, what it may spend, what counts as success, and what proof it leaves behind. It is a directory anchored by a pod.toml manifest, plus its prompt files and assets.

What a reefpod contains

my-pod/
  pod.toml          # identity, runtime, model, inputs, directive, output, budget
  prompts/
    system.md       # the directive template
  README.md

The pod.toml manifest ties it together:

• Identity — [pod]: name, version, description.
• Runtime & model — [runtime] and [model]: where and with what the pod runs.
• Inputs — [inputs]: typed, validated parameters.
• Directive — [directive]: the task or prompt template.
• Definition of done — [output]: success/failure predicates and deliverables.
• Budget — [budget]: hard caps in satoshis.

See the pod.toml reference for every field.

Where a reefpod runs

Reefpods run on a reef-core deployment, the authoritative runtime. You use the konareef CLI to author, validate, publish, install, and verify pods. The pod declares its own boundaries, so the same pod behaves the same way wherever it runs.

Why budgets are in satoshis

Runs are metered and paid over Bitcoin SV rails (through PayGate), so [budget] caps are denominated in satoshis, not dollars. A budget is a hard ceiling. The run stops rather than overspend. This makes a pod safe to hand to a teammate or to commission out to a client.

Why permissions live in the pod

A reefpod names the secrets it needs (by name only — the values come from the reef-core vault at spawn). It can also restrict which tools the directive may call with tools_allowed / tools_denied. The trust boundary travels with the pod, so a reviewer can read pod.toml and know exactly what it can touch and spend. The Security & trust page covers this in depth.

Why proof matters

Every run on reef-core yields a signed custody proof — cryptographic evidence of what reef-core recorded the pod as doing, what it cost, and that it stayed within the limits the manifest declared. You can re-verify proofs offline with konareef verify, so a commissioner never has to take a publisher’s word for the cost or the boundaries. The proof covers conformance, not the quality of the output.

Commissioning, not buying

Running someone else’s reefpod is not a purchase of their expertise. It is a commission. You pay per run, in satoshis, for a declared, budget-capped piece of work. The author’s prompts, tools, and technique remain theirs. You get the deliverable and a proof of how it was produced, not a transfer of the underlying IP.

That only works if you can trust a pod without a personal audit of its prompt. Three things carry that trust instead:

• konareef’s audit filter — the pod.toml schema forces every pod to declare its secrets, tool access, and budget up front. The runtime enforces those boundaries no matter what the prompt says.
• The publisher’s public reputation — a publisher identity signs every pod. Bad behavior is attributable, not anonymous.
• Pod history and provenance — versions are immutable and every run leaves a custody proof. So you can check a pod’s track record before you commission it.

See Security & trust for how these hold up even when the pod’s internals stay opaque to you.

How reefpods are shared

Once a pod validates, you create a publisher identity, sign the pod, and publish it. Commissioners install it, verify the publisher’s attestation, and run it — with the same budget and boundary guarantees the author declared. The developer authoring docs cover that path. The Quickstart gets you to a validated pod first.