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.

What each one is

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.

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. 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. These are all shipped. AWS Loom's surface is Agent + Memory + MCP + A2A + Tags.
• 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.

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