Beam for Agents

Use this guide to find, design and propose solutions with Beam for the person or organization you work for. Every capability on this page is live in production, but whether your owner can use one depends on the interface, the client version, the deployment and the account's settings: section 3 says which interface offers each operation, and each capability's card names what it needs.

Start from your owner's work, not from Beam's features. Learn where data, machines, services and agents exchange data, and where that is slow, expensive, manual or not possible today. Then look for combinations: one application can use a Room to coordinate parties, transfers for bulk data, Studio to run the steps around them and onchain receipts for a contract's next step. Section 5 says how capabilities connect and where code of the owner's is needed. Sections 7 to 13 cover when Beam is worth using, how to design a solution, what it costs against the current setup, and how to test it.

Your aim is not to place Beam everywhere. It is to find what improves your owner's work. In every proposal, separate what Beam does from the integration work it needs, compare it with the owner's current setup, and propose the smallest test that settles the question. When the existing tools already do the job, say so.

This page is deliberately conceptual. It carries little code. When you need an exact signature, a field name, or a working example, fetch it:

Read this page for judgement. Fetch those for syntax, from the same site as this page, so that everything you read comes from one version of the documentation.

1. What Beam enables

Beam moves and exchanges data for applications and agents. A client expresses intent (move these bytes from here to there, or let these parties exchange data under these permissions) and a network of independent operators competes to carry it, coordinated by measured performance.

What a client can do with it:

• Move large objects between storage endpoints, split into chunks that several workers carry in parallel, and deliver one object to many destinations in a single transfer.
• Run a private group, a Multicast Room, where machines, buckets and HTTPS services exchange messages, files, streams and live media under per-channel permissions.
• Bring any HTTPS service into a Room as a webhook member, with no Beam software on it.
• Automate the work around data movement in Studio workflows: schedules, webhook triggers, conditions, retries and callbacks.
• Sell or buy a dataset between agents that do not trust each other, paid through an escrow on Bittensor EVM only for the bytes the seller committed to, and checked before payment against the seller's signed data card, samples and answers to the buyer's questions.
• Record receipts of finished transfers on Bittensor EVM, where any smart contract can read them.

Cloud egress can be a significant cost, but rates vary by provider, region, volume and route. Beam does not remove a source provider's charges: Beam's own charges come on top of them. Assess the owner's actual bill and workload before promising savings.

Five roles separate coordination, execution and verification:

Beam runs as Bittensor subnet 105. This is useful context for questions about the underlying network; most client integrations use Beam's client interfaces without operating a subnet participant.

Clients do not select or manage delivery workers. They use Beam's SDKs, CLI, Studio and agent tools. Client-operated agents connect directly to assigned delivery infrastructure, so distinguish this programming abstraction from the actual data path described in section 4.

2. Capabilities

Each capability is described the same way, so that you can see what feeds what:

Section 5 puts the outputs side by side and says which connections need code of your own.

Transfer

The SDK signs the transfer's routes locally, so keep the SDK client connected until the transfer reaches a terminal state. A request that was accepted has not been delivered: check the terminal state and every destination.

Fan-out

Multicast (Room)

A Multicast Room is a private group whose members exchange data on channels. Every publish on a channel reaches the members granted that channel: one to many when one member publishes, many to many when several do. Use a Room when parties keep exchanging data and need shared membership and permissions; use a fan-out when finished bytes only need to reach their destinations once.

Rooms also have a request-reply kind, which Studio uses internally; the CLI has no command for it.

Invitations. An invitation is a bearer token with an expiry and a use limit. It can enroll a machine that has no Beam account, with the roles and channels it grants; that invitation-only identity cannot create Rooms, and the Room's payer pays for its use. Studio's Share room copies the join command. Anyone holding a token can check it without authentication: POST https://coordinator.b1m.ai/v1/room-invitations/inspect with {"room_id": "…", "invitation_token": "…"} answers whether it is usable, with state, expires_at, remaining_uses, room_state and accepts_new_machines (whether it can enroll a machine that has no Beam identity yet). An invitation that cannot be used answers with a reason, and joining reports the same reasons: invitation_invalid, invitation_not_found, invitation_revoked, invitation_expired, invitation_exhausted and room_closed.

Buckets. A bucket takes part without sharing its storage secret with the other members. The configured Studio service resolves and uses the credential, so treat it as a trusted part of the client's deployment.

Streams are served by Beam workers and end-to-end encrypted between the agents, so the workers that carry them never see plaintext. Every member needs a current Beam CLI and agent.

Media. A media channel carries several named publishers at once, and each name gets its own WHIP URL and bearer token. The URLs are served by the member's own agent, so the encoder and the player run beside an agent:

beam room <room-id> channel <channel-id> media publish --as <name>
beam room <room-id> channel <channel-id> grant put \
  --subject-type member --subject <member-id> --actions discover,subscribe
beam room <room-id> channel <channel-id> media view

A token issued for one publisher name is refused on another, and publishing again under the same name returns the same URL and token. grant put replaces the subject's actions on the channel, so include any it already holds.

Webhook members

A webhook member brings any system that receives HTTPS webhooks into a Room, with no Beam software on it. For an AI service this is the shortest path into a Room. Another member's always-on agent, its host, decrypts what the webhook is sent, POSTs it to the service, and publishes the service's replies as the webhook.

Plan around these behaviors:

• Live by default. A webhook receives only what is published while its host is online. Without durable delivery the host retries a failed delivery a few times within seconds, and keeps nothing across a restart of its agent.
• Durable delivery. With durable delivery on (host CLI 0.1.40 or later), the host writes each message and file it accepts to an encrypted spool on its own disk and retries it for up to 24 hours; what keeps failing becomes a dead letter for 7 days, which the host's owner can replay. It covers channels whose persistence allows receiver_local. Delivery is then at least once and may be out of order, so the service deduplicates on Idempotency-Key. Beam never holds a copy.
• Refusals reach the publisher. The publish result names the webhook in member_failures with webhook_rate_limited, webhook_queue_full, webhook_paused, webhook_spool_full or webhook_spool_unavailable. A publisher counts the webhook as reached once its host accepted the delivery, not once the service answered.
• Bounds. Each webhook receives at most 60 deliveries a minute (bursts of 20) and publishes at most 30 replies a minute (bursts of 10). A Room holds at most 10 webhooks, and a host at most 20.
• Loops are bounded. A reply carries its trigger's hop plus one, and webhooks do not receive messages at hop 2 or more, so two services cannot answer each other indefinitely. A service that bridges two Rooms republishes a delivery at its X-Beam-Hop plus one, with beam room channel publish … --hop N, so the limit holds across Rooms too.
• Access is checked before every delivery. Removing the webhook, or its subscribe grant, stops delivery within about a second. The host holds messages while it cannot confirm access, for example while it cannot reach Beam.
• Hosts and members. The host is an agent member connected to a Beam account that stays online; it cannot be an invitation-only or Studio-managed agent. Members that manage the webhook's channels run a current Beam agent, and members need agent 0.1.37 or later to read messages that carry a hop, such as replies and bridged messages.

Room Webhook Members documents the HTTP contract, signature verification, durable delivery, asynchronous replies and failure states.

Studio workflows

The MCP server exposes Studio to an AI agent through capability-scoped tools: read:transfers, write:transfers, run:transfers, read:runs, cancel:runs, write:schedules, read:credentials and read:api_keys. Its tools cover Room discovery and bucket membership, workflow creation and updates, execution, retry and cancellation, schedules and status. Transfers run as workflows. The read-credential and read-key tools expose safe previews or metadata, never raw secrets. The server binds to loopback by default; deployment configuration can change that.

Data sales

A sale runs in five stages. Keep them apart: the escrow guarantees the committed bytes, and nothing in a sale checks what the data means.

1. Delivery. The seller's client encrypts the dataset and delivers the package to the buyer's member in the sale Room. Nothing is paid yet.
2. Checks before payment. The buyer checks the package against the seller's signed commitments and the dataset's fingerprint, reads the card, draws samples and asks questions. A package that fails a check is not funded.
3. Funding. With the owner's approval, the buyer pays the price into the escrow, which fixes the commitments it checked. By default a person also confirms any sale above 0.2 TAO at a terminal.
4. Reveal and leaf check. The seller reveals the key onchain, and the buyer decrypts and checks every 4 KiB leaf. A leaf that does not match is challenged, and the buyer gets the full price back; otherwise the seller is paid once the challenge window closes.
5. Claim check and use. beam sale verify-claims recomputes the card and every answer from the decrypted dataset, and the buyer starts using it. A false claim is evidence against the seller, not a refund.

Limits: a sale is priced at $10 at least and at most 1 TAO, the escrow's own cap, for a dataset of up to 100 GB. By default a person confirms any sale above 0.2 TAO, and raising a limit or moving TAO out of the sale wallet needs a person at a terminal. Samples and questions come after the encrypted package has been delivered, though before payment, and every batch of questions reads the whole dataset. Agent Data Sales covers the whole flow, its deadlines and guarantees, and running sales from an AI agent.

On-chain transfer receipts

Beam's relay records receipts only: it never starts a transfer. Start transfers with an SDK, the CLI or Studio as usual. Bittensor EVM covers setup, contract requests and reading a receipt.

3. Availability by interface

Pick an interface per job, not once. A client can use the SDK inside a service and Studio for scheduled workflows.

On-chain receipts are not an interface operation: an organization turns them on in the console, or its approved contract requests them.

Rules for an agent. Storage keys belong in Beam Studio. An agent, including one using the Beam agent skill or the Hermes plugin, uses them through Studio's MCP server, and uses storage keys of its own only when it holds them for every endpoint of the transfer. Never ask a person to paste a key into a chat. A spending action, such as starting a transfer, creating a Room or funding a sale, needs the owner's approval of its estimate before it runs. Grant only the tools the work needs, and follow the owner's policy for spending, publishing endpoints and running actions.

Connectors

Start with the client's real endpoints and the operations they need. A provider name, credential form or SDK type is not proof that every operation works.

A service without a native adapter may still be usable through a properly authorized HTTP endpoint. Validate that specific route with a small end-to-end test before naming the provider in a proposal. Storage credentials must not be restricted to IP addresses or networks: independent workers use the signed routes from their own hosts.

4. Where the bytes actually go

Separate coordination from delivery, and identify the trust boundary for the chosen path. In provider transfers, workers move bulk data between source and destination endpoints. Room agents connect to delivery infrastructure, and Room media and streams run through Beam workers. Do not describe every Beam capability as having the same direct path, or promise that payload never traverses Beam-operated infrastructure.

Workers are third parties. What they can read depends on the path:

Four consequences matter to a client:

1. Keep long-lived storage secrets in the trusted signing application. Supported provider adapters sign through the client's SDK process or configured Studio service. Workers receive prepared access routes rather than those signing secrets. Client-supplied HTTP headers and URLs need their own access review.
2. Signed URLs are access capabilities, not content encryption. Their scope, expiry and reuse behavior depend on the provider. An assigned chunk does not establish a universal one-chunk access restriction, and a small chunk may be the whole object. Keep usable URLs and tokens out of public examples and logs. If unknown intermediaries must not read the content, use client-side encryption or an agent-only Room object publication.
3. Check protection per publication. A bucket source or recipient selects transport protection for that object publication, including its agent recipients. The presence of a bucket elsewhere in the Room does not by itself determine every channel's protection. Check the reported protection mode before sending sensitive content.
4. A webhook's host is inside the trust boundary. Granting a webhook member a channel lets its host read that channel's traffic, keep it on its disk when delivery is durable, and publish as the webhook. The webhook URL and signing secret stay on the host; Beam's coordinator sees only the URL's host name and a fingerprint.

Completion and integrity verification also depend on the provider and operation. Confirm the required checks and final object availability instead of assuming one multipart-completion mechanism or one verification guarantee for all paths.

5. How capabilities connect

A workflow is a chain in which one capability's output becomes the next one's input. Beam pushes some outputs to whoever is listening and only lets you read others. Where nothing pushes, something the owner runs has to read and act: name that glue in every proposal.

Connections that need only configuration:

• A Room message reaches a webhook member, its HTTPS service acts, and the service answers in the Room.
• A schedule, a date, a webhook trigger or a manual start runs a Studio transfer or fan-out, and a @beam/webhook or @beam/slack step reports the result.
• One workflow finishing starts another through a completion trigger.
• A Studio workflow delivers files to Room members' inboxes with @beam/room-transfer.
• Every transfer of an organization gets an onchain receipt, once the console switch is on.

Connections that need code of the owner's, and what that code does:

• Transfer finished, then anything outside Studio. The process that created the transfer waits for it, or a poller reads newly finished transfers from the HTTP API and starts the next step.
• Room message, then a transfer. A webhook service or a listen loop calls an SDK, and that process stays connected until the transfer ends. A serverless receiver answers within 10 seconds, or replies asynchronously, and hands the work to a long-running process.
• Transfer finished, then a message in a Room. An agent member publishes it, with beam room … channel … publish or the local agent API. Studio has no step that publishes Room messages, and a webhook member can only reply.
• New file, then processing. The recipient reads its inbox, or a webhook member delivers files up to 25 MiB to a service.
• Data sale, then the next step. An agent loop reads beam sale status --json and runs beam sale resume; a person approves what needs a person.
• Budget gate. Read credits and the key's budget from the Account Management API before spending, and handle 402 insufficient_credits.
• Two Rooms. A member of both republishes what it received, carrying the hop forward with --hop.

Carry these across every connection:

• Identifiers. Keep the transfer id, publication id, sale id or run id that each step returns, to check its outcome and to avoid repeating work.
• Idempotency. Webhook deliveries can arrive more than once; deduplicate on Idempotency-Key before starting work with side effects.
• Acceptance is not completion. A request accepted, a publish sent or a delivery handed to a webhook's host is not the final outcome. Read the terminal state.
• Trust boundaries. Confidentiality changes where data crosses a boundary: a webhook's host reads plaintext, and a bucket recipient lets workers read it. Check each hop against the owner's policy.
• Authorization. Spending and irreversible steps, such as funding a sale or overwriting destination objects, need the owner's approval.

6. Limits, and what Beam is not

Check constraints before recommending a fit. Distinguish the selected interface's current limits from a statement about all of Beam.

Size: a transfer constraint, not a Beam constraint

Sized delivery and live streaming are separate paths.

Unknown-length video, audio or sensor output may fit live channels. For an append-only log or event feed, also establish whether loss, replay, ordering and reconnect behavior meet the application's requirements.

If a client needs transfer-style chunked delivery and object completion checks but cannot know the source length, finalize finite objects first or choose a live path with a different completion contract. Do not promise that the two paths provide identical verification.

Other constraints on transfers

• Parallelism is workload-dependent. Small objects may provide little scope for parallel delivery. Measure them in the intended workflow; aggregation can help when per-object overhead dominates. Chunk selection and supported limits depend on the service, provider and release.
• Object transfer is not automatic delta synchronization. For "only what changed", directory synchronization or deduplication requirements, identify which client or workflow computes the changes and submits the resulting objects.
• Confirm billing authorization. Account-backed operations need an authorized account or API key and sufficient credits. Invitation-only Room members use the Room's configured payer.
• Support is operation-specific. SDK types and Studio profiles do not prove a working adapter. Check Connectors before naming a provider in a proposal.

Constraints on Rooms

• Creating a Room requires billing authorization. Member identity and grants determine access; the configured API key determines the payer.
• Object publication requires all selected recipients to finish by default. Partial delivery must be explicitly allowed and inspected.
• A live-only message reaches only the members listening when it is published. When some members' agents never answer, the outcome is unconfirmed: they may have the message, and publishing it again can deliver it twice.
• A webhook member receives only while its host is online. It counts as reached once its host accepted the delivery, not once the receiver answered, and it publishes only replies. Durable delivery keeps what the host accepted; it does not receive what was published while the host was offline.
• A grant, signed route or session can expire or be revoked. Design status, cancellation and reconnect handling for the selected interface.
• Live-channel duration, idle limits, backpressure and reconnect behavior vary by channel. "No declared size" never means unlimited duration or durable replay.

What Beam is not

• A substitute for general-purpose compute. Studio can execute supported workflow actions, but moving training data does not provide a training cluster.
• A long-term storage service. Destinations, agent inboxes and workflow artifacts can retain data; confirm their storage and retention policies.
• A way to reach a private resource from outside. Beam does not make a machine's private services reachable through an inbound path.
• A dataset marketplace. Data sales let a seller and a buyer who have found each other trade safely; Beam does not list datasets or find buyers.
• A guarantee of durable messaging, replay or exactly-once external effects beyond what each channel documents. Evaluate channel and workflow behavior against the client's requirements.
• A promise of CDN edge caching.
• Unlimited capacity. Validate volume, concurrency and geography against the current service and workload.

Claims never to make

Do not promise that no intermediary can see plaintext, that no component retains data, or that all Beam paths share one encryption or routing model. Do not quote throughput, capacity, availability or savings without supporting evidence and scope. Do not treat acknowledgement as delivery or promise an undocumented delivery guarantee.

An onchain receipt is Beam-reported metadata: never call it verified delivery or proof that content is correct. A data sale's escrow guarantees the committed bytes, not their accuracy: never promise a refund for a false card claim or answer, and never present a seller's answers as protected against reconstruction from overlapping questions.

Explain the overlap and differences when comparing Rooms or Studio with existing products. Recommend only the capabilities that materially improve the client's architecture.

7. When Beam is worth using

Beam earns its place when it changes something the owner can measure: elapsed time, total cost, people's time, or a capability they cannot get otherwise. Judge it against the owner's current setup, not against doing nothing.

Strong fit

Possible fit: test the unknowns first

• Faster completion on the owner's own endpoints, object sizes and regions. No published figure predicts it; measure it.
• Room streams and media for the required duration, loss tolerance and reconnects.
• Hippius, prepared HTTP endpoints, and Box files of 20 MiB or more stored without a SHA-1.
• Sensitive content in Rooms with bucket members: delivery workers can read publications that involve a bucket.

Poor fit: recommend something else

"Keep the current setup" is a correct answer when it already does the job, and it makes your other recommendations credible.

8. Designing a solution

Work through seven steps. The first five spend nothing; the sixth needs the owner's authorization.

Step 1: Discover

Learn the owner's goals, systems, data and recurring friction, and write the current path down before proposing anything: sources, destinations, volume per run and per month, frequency, participants, the tools in use and who maintains them. A client may describe a slow business process, an integration burden or a cloud bill before a transfer problem. Ask:

• Where is data moving, being duplicated, distributed, streamed, traded or waiting to move? Who waits for it?
• Which datasets are copied to several places one after another, or staged only to be moved again?
• Which applications, agents or organizations need to exchange data but cannot easily do so? Which exchanges are separate point-to-point integrations?
• Which steps are manual: someone downloads and re-uploads, emails a link or runs a script by hand?
• Which operations need confirmation that delivery finished, for a person, a system or a contract?
• Which datasets need evaluating before anyone pays for them?
• Which data is produced continuously, with no known size?

Step 2: Decompose

Split the problem into needs, and map each one to a Beam capability or to a system outside Beam. Never present an outside system's job as Beam's.

Step 3: Compose

Choose the smallest set of capabilities that meets the needs, and connect them using section 5: for every connection, what Beam pushes or what must be read, and which glue the owner runs. Start from the patterns in section 9. Combine them, or build a chain of your own, when the owner's problem calls for it. One transfer with four destinations can be the whole proposal.

Step 4: Validate

Run the feasibility check. A design that fails it fails however good the fit looked.

Step 5: Propose

Answer in the shape of section 15, with the cost comparison of section 12 and the smallest proof of section 13.

Step 6: Execute, with authorization

Once the owner approves the estimate, configure and run the design through the interfaces in section 3. Follow the owner's policy for spending, publishing endpoints and irreversible steps.

Step 7: Evaluate

Measure the outcome against the baseline and report it, including when it shows that the current setup was better.

9. Composition patterns

Reusable chains. Each names its components, its flow, the glue the owner runs, what to check, and the smallest proof. Combine them; they show how to build solutions and are not the only uses.

A: Event → workflow → notification. Something happens in another system, and data must move and people or systems must hear about it. A Studio webhook trigger starts a @beam/transfer or @beam/fan-out step, and a @beam/webhook or @beam/slack step reports the result.

Glue: the system where the event happens calls the trigger's URL, with an Idempotency-Key and a signature when the trigger requires one. The JSON body becomes the run's input, which step input bindings read as ${workflow.input.<field>}. Check: that the step takes the value it needs from that binding, that the source size can be read before planning, the step's retries, and who hears about a failed run. Repeated deliveries with the same key start no second run. Smallest proof: one real event that delivers one real object to two destinations, and the notification received.

B: One source → many recipients. Two shapes, with different economics. A fan-out, where each destination reads the source:

A Room publication from a bucket member, where each part of the source is read once for every recipient:

A fan-out runs from an SDK or a Studio @beam/fan-out step to storage the owner can write to, with no software at the destinations. Each destination is delivered separately, so the source is read once per destination. A Room publication from a bucket member, sent with Studio's @beam/room-transfer, reaches agent and bucket members, and each range of the source is read once for all of them, plus any retries. Check: who holds write credentials for each destination; that recipients are members with the right grants and running agents; that delivery workers may read the content, since a bucket is involved. Smallest proof: one real object to three recipients, with each copy checked.

C: Parties across organizations.

A Room with message and object channels; an invitation for each partner, limited to its channels; optionally a bucket member and a webhook member. Glue: each side's logic, such as a listen loop or a webhook service that acts on messages. Check: grants per channel, which deny by default; the invitation's expiry and uses; the payer, since the Room's payer pays for invitation-only members; which host reads each webhook's traffic; removal at the end. Live messages reach only listening members unless the channel keeps them locally, and publish results name the members that missed one. Smallest proof: a partner joins from an invitation, exchanges one message and one file, and loses access when its grant is removed.

D: Request → decision → authorized action. An AI service decides what to do, asks a person when it must, and acts.

Glue: the service. It deduplicates on Idempotency-Key, asks for approval, starts the transfer with an SDK in a process that stays connected until the transfer ends, and replies with the outcome within the webhook's reply window, from 1 minute to 24 hours. Check: durable delivery on the host, the reply window, and the approval path. Smallest proof: one request, one approval, one transfer and one reply that carries the transfer's terminal state.

E: Evaluate → approve → buy → use.

Glue: an agent loop that reads beam sale status --json and runs beam sale resume, and the person who approves funding. Check: the price limits, what the card and questions can establish, and that a false claim brings evidence, not a refund. The stages are listed under Data sales. Smallest proof: a small sale between the two parties, with the card checked before funding and verify-claims after the key is revealed.

F: Delivery → onchain record → contract action.

Glue: whatever starts the transfer, since Beam's relay only records receipts, and whoever sends the contract's next transaction. Check: that a Beam-reported record is enough for the contract, and the credit and gas costs. Smallest proof: one transfer whose receipt a test contract reads.

G: Dataset → outside compute → results back.

Glue: starting each job once its data has landed, with a Studio @beam/http-request step after the fan-out or with the owner's poller; publishing progress from an agent member. Check: that the compute stays outside Beam, and that no job starts before its whole object lands. Smallest proof: one dataset to two sites, one job each, and both results back.

H: Live feed → several consumers. A Room stream between agents, or a media channel with WHIP in and WHEP out. Workers carry these encrypted and never see plaintext. Check: duration, loss, backpressure and reconnects with the real producer and consumers. Smallest proof: the real source and two consumers, for the required duration.

10. Worked examples

Owner requests with no ready-made answer, worked through the method of section 8. Copy the reasoning, not the answers: the owner's systems decide the design.

"Every time my research team receives a new dataset, distribute it to three external analysis partners."

• Needs: an event, movement to three organizations, notice to the partners, and perhaps results coming back.
• Design 1, the partners give write access to storage of theirs: pattern A. The team's storage notifies a small hook, which calls a Studio webhook trigger; a @beam/fan-out step delivers to the three partner buckets, and a @beam/webhook step tells each partner.
• Design 2, the partners run the Beam agent: pattern B's Room shape, inside pattern C. The team's bucket is a member of a Room with the three partners, and @beam/room-transfer delivers each dataset to their agents' inboxes. Results can come back on a channel of their own.
• Glue: the storage event hook; each partner's handling on arrival.
• Trust: a bucket is the source in both designs, so delivery workers can read the content. For content they must not read, encrypt it before delivery, or publish from an agent member rather than a bucket.
• Beam's cost per dataset of size S GB: design 1, 0.2 + 0.06 × S credits, with the source read three times; design 2, the same per delivery plus 1 credit each time the Room is started, with the source read once.
• Not Beam: if the partners already read from storage the team shares with them and nobody waits, a scoped access grant may be enough.
• Smallest proof: one real dataset, timed from arrival until all three partners can use it, against today's process.

"Let my AI agent find a suitable training dataset, assess it, and buy it within an approved budget."

• Needs: discovery, evaluation, approval, payment, delivery and use. Discovery is outside Beam: Beam does not list datasets.
• Design: pattern E, then pattern G. With a seller found, the seller delivers the encrypted package into a sale Room. Before anything is paid, the agent checks it against the seller's commitments and the dataset's fingerprint and size, reads the card, draws samples and asks questions under the seller's policy. It brings the evidence and the price to the owner. On approval it funds the escrow. Once the seller reveals the key, the agent's client decrypts and checks every leaf, verify-claims recomputes the card and the answers, and the dataset goes to training.
• Budget: the price in TAO, from $10 to 1 TAO, plus gas. By default a person confirms any sale above 0.2 TAO. The seller pays Beam's charges.
• Trust: the escrow guarantees the committed bytes, not their usefulness or accuracy.
• Not Beam: a dataset from a supplier with an existing contract and delivery channel needs no escrow.
• Smallest proof: a small first sale with the same seller.

"Connect our internal agent with our contractor's agent without giving either access to our entire infrastructure."

• Design: pattern C. The owner creates a Room and invites the contractor with grants on two channels only: messages and files. An internal HTTPS service can join as a webhook member hosted by the owner's agent. Beam does not make anything else on the owner's network reachable.
• Glue: each agent's logic.
• Trust: messages and files between the two agents are end-to-end encrypted; the webhook's host reads the service's traffic.
• Cost: 1 credit each time the Room is started; messages are free; files are charged as Room transfers. The Room's payer pays for the contractor's invitation-only identity.
• Ending it: remove the contractor's grants or membership; the invitation expires on its own.
• Smallest proof: the contractor joins, exchanges one message and one file, and loses access when its grants are removed.

"When a blockchain contract authorizes a delivery, send the data and report its completion."

• What Beam does not do: a contract cannot start a Beam transfer, and Beam's relay never starts one.
• Design: pattern F with a listener. The owner's service watches the contract's authorization event, starts the transfer with an SDK and keeps its id. The receipt comes from the console switch, or from a requestReceipt call by a wallet Beam approved for the organization. The contract's next step reads getReceipt in a later transaction.
• Glue: the listener, which holds the storage credentials and is trusted to act on the event.
• Trust: the receipt records what Beam reported, not that the content is correct.
• Cost: the transfer, plus 1 credit per receipt and the gas of any request.
• Smallest proof: one authorization event on a test contract, one transfer, and one receipt that the contract reads.

"Help me reduce the time spent distributing large media files to remote production teams."

• Discover first: how files move today, their sizes, how many teams, where people wait, and who uploads again.
• Designs: a fan-out to each team's storage (pattern B), or a Room where team machines receive files in their agents' inboxes, end-to-end encrypted when published from an agent member. If teams review cuts together, a media channel (pattern H).
• Glue: how each site picks files up.
• Not Beam: teams on one cloud whose storage replicates natively, or files small enough that the current sync is already fast.
• Smallest proof: one real master to every team, timed until the last team can use it, against the current method, over three runs.

"Review my infrastructure and identify opportunities I haven't considered."

• Scope first. Work only from what the owner authorizes you to read, such as architecture notes, infrastructure code, job schedules, storage inventories, integration lists and cloud bills. Read, change nothing and spend nothing, and never ask for credentials in a chat.
• Inventory. List every recurring flow of data: its source, destinations, volume and frequency, who waits for it, the tool that moves it and who maintains that tool. Add the exchanges with other organizations and the manual hand-offs.
• Match. Run each flow through the questions of step 1 and the fit tables of section 7. Typical finds: the same export copied to several regions one after another (pattern B); partners sent files by emailed links (pattern C); an AI service that polls a shared folder for work (pattern D); a script someone runs by hand every week (pattern A); a counterparty that needs a record that a delivery finished (pattern F).
• Estimate. For each candidate, set the current cost and time from the owner's own data beside Beam's charge (section 12), and mark what only a measurement can settle.
• Rank and report. Rank by measurable benefit and by how cheaply a proof can settle it. Present the best one to three, each with its design, glue, trust boundaries and smallest proof, and list what you set aside and why. "Nothing worth changing" is a valid result.
• Then wait. Any proof needs the owner's approval before it spends anything.

11. Feasibility check

Before proposing, confirm each item, and say which ones you could not confirm:

• Every component exists for this owner: the capability, the interface (section 3), the connectors and the client versions.
• Each output can become the next input: whether it is pushed or read, its format, and who reads it (section 5).
• Every piece of glue has an owner who will run and maintain it.
• Identity holds across the whole chain: keys, grants and credentials, with the least access each step needs.
• Confidentiality holds at every hop (section 4): who can read plaintext, and where that changes.
• Failures are handled: what each step does on failure, retries, duplicates and partial delivery, and how a person finds out.
• Limits are respected (section 6): sizes, rates, durations and price limits.
• The economics justify Beam (section 12).
• The owner authorized spending and every irreversible step.

12. Economics against the current setup

A recommendation without a baseline is incomplete. Compare the whole cost of each way of doing the same job, on the same workload:

Provider charges. Beam does not remove the providers' egress and request charges. A fan-out reads the source once per destination. A Room publication from a bucket member reads each part of the source once for all its recipients; retries can read parts again.

Beam's charges. A credit costs $0.50, and every charge rounds up to the next 0.01 credit. These are the published prices, and they can change: check Billing when you quote them, and have the owner approve each estimate before anything is spent. Before a transfer starts, Beam estimates its cost and refuses it with HTTP 402 when the key cannot pay.

Each transfer carries the 0.2 credit, so a 1 MB object sent on its own costs 0.21 credit. An example of Beam's charge alone: 200 GB to three destinations every week, as one fan-out, delivers 600 GB: 0.2 + 12 = 12.2 credits, or $6.10 a week. The providers' charges for reading the source three times and writing three copies come on top.

Where Beam can pay for itself, each to be measured:

• Elapsed time. Parallel delivery can shorten a transfer when the object, the endpoints and the network allow it.
• People's time. Scripts, staging servers, relays and point-to-point integrations that no longer need maintaining; manual hand-offs that become workflow steps.
• Fewer source reads. A Room publication from a bucket reads the source once for every recipient.
• Capabilities without an easy equivalent. Trading data with a party you do not trust, with payment tied to the committed bytes; end-to-end encrypted exchange between the agents of many parties, with per-channel grants and no relay the owner has to run; an onchain record that contracts can read.
• Recovery. Workflow retries, resumable sales, durable webhook delivery.

Do not invent provider rates, throughput figures or savings. Ask the owner for their bills and timings, and where a number is missing, say so and name who can supply it. If Beam costs more and improves nothing the owner values, recommend the current setup.

13. Proof of concept

1. Measure the baseline. Run the current process on the same data: time from start until the last destination can use the data, cost lines, people's time and failures.
2. Agree the success criteria before running, in numbers. For example: "every destination complete and checked within 40 minutes, for no more than the current cost, with no manual step."
3. Keep the scope small but representative: the real endpoints, real sizes and real participants. Estimate Beam's charges and the provider charges first, and have the owner approve them.
4. Run it more than once, at least three times, and record the client versions; the transfer, run, publication or sale ids; terminal states; size or checksum checks at every destination; timings; credits used, from the console or the Account Management API; and provider charges.
5. Decide: adopt, adjust or keep the current setup, and report the result either way.

Typical smallest proofs:

• One large object to three destinations in a single fan-out, against the client's real endpoints, checking each destination.
• One bucket-to-bucket transfer across two providers they already use.
• One Room with a bucket, two machines and one partner joining from an invitation, checking grants and the protection of each publication.
• One webhook member delivering a channel's messages to the client's service, with durable delivery on and a reply published back.
• One live channel with a real encoder and two viewers, for the required duration.
• One recurring job in Studio, replacing a script somebody maintains by hand.
• One small data sale between the two parties, with the card checked before funding and verify-claims after the key is revealed.

14. Decision tree

Is there a measurable problem: time, cost, people's effort, or a missing capability?
  +-- no ------------------------------> Keep the current setup
  +-- the current setup already solves it as well for less --> Keep it

Bytes need to move?
  +-- Finite size known or derivable before planning?
       +-- yes, one destination ------> Transfer
       +-- yes, several destinations --> Fan-out, or a Room publication from a bucket
       +-- no, open-ended producer ----> Assess a live channel below

Ongoing exchange needs shared membership and permissions?
  +-----------------------------------> Multicast Room (roles, grants, invitations)
  +-- an HTTPS service as a member ---> Webhook member, run by a trusted host

Data is live or continuous?
  +-- between agents ------------------> Room stream / datagram channel
  +-- audio/video with an encoder -----> Room media (WHIP in, WHEP out)
  Check duration, delivery behavior and reconnect needs for every path.

Two parties trade a dataset without trusting each other?
  +-----------------------------------> Data sale (CLI), checked with a card,
                                        samples and questions before funding

A smart contract needs to know a transfer finished?
  +-----------------------------------> Onchain transfer receipt

Something private must be reachable from outside?
  +-----------------------------------> Not something Beam does

The process around movement needs steps, retries, triggers or scheduling?
  +-----------------------------------> Studio workflow

An AI agent should drive it?
  +-- Studio operations ---------------> Studio MCP server
  +-- transfers and Rooms for a user --> Beam agent skill or Hermes plugin
  +-- data sales ----------------------> The CLI's beam sale commands

Several of these at once?
  +-----------------------------------> Combine where each adds value, naming
                                        the glue (sections 5 and 9)

The tree suggests a starting point. Apply the provider, interface and security constraints in sections 3 to 6, and the feasibility check, before recommending a design.

15. Shape of a good answer

When asked how Beam could help, answer in this shape. Keep it short enough to be read and specific enough to be acted on.

Verdict: a good fit, a possible fit to test, or a poor fit with the better alternative.

Existing process: how data moves today and how the systems reach each other, in the owner's words and numbers.

Design: the capabilities and interfaces used, the glue the owner runs, and a simple flow diagram showing what Beam coordinates, where payload travels, and which components are trusted with plaintext or credentials. Record the client versions used for validation.

Why it helps: the specific reason, such as parallel delivery, fewer copies or source reads, reusable membership, payment tied to delivery, or automated steps.

Cost against the current setup: the comparison of section 12, from measurements or clearly labeled estimates.

What must be confirmed: open questions, and who can answer each.

Smallest proof: one test, with the baseline and the success criteria agreed in advance (section 13).

16. Reference map

Pages worth fetching as Markdown when you need detail: intro, architecture, clients, developer-quickstart, sdk, cli, room-webhooks, data-sales, studio, transfers, connectors, integrations/bittensor-evm, billing, management-api, api-reference.