Skip to content
beam-agents
GitHub

Glossary

The terms this project uses precisely — activation, entity key, staging, continuation, intent, effector, re-injection, replay cache, seq.

StableImplemented, specified, and covered by tests in the repository.

These words carry specific meanings here. Where the same word means something looser elsewhere in the ecosystem, that is noted.

The order below is conceptual rather than alphabetical: each entry leans on the ones above it.

Activation

One execution of the agent, for one key, inside one process() call. Not "a conversation" and not "a session" — a single invocation with a single outcome. An agent that suspends and resumes has had two activations, sharing one seq.

Entity key

The bytes key an activation runs under — the account, user, device, or whatever else the pipeline partitions by. It is the Beam key, so it is also the unit of state isolation and of serialization: two entity keys never share memory and never contend, and one entity key is processed one activation at a time. Input to RunAgent must already be keyed by it.

Outcome

What an agent returns: Complete(output=...), which ends the activation and emits on .output, or Suspend(...), which persists a continuation and waits for a ToolResult or an Approval. There is no third option and no implicit fall-through, because "what happened to this activation" has to be answerable from the return value alone.

Staging

Recording an effect in the activation context instead of performing it. Memory writes, cache inserts, intents, traces, and outputs are all staged, and applied only when the activation succeeds and its bundle commits. It is the mechanism behind the atomicity invariant: an activation that raises halfway through has staged work and applied none of it.

Continuation

The persisted resume-state for a suspended activation awaiting a ToolResult or Approval. Framework-opaque: the runtime stores the snapshot bytes the agent handed it and gives them back on resume, without interpreting them.

Intent (ToolIntent)

A declarative request to perform a side effect. Not the effect itself — a description of one, carrying a deterministic intent_id, the tool name, JSON-encoded arguments, and an expires_at_ms. Intents leave the pipeline on .intents; the effector executes them.

Effector

The external reference service that consumes intents, deduplicates on intent_id, executes the tool exactly once per intent, and publishes ToolResults. It runs outside the pipeline, as a separate process. It is a reference implementation, not a hosted service.

Effectively-once

The delivery property the effects path targets: an intent is executed once observably, even though the pipeline may produce it more than once. It is not a claim that the message is delivered exactly once — that is unachievable across a process boundary. It is deterministic intent identity plus deduplication at the executor, which together make a duplicate a lookup rather than a second effect. See correctness invariant 2.

Side-effecting tool

A tool declared side_effect=True. Calling one directly raises SideEffectToolError; the only way to invoke it is ctx.act(...), which stages an intent. Its counterpart, a side_effect=False tool, runs inline inside the activation and never leaves the pipeline. See the tool registry.

Approval

A human decision re-entering the pipeline on the same key, in the same shape as a ToolResult. Human-in-the-loop is not a separate mechanism here — it is the effects path with a person where the executor would be, which is why it inherits the same expiry and fail-closed behavior.

Re-injection

Results and approvals re-entering the pipeline as new elements on the same key. This is how the agent loop closes: not as a cycle in the Beam DAG (which is acyclic), but as a round trip through the message bus.

Replay cache

Keyed-state memoization of model calls, making bundle retries cheap and path-stable. Keyed on the request content plus the activation's (key, seq), so a retried bundle both costs nothing extra and takes the same path.

seq

The per-key monotonic activation counter. It scopes cache keys and intent ids. A suspended activation that resumes keeps its seq — the resume is the same logical activation continuing, not a new one.

Fast path

An activation that completes in a single element with no suspension. Contrast with the re-injection path, which suspends and resumes.

Step index

The position of a staged effect within an activation. Combined with the key and seq, it produces the intent id. A resumed activation continues its step index rather than restarting at zero, so a second intent in the same logical activation cannot collide with the first.

Dead letter

An .errors record. It means the activation committed nothing — no memory write, no intent, no output. The record is the only evidence the key was touched. See the errors reference for the reason taxonomy.

Runtime, not framework

Used throughout this site as a specific claim: the project provides execution guarantees (durable memory, effectively-once effects, event-time semantics, scale-out) and deliberately provides no agent-authoring surface (no prompt templating, no orchestration DSL). Authoring belongs to LangGraph and its peers, integrated via adapters.

What backs this page

Symbol
beam_agents.RunAgent
Source
src/beam_agents/core/context.py
Specification
openspec/specs/wire-schemas/spec.md
Test
tests/core/test_context.py