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.
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.
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
✓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:
Your agents already live on Bedrock AgentCore and the rest of your infrastructure is AWS-native. Adding loomcycle in front of Bedrock is possible but pointless.
Your compliance posture requires the AWS shared-responsibility model. Bedrock's audit surface, Secrets Manager's KMS-backed storage, IAM's fine-grained roles: all of that comes free when the runtime lives in your AWS account. loomcycle can be deployed with equivalent controls but you're the one wiring them.
You want a governance review-board workflow for agents before production. AWS Loom ships this via AWS Agent Registry. loomcycle has versioning and content-addressing but no formal review-board gate on the promote transition (yet).
You need RFC 8693 chained token exchange through delegated MCP calls and downstream APIs. AWS Loom ships this via AgentCore Identity. loomcycle has run-identity plumbing and OperatorTokenDef; the specific chained-token pattern is a candidate RFC.
Your buyer signs off on AWS-branded software and does not sign off on GitHub Apache-2.0 projects from independent maintainers. Real constraint. loomcycle does not solve that constraint.
Where loomcycle fits better
Also straightforward. Pick loomcycle if:
You want to run the runtime yourself. On a laptop, a VPS, a homelab NAS, a Fly.io app, a Kubernetes cluster, or an air-gapped machine. AWS Loom lives in an AWS account; there is no other option.
You need a local LLM inference path. Ollama on a Ryzen 7 8700G iGPU. llama.cpp on a Mac. LM Studio on a workstation. loomcycle routes to any of these natively. AWS Loom cannot reach a model that isn't on Bedrock.
You need to route across providers. Anthropic direct for the coding agent, DeepSeek for the bulk classifier, OpenAI for the embedder, Ollama for the offline fallback, Bedrock for the audit-friendly path. loomcycle's provider cascade handles this with per-agent overrides. AWS Loom is Bedrock, full stop.
You need multi-agent workflows as a first-class primitive. TeamDef graphs, parallel handlers with consolidators, pushback loops, durable Document-backed boards, interrupt-on-cap escalation. AWS Loom mentions A2A integrations but has no state-machine primitive with pushback and durable state.
You care about the substrate vocabulary. Skills that load only when asked. Documents as chunked-graph knowledge with a 0.966 retrieval number. A Path VFS over Documents and Volumes and Memory. Volumes as tenant-scoped filesystem mounts. Bashbox as an in-process shell sandbox. Client-executed tools that let a browser extension run tools locally. All shipped. AWS Loom's surface is Agent + Memory + MCP + A2A + Tags.
You want a Decision model as a general primitive. The Decision tool takes choice, noul or score questions and returns calibrated probabilities. Model aliases carry a kind tag so a chat model wired into a decision slot refuses config load with a named error. AWS Loom has no equivalent.
You want Teams-as-one-file state machines with decision nodes. A single TeamDef carries agents, skills, channels, schedules, and webhooks; routing nodes gate on Decision-tool probabilities; parallel + consolidator; durable Document-backed boards; interrupt-on-cap escalation.
You want whole-deployment Snapshots. One archive carries users, budgets, schedules, webhooks, memory peers, document sources, volume mounts, the Path tree, the consolidation queue, and HMAC-signed secret references. Restore re-validates against the current runtime version.
You want a published memory number, not a story. LoCoMo final retrieval 0.74; Documents retrieval 0.966; LoCoMo rerank recall@5 lifted from 0.588 to 0.740 by swapping a prose reranker for a decision one. AgentCore Memory ships but publishes no benchmark.
You want the operator to pay one bill, not five. loomcycle's operator pays the LLM API. That's it. AWS Loom stacks Bedrock + AgentCore + Secrets Manager + API Gateway + Agent Registry.
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
loomcycle vs Mastra — a TypeScript framework with an Enterprise licence vs a single Apache-2.0 Go binary.