AWS Loom - what the AI agent platform is and when it is worth adopting
If the pattern of many disconnected agents in one organisation is new to you, start with our article on agent sprawl. Loom is one of the market’s answers to that exact problem. Here we focus on the platform itself.
What is AWS Loom?
Loom for AWS (Loom) is an open-source platform for building, deploying, and governing AI agents, released in July 2026 under AWS Labs on the Apache 2.0 licence. It provides a single management UI and a backend API with Amazon Cognito authentication, scope-based authorisation, multi-persona navigation, and full lifecycle management for agents, memory, MCP servers, and agent-to-agent (A2A) integrations.
One thing to be clear about before going further: Loom is AWS Labs reference code, not a supported AWS product. That distinction changes the whole analysis, and we come back to it in its own section below. First, what Loom actually does.
Sources we reference: the Loom repository on GitHub and the AWS announcement.
The problem Loom solves
AWS gives you the building blocks for agents: a runtime, a gateway, a registry, memory, identity. But organisations still have to assemble those blocks into a platform themselves, with guardrails, least privilege, consistent tagging, and governance. Loom fills that “turn the blocks into a platform” layer.
The problem it addresses is classic agent sprawl: many teams, many frameworks, no shared layer for governance, observability, or cost control. Loom gives you one way to build and one way to govern, instead of three separate ones.
Concretely, Loom tackles seven recurring challenges that AWS names directly:
| Challenge | How Loom addresses it |
|---|---|
| Consistent resource tagging | Automatic, enforced tagging of deployed resources for cost attribution and governance |
| Access control | Role- and attribute-based controls (RBAC/ABAC), scope-based authorisation, per-persona access |
| Blueprints | A paved-path approach: patterns with good practices baked in for new services and use cases |
| Safe deployments | Testing, validation, and security scanning before deployment |
| Identity propagation | Managing identity across delegated actor chains |
| Agent and tool proliferation | Integration with AWS Agent Registry: a registry and an approval workflow |
| Human-in-the-loop | Enforced human approval before sensitive actions |
How Loom is built
Loom is not a standalone runtime. It is an opinionated layer on top of managed AWS services. The stack looks like this:
| Layer | Component | Role |
|---|---|---|
| Governance / UI | Loom | Management interface, lifecycle, governance, tagging, identity |
| Agent framework | Strands Agents SDK (default) or Google ADK | Agent logic, selectable per agent at deploy time |
| Runtime | Bedrock AgentCore (Runtime, Gateway, Identity, Memory, Observability) | Managed agent runtime infrastructure |
| Registry | AWS Agent Registry | Discovery and governance (opt-in), approval workflow |
| Models | Amazon Bedrock | Model inference (or self-hosting through a LiteLLM proxy) |
You can deploy an agent two ways: as a low-code option (a pre-written but configurable Strands agent on AgentCore Runtime) or as a no-code option through the managed AgentCore harness (generally available since June 2026). Loom sits on top of both and lets you trade customisation for simplicity.
Two details soften the usual lock-in worry. The framework is selectable per agent (Strands or Google ADK), and model calls can be routed through a self-hosted LiteLLM proxy instead of Bedrock. That matters if you have a requirement for local models.
Weighing up Loom or your own agent platform on AWS?
Book a free 30-min call
Loom is reference code, not a product
This is the most important section of the article, and the part most of today’s coverage does not say plainly.
Loom lives in an AWS Labs repository. That means:
- No SLA and no production support from AWS. This is not a service with guarantees. It is code you deploy at your own risk.
- Adopting Loom means owning a fork. Updates, security patches, and breaking changes become your problem. The repository is about two months old (as of September 2026), so expect churn.
- It is greenfield and opinionated by design. AWS states plainly that Loom is meant for platform engineering teams building a new application on fully managed AWS services. Anything that is not Strands or AgentCore has to be rewritten to fit its opinions.
None of this is a flaw. It is a deliberate design choice by AWS. But it changes the decision from “we deploy a platform” to “we take on maintenance of a reference fork”. With three existing, heterogeneous systems, that is a very different calculation than a clean greenfield.
When Loom is worth adopting, and when it is not
| Loom fits when... | Loom does not fit when... |
|---|---|
| You are building greenfield, with no existing agent systems to migrate | You have several existing systems on different stacks (not on AgentCore) |
| You are all-in on AWS and accept Bedrock as the default model source | You have a hard requirement for local, self-hosted models (only the LiteLLM proxy path) |
| You have a platform engineering team that will maintain the fork | You have no platform owner to take on maintaining the fork |
| You accept the lack of an SLA in exchange for a ready-made paved path | You need vendor support and a stability guarantee |
A simple rule: Loom is excellent as a pattern to learn from and as a starting point for greenfield. Taking a hard dependency on a two-month-old AWS Labs repository as your “enterprise platform” is a different risk decision. It is worth making with your eyes open.
Alternatives to Loom for AWS
An important distinction first: we mean Loom for AWS (the AWS Labs agent platform), not the screen-recording tool of the same name. The alternatives sit on a spectrum, from least lock-in to most opinionated:
- AgentCore building blocks, without Loom. Use the same services Loom is built on (AgentCore Runtime, Gateway, Identity, Memory, Observability, plus Agent Registry) and write a thin governance layer yourself. You get every governance capability Loom offers, without depending on the fork. AWS Agent Registry has been generally available since 31 August 2026, so the registry, the approval workflow, and cost attribution are managed services today, not something you have to build.
- Loom as a pattern, not a dependency. Take its patterns (the registry workflow, the tagging strategy, the scope model, the human-in-the-loop gates) but do not take a hard dependency on the whole codebase.
- A framework-neutral governance layer. A gateway, registry, and observability in front of your existing runtimes, with no rewrite. This is the choice when the goal is “connect what we already have” rather than “standardise on one runtime”.
- Other agent platforms and frameworks (if portability beyond AWS matters): LangGraph Platform, CrewAI, Microsoft Agent Framework / Semantic Kernel, Google ADK (which Loom itself supports as an alternative framework).
For most organisations with existing systems, the most sensible starting point is option 1 or 2: managed AWS services plus a thin governance layer, treating Loom as a reference to learn from rather than a platform you inherit along with its maintenance.
Costs to watch
Loom itself is free (open source), but what sits underneath it is not. AgentCore is billed on consumption across several components (Runtime, Gateway, Memory, Identity, Observability), and Agent Registry has a consumption model with a monthly free tier. Loom adds enforced tagging and cost tracking on top. That is actually a plus from a FinOps point of view, because you see cost per agent from day one.
If RAG is in play (searching internal documents), add the fixed cost of OpenSearch Serverless, in the order of a few hundred dollars a month for a minimal OCU configuration, regardless of traffic. It is the most commonly underestimated line item in agent budgets.
When it is worth bringing in an external partner
- Many teams, many frameworks. Consolidation needs a neutral party that does not favour any of the existing systems.
- Agents with access to production data. Designing the identity layer and least privilege takes cloud security experience.
- The adopt / fork / alternative decision. This is an architectural choice with a long maintenance tail, not a one-off deployment.
- No platform owner. Nobody internally is responsible for a shared way to build and govern agents.
Summary
Loom is a solid AWS answer to agent sprawl. It gives you exactly the governance primitives organisations need: a registry, approvals, tagging, human-in-the-loop, identity propagation. But it is AWS Labs reference code, not a supported product, and it is designed for greenfield.
Three things to remember:
- Loom is a governance layer on top of AgentCore and Strands, not its own runtime. All the heavy lifting is done by managed AWS services.
- It is a fork you take on to maintain. No SLA, about two months on the market. Great to learn from, risky as a hard enterprise dependency.
- With existing systems, consider managed AgentCore building blocks plus a thin governance layer, using Loom as a reference. Agent Registry has been GA since August 2026, so you have governance as a service today.
We will cover AgentCore’s architecture and cost model in detail in a separate article.
Weighing up Loom or your own agent platform on AWS?
Book a free 30-minute call. We help teams choose between adopting Loom, adapting it, or building a lighter governance layer on Bedrock AgentCore, starting with an assessment of the current state and a target plan.
