Beam

Code on Beam reaches other systems through what the customer writes: secrets hold credentials, S3 buckets mount into apps and custom registries supply images, while task callbacks POST results to the customer's server and sandbox ports expose services. Beam has no catalog of connectors, OAuth actions or tool gateway of its own; the tools are the customer's code. Earlier claims of file access to Gmail, GitHub and Linear through Airstore do not appear on Beam's current pages.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

An agent framework ships in the SDK (Bot, BotLocation, BotContext), built on a Petri net model: locations hold typed state, and transitions consume inputs from locations and write outputs to others. Transitions can be driven by a model or by plain code, run concurrently in isolated containers and keep state synchronized between them, while task queues add retries and timeouts and map fans work out. So deterministic steps mix with agent steps, and branching and retries are built in. Beam says it is launching the framework, and how mature it is beyond the documented example is not stated.

Sourcedocs.beam.cloud/v2/agents/introductionread 2026-09-22

Any retrieval system on Beam is one the customer builds; Beam maintains no retrieval structure of its own over the customer's content for an agent to query. Volumes and durable disks, Maps and mounted S3 buckets are storage, not an index that returns results, and nothing Beam provides indexes, refreshes or permissions the customer's sources.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Nothing documents an approval step, consent checkpoint or escalation to a person for work running on Beam, including agents built with its framework. Workload isolation, with containers per customer, network separation and scoped secrets, is security the platform applies, not a point where a person reviews an agent's action.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

Beam states a SOC 2 Type II audit by Advantage Partners (report under NDA), HIPAA BAAs for Enterprise customers and a GDPR DPA. Data is encrypted in transit and at rest, and containers and networks are isolated per customer. The customer scopes, rotates and deletes its encrypted secrets, and workspace API tokens can be created, rotated and revoked. Beam's own security page admits the gaps: all members of a workspace currently have the same permissions, and single sign on is not yet available.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

The workload is recorded: application logs are kept 30 days on Developer and Team plans and one year on Growth, log export is included, and task status can be queried by ID with callbacks on completion. Prompts, tool calls, retrieved knowledge and outputs can be inspected step by step only as far as the customer's code logs them, and no audit log of workspace actions separate from runtime is documented.

Sourcebeam.cloud/pricingread 2026-09-22

State carries across runs. Sandbox snapshots capture filesystem and memory as an immutable artifact to fork from or restore, and distributed volumes and durable disks on each node persist data. Distributed Queues and Maps share it across tasks, and the agent framework synchronizes state between transitions, so an agent's code can read that state and carry on. Volumes and disks are storage the code reads, though, and snapshot state belongs to the machine: the buyer can restore or delete it but not review or edit it as memory, and no memory layer with a stated scope and lifetime is documented.

Sourcedocs.beam.cloud/v2/sandbox/snapshotsread 2026-09-22

Beam runs three ways. Its managed cloud runs on AWS and Google Cloud. With bring your own cloud, Beam runs the control plane and compute in the customer's AWS or GCP account (its pricing page also names Azure) for a flat management fee, while the compute bills to the customer's cloud.

And Beta9, the engine that powers Beam, is open source under AGPL 3.0 and can be self hosted on a local machine or Amazon EKS. Compute pools can also run Beam workloads on the customer's own machines. The beta9 repository is actively maintained, with a release on 22 September 2026. No region selection for the managed cloud is documented.

Sourcedocs.beam.cloud/v2/self-hosting/overviewread 2026-09-22

Ready made starting points ship as end to end examples for model serving (Llama, DeepSeek, Qwen and Hugging Face models, plus an OpenAI compatible vLLM server), for media (ComfyUI, Whisper and text to speech), and for fine tuning and web scraping, plus a research assistant agent built on the agent framework. These are examples a developer builds from, not a browsable catalog of agents a buyer adopts.

Sourcedocs.beam.cloud/v2/examples/overviewread 2026-09-22

Work starts without a person. The schedule decorator runs a deployed job on a schedule, web endpoints and task queues boot containers from zero when requests or tasks arrive, and one app can send events to another through signals, for example to reload a model when retraining finishes. Task callbacks also notify the customer's server when a task finishes.

Sourcedocs.beam.cloud/v2/function/scheduled-jobread 2026-09-22

Model choice is the customer's: Beam runs any model on the GPU the customer picks. Documented examples serve Hugging Face models such as Llama 3.1, DeepSeek R1 and Qwen through vLLM, including an OpenAI compatible vLLM server, or through SGLang, and fine tune Gemma and Llama, so the buyer's own deployments and providers are in play.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Outside callers reach Beam through Python and TypeScript SDKs, a CLI, and a REST API with published Swagger specifications for the gateway and pods, covering tasks, pods and sandboxes. Web endpoints expose the customer's code as HTTP APIs, the open source Beta9 engine can be extended, and a docs MCP server serves Beam's documentation to coding tools.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Code, experiments and fine tuning jobs run on Beam with retries and logs, but Beam offers no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs. Running experiments is compute, not evaluation.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Beam Sandboxes run any code with GPUs, networking and storage and can expose ports for web services, but no browser or desktop the agent operates is documented, and no API for screenshots, clicks or typing. A code sandbox is not an agent operating a web interface or desktop where APIs are absent.

Sourcedocs.beam.cloud/v2/sandbox/overviewread 2026-09-22