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]: spending limits 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

Budgets are denominated in satoshis, not dollars. A budget stops a run when its recorded spend reaches max_sats. The run can spend somewhat more than max_sats before it stops, and a stopped run fails. A declared budget makes a pod easier 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 declare which tools the directive may call with tools_allowed / tools_denied (not enforced yet). The declarations travel with the pod, so a reviewer can read pod.toml and see what it declares it will 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 and what it recorded the run costing. You can re-verify proofs offline with konareef verify. 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 piece of work with a spending limit. A publisher can choose to keep a pod’s internals closed. See the pod.toml visibility field. 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 — pod.toml declares a pod’s secrets, tool access, and budget up front, so a reviewer can read these boundaries before a run.
• 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 declared budget and boundaries. The developer authoring docs cover that path. The Quickstart gets you to a validated pod first.