Compared with Apache Flink Agents

Apache Flink Agents is the closest comparable project, and beam-agents' own project context names it as the direct competitor. This page compares the two as carefully as the available evidence allows — which means several rows below read Not established.

The honest headline

Both projects put an AI agent inside a streaming pipeline as a keyed operator, and both require the input to be keyed. The difference a reader is most likely to care about is the substrate: Flink Agents is a sub-project of Apache Flink and targets Flink; beam-agents targets Apache Beam and therefore aims at runner portability, including Dataflow as a managed service.

The other difference is maturity, and it does not favor this project. Flink Agents has published releases; beam-agents declares version 1.0.0 but has pushed no release tag, so it has published none.

Comparison

Rows marked Not established were not verified from a citable source at the retrieval date shown below.

Aspect	beam-agents	Apache Flink Agents
Governance	Independent project, Apache-2.0 licensed, built on Apache Beam. Not an ASF project.pyproject.toml	A sub-project developed under the Apache Flink umbrella, Apache-2.0 licensed.[src]
Substrate	Apache Beam. Exercised on DirectRunner and Flink per PR, Dataflow nightly; a weekly Spark leg currently skips every conformance cell.tests/conformance/test_direct.py	Apache Flink.[src]
Languages	Python only for v0.x. Wire schemas are protobuf, so cross-language stays possible.pyproject.toml	Java and Python 3.10-3.12.[src]
Attaching an agent	events | RunAgent(agent, config=AgentConfig(...)) over a pre-keyed PCollection[KV[bytes, AgentEnvelope]]; unkeyed input raises at construction time.tests/core/test_transform.py	from_datastream(input, key_selector).apply(agent).to_datastream(); the input must be a KeyedStream or carry a KeySelector.[src]
Released versions	None. Declared version 1.0.0, but no release tag pushed and nothing on any registry.pyproject.toml	0.1.0 announced October 2025; v0.2 and v0.3 documented, with v0.3-SNAPSHOT current in development.[src]
Side-effect model	Effects never run in the pipeline. The agent stages a ToolIntent with a deterministic id (uuid5 over key|seq|step_index); an external effector deduplicates on it and executes.tests/semantics/test_effectively_once_e2e.py	Not established
Duplicate-effect guarantee	Duplicates bounded to the crash window between a tool effect and its durable completion record; true exactly-once requires tools idempotent on intent_id. Gated end to end with SIGKILLed workers.tests/semantics/test_effectively_once_e2e.py	Not established
Human-in-the-loop	Approval intents plus a fail-closed timeout at two layers: an in-pipeline timer routing Deny/Drop/Escalate, and effector-side refusal of expired intents.tests/semantics/test_hitl_fail_closed.py	Not established
Memory	Working memory in Beam keyed state: scalars and bounded rings, 100 KiB blobs, 1 MiB soft cap per key, event-time TTL GC. A long-term MemoryStore tier ships behind it: Bigtable, Redis, Firestore, and SQL backends with seq-guarded upserts.openspec/specs/memory-facade/spec.md	Documentation organizes memory into Sensory & Short-Term Memory and Long-Term Memory.[src]
Tool and MCP support	A @tool registry with a side_effect flag; read-only tools run inline, side-effecting ones only via intents. Read-only MCP is described in the module map but is not implemented.openspec/specs/tool-registry/spec.md	Documents Tool Use and MCP sections.[src]
Bring-your-own agent framework	Adapter-based, targeting a structural protocol. LangGraph, Google ADK, and Pydantic AI adapters are implemented, each on the conformance matrix.tests/adapters/test_e2e_pipeline.py	Not established
Model-call replay behavior	Every model call is cached in keyed state, keyed on the request plus (key, seq). A bundle retry incurs zero additional provider calls on the cached path.openspec/specs/llm-replay-cache/spec.md	Not established
Published performance figures	A design budget for runtime overhead, measured by an offline pyperf suite and gated against a committed baseline in the repository; this site publishes no figures of its own.openspec/project.md	Not established

About the empty cells

Six rows have no Flink Agents entry. That is a limitation of this page, and worth being precise about: the documentation pages consulted at the date below covered integration, memory organization, and tool/MCP support, but the pages this author reached did not state a side-effect execution model, a duplicate suppression guarantee, or human-in-the-loop semantics in terms that could be quoted.

This project's own internal notes assert that Flink Agents uses inline durable execution where beam-agents uses an outbox. That assertion is not repeated as fact here, because it could not be substantiated from a citable source at the retrieval date. If you are choosing between the two on that axis, read their documentation directly rather than trusting either project's characterization of the other.

What is genuinely different

Setting aside what is unverified, two differences are solid:

1. Runner portability versus a single engine. Targeting Beam means the same pipeline can run on the DirectRunner, Flink, or Dataflow. Whether that is worth anything depends entirely on whether you want to leave Flink.
2. Maturity, in Flink Agents' favor. Released versions, an ASF community, and Java support are real advantages over an unreleased single-language project. If you need something in production this quarter, that difference matters more than any architectural preference.

Related

• Compared with running a framework outside a runtime
• Adapters
• Correctness invariants