Skip to main content
loomcycle
§ comparison

AWS Loom vs loomcycle.

Both projects live near the same problem shape. Both use "loom" in the name. They are different kinds of tools, they run in different places, and they compose with a very different set of primitives. This page lays them side by side so you can pick the one that fits.

Two different projects, same base word. AWS Loom (github.com/awslabs/loom, AWS Labs) is an opinionated control plane for Amazon Bedrock AgentCore. loomcycle (github.com/denn-gubsky/loomcycle, Apache-2.0) is a self-hosted agentic runtime. Related space, unrelated codebases, unrelated authors. This page uses "AWS Loom" and "loomcycle" throughout to keep the two clearly separate.

The one-line difference. AWS Loom is a control plane. loomcycle is a runtime. If your agents already run on Amazon Bedrock AgentCore and you need governance, tagging, and a management UI around them, AWS Loom is a fit. If you want the runtime itself, portable and self-hosted, with a published memory benchmark, a Decision model, Teams-as-one-file state machines, multi-replica HA on Postgres, whole-deployment Snapshots, and seven LLM providers including local Ollama, loomcycle is a fit.

What each one is

AWS Loom

what: control plane over Bedrock AgentCore

runs on: an AWS account, cloud-only

providers: Amazon Bedrock only

status: AWS Labs (experimental)

shape: FastAPI backend + management UI + paved-path blueprints

Wraps AWS Bedrock AgentCore Runtime, Bedrock AgentCore Memory, AWS Secrets Manager, and AWS Agent Registry behind a unified API and console. Agents ship as pre-written Python code (Strands Agents SDK) or as no-code deployments on AgentCore's managed harness. Explicit invariant: no AI-generated code at runtime. Governance via required tags (loom:application / loom:group / loom:owner) and ABAC over those tags.

loomcycle

what: self-hosted agentic runtime

runs on: one ~80 MB Go binary, laptop / VPS / container / k8s

providers: Anthropic direct, OpenAI, DeepSeek, Ollama, Gemini, Bedrock, more

license: Apache-2.0, v1.116.0 (October 2026)

shape: HTTP + gRPC + MCP server + MCP client + WebSocket + TS + Python surface, ships as one process

The runtime that owns the agent loop. Bi-temporal memory with subject-document identity and a published LoCoMo final retrieval of 0.74. The Decision tool as a general primitive with kind-typed model aliases. Teams-as-one-file state machines with declarative decision nodes, parallel + consolidator handlers, pushback. Whole-deployment Snapshots. Multi-replica HA on Postgres LISTEN/NOTIFY. Bundled dev toolchain and a headless Chromium. Validated by two months of continuous production operation at JobEmber.ai.

Where they overlap

The two projects genuinely try to solve some of the same problems. Both externalize credentials rather than storing them inline. Both attach identity to every call and refuse cross-tenant reads. Both have a human-in-the-loop primitive that pauses on sensitive tool calls and asks for approval. Both give agents a memory surface with a lifecycle attached to it. Both integrate with MCP servers as tool sources. Both provide per-scope cost visibility. This isn't accidental. The shape of "run agents in production" converges on a similar set of concerns regardless of who builds it.

Capability matrix

Rows marked ✦ are where loomcycle's answer is materially different from AWS Loom's. Some of those rows favor loomcycle, some favor AWS Loom; the mark just flags a real divergence, not a value judgement.

Capability AWS Loom loomcycle
License AWS Labs (unstated in the launch post)experimental / unsupported status Apache-2.0v1.116.0 (October 2026), weekly ship cadence
Runs where Amazon AWS account onlyBedrock AgentCore Runtime hosts everything Laptop, VPS, homelab, container, k8sone ~80 MB Go binary + sqlite by default; postgres for HA
LLM providers Amazon Bedrock onlyAnthropic models via Bedrock Anthropic direct, OpenAI, DeepSeek, Ollama, Gemini, Bedrock, morenative HTTP, no vendor SDK, provider-cascade fallback circuit
Local LLM inference ✗ ✓Ollama, llama.cpp, LM Studio; qwen3.6 at 6-9 tok/s on a Ryzen 7 8700G iGPU
Distribution shape FastAPI control plane deployed on AWSplus AWS infrastructure setup Single binary, curl + chmod +x + runor a Docker image, or a Homebrew tap
Owns the agent loop ~delegates to Bedrock AgentCore ✓the loop is the product
MCP client (consumes MCP servers) ✓MCP servers configurable with OAuth2 ✓MCPServerDef primitive, per-tenant credentials
MCP server (the runtime addressable via MCP) ✗ ✓stdio MCP server; 21+ meta-tools including history, document, path, teamdef
Memory quality (published benchmark) ✗AgentCore Memory ships; no published benchmark number ✓bi-temporal + subject-document identity; LoCoMo final retrieval 0.74; cascade with Decision verifier and recall_attach_traces runtime grant
Decision model (typed probabilities) ✗ ✓Decision tool (v1.107) with choice, noul, score; kind-typed aliases; LoCoMo rerank recall@5 lifted 0.588 → 0.740
Multi-agent workflows / state machines ~A2A integrations mentioned; no state-machine primitive ✓TeamDef (v1.109): Teams-as-one-file carries agents, skills, channels, schedules, webhooks; parallel + consolidator; pushback loops; declarative decision nodes
Whole-deployment snapshot (one archive) ✗ ✓Snapshot (v1.101): HMAC-signed secret references, re-validated on restore; one create + restore moves a working deployment
Multi-replica HA (Postgres) ~AWS runs the control plane multi-AZ; shape not configurable ✓Postgres LISTEN/NOTIFY fan-out across replicas; single-writer leases on schedules + webhooks
Bundled dev toolchain + headless Chromium ✗ ✓Toolbox (v1.95): lint / test / build / scrape without the operator provisioning them per project
Skills primitive (on-demand context) ✗ ✓SkillDef: loads only when the agent asks for it; no default context cost
Documents (chunked-graph structured knowledge) ✗ ✓Document + per-piece derived search units; retrieval 0.966; Markdown round-trip
Path VFS (tenant-rooted directory tree) ✗ ✓Unix-like paths over Documents + Volumes + Memory entries
Filesystem volumes (per-tenant, sandboxed) ✗ ✓VolumeDef: read-only / read-write mounts, resolveInsideRoot guarantee, ephemeral-per-run default
In-process shell sandbox ✗no explicit sandboxing mentioned ✓Bashbox: in-process shell parser, allowlisted builtins, host-command fallback
Client-executed tools (browser / IDE / phone) ✗ ✓a client opens a WebSocket, registers tools, and executes them locally when the agent calls them
History (list, search, recap, resume, related) ~Agent Registry lists agents; no chat-history op set ✓10 ops including recap + resume + semantic related, tenant-safe fold on every read
Credentials externalized ✓AWS Secrets Manager ✓CredentialDef, per-tenant encrypted at rest, $cred: references
Multi-tenant isolation ✓ABAC via loom:group tag, RBAC tiers ✓tenant scope on every def + every read, fold-first by-id ops, opaque not-found
Human-in-the-loop ✓Strands hooks + interrupts + MCP elicitations ✓Interruption tool (in-loop + off-run); interrupt-on-cap for TeamDef
Cost attribution ✓AWS cost console via required tags ✓per-scope token/cost ledger with enforceable per-scope budgets
Governance review board / approval gate ✓Agent Registry review workflow before production ~content-addressed versions + fork/promote/retire; explicit review-board flag not shipped yet
Chained identity token exchange (RFC 8693) ✓end-user + agent identity through delegated MCP + API calls ~OperatorTokenDef + RunIdentity; RFC 8693 chaining queued as an RFC candidate
Deep managed-AWS integration ✓Bedrock AgentCore, Secrets Manager, API Gateway, Agent Registry ✗reaches AWS via native HTTP where useful; not AWS-native
Scheduled runs (cron + per-user forks) ~via EventBridge integration ✓ScheduleDef primitive, in-flight tracker, x30k stress-tested
Input webhooks (HMAC-verified, idempotent) ~via API Gateway routing ✓WebhookDef: three signature envelopes auto-detected, verify-before-parse
OpenAI-compatible gateway in-process ✗ ✓/v1/chat/completions + /v1/embeddings; drop-in for any OpenAI client
✓ shipped ~ partial or indirect ✗ not present ✦ material divergence between the two

Where AWS Loom fits better

Straightforward cases. Pick AWS Loom if:

Where loomcycle fits better

Also straightforward. Pick loomcycle if:

A note on the shared name

Loomcycle's project name is a compound (weaving + cycle) and has been on loomcycle.dev since 2025. AWS Loom launched in 2026 as an AWS Labs project. Same base word, different products, no shared code, no shared maintainers. The two projects will show up next to each other in searches for a while. If you're looking for the AWS product, you want github.com/awslabs/loom and the AWS blog. If you're looking for the self-hosted runtime, you want github.com/denn-gubsky/loomcycle and this site.

See also

Try loomcycle

One binary. One config file. Route to any provider. Run on the machine you already have.

curl -L https://github.com/denn-gubsky/loomcycle/releases/latest/download/loomcycle-$(uname -s | tr A-Z a-z)-$(uname -m) -o loomcycle
chmod +x loomcycle
./loomcycle serve --config loomcycle.yaml