AWS open-sourced Loom for AWS on July 9, 2026, and if you build AI agents for a living, it is worth an afternoon of your attention. Loom is a management platform for building, deploying, and running agents on Amazon Bedrock AgentCore Runtime. It ships as a full stack you deploy into your own account, not a hosted service you rent. The interesting part is not the feature list. It is the architecture, because the diagram tells you exactly how AWS thinks a production agent platform should be wired.
So let’s read the diagram. The whole thing fits on one screen, and once you see how the pieces connect, the design decisions make sense.
What Loom for AWS actually is
Two open-source projects sit underneath Loom, and you need both to follow the rest of this.
Strands Agents is the SDK that defines an agent. An agent in Strands is three things: a model, a system prompt, and a set of tools. That is it. The SDK has real traction, with over 150,000 PyPI downloads and teams like Amazon Q Developer and AWS Glue running it in production. Loom uses Strands to describe every agent it deploys.
Amazon Bedrock AgentCore is the runtime those agents run on. It went generally available on October 13, 2025, and it gives agents things that are annoying to build yourself: eight-hour execution windows, per-session isolation, managed memory, a gateway for tools, and identity handling. Loom deploys to AgentCore Runtime so it does not have to reinvent any of that.
Loom is the layer on top. It is the UI, the control-plane API, the authentication, the cost tracking, and the governance that turns “I have an agent SDK and a runtime” into “my platform team can hand agents to 200 engineers without losing sleep.” Heeki Park, the AWS solutions architect who wrote the launch post, describes the design in three words: simple, opinionated, enterprise-grade. The opinionated part is what shows up in the architecture.
How Loom composes an agent
Before the deployment view, there is a smaller diagram in the repo that shows what goes into a single agent. A pre-written Python agent pulls in a system prompt, a memory resource, one or more MCP servers, and any agent-to-agent (A2A) connections. Secrets Manager holds the credentials. The output is a deployed agent. Nothing here is generated at runtime, which is a deliberate security choice I will come back to.
Reading the AWS deployment diagram
Here is the full cloud deployment, phase three in Loom’s model, running entirely on AWS. Follow it left to right and the split between public and private jumps out.
The public edge: get the user in, then stop
A user hits Cognito first. That is authentication, and nothing behind it responds until Cognito issues a token. Loom also federates with Entra ID, Okta, Auth0, or any OIDC provider, so most enterprises can plug in their existing identity setup instead of managing a second user directory.
From there the request goes through Route 53 for DNS and lands on an Application Load Balancer. The ALB sits in the public subnet with an ACM certificate for TLS. It is the only thing exposed to the internet, and it is doing routing work: /api/* and /health go to the backend, everything else (the default) goes to the frontend. That is the entire public footprint. One load balancer, one certificate, one auth gate.
The private subnet: where everything real lives
Cross the boundary into the private subnet and you find the actual application. Two containers run on ECS Fargate, with images pulled from ECR:
- The frontend, a React app built with shadcn/ui and Vite.
- The backend, a FastAPI service in Python that does the real work.
The backend talks to a Postgres database, but not directly. It goes through RDS Proxy, which sits in front of RDS Postgres. That extra hop matters under load. RDS Proxy pools and reuses database connections, so a burst of agent activity does not exhaust Postgres connection limits. It is the kind of detail you only add after you have watched a database fall over.
The backend also drives the agent side of the house. It hands the Strands agent definition off, ships the zip artifacts to S3, and registers the agent with AgentCore Runtime. Once that is done, AgentCore runs the agent. Loom’s job was to configure and deploy it, not to host the execution.
Why the public/private split is the whole point
Plenty of teams would put the frontend and backend in the public subnet because it is easier. Loom does not, and that is the opinion baked into the diagram. Only the load balancer touches the internet. The application, the database, and the agent artifacts all sit in private subnets with no public route in. If someone finds a hole in your frontend, they still cannot reach Postgres directly.
This lines up with the second opinion Loom enforces: no runtime code generation. Some agent platforms let a model write and execute code on the fly. Loom refuses. Every agent is deployed from configuration and pre-written Python, so there is no path for a prompt to talk its way into running arbitrary code on your infrastructure. Combined with the network layout, you get a platform where the attack surface is small and the blast radius is contained.
The governance features sit on top of this foundation. Loom does automated resource tagging (loom:application, loom:owner, and a group tag), fine-grained role-based and attribute-based access control, RFC 8693 token exchange so an agent acts with the calling user’s permissions instead of a shared service role, and human-in-the-loop approval workflows for sensitive tool calls. It also integrates with AWS Agent Registry, where agents deploy in a DRAFT state and an admin has to approve them before anyone can use them. None of that works if your network is flat and your database is public.
The three ways to run it
You do not have to deploy the full AWS stack on day one. Loom supports a progressive model with three phases, and the diagram above is only the last one.
- Phase 1, local. Run the whole UI on your laptop with SQLite and Cognito auth. No AWS compute at all. You can deploy and invoke real agents while iterating with hot reload on both frontend and backend.
- Phase 2, hybrid. Push RDS Postgres to AWS and tunnel to it over SSM while still running the app locally. This is where you test against a production-grade database and share one dataset across the team.
- Phase 3, cloud. The diagram we just walked through. Frontend, backend, and database all on ECS Fargate behind the ALB, reachable over HTTPS on your own domain.
Starting local is the right call. You get the real product behavior without paying for a single Fargate task, and you only graduate to the cloud diagram once the thing earns it.
What it costs to run
Loom itself is free and Apache-2.0 licensed. The bill comes from what it deploys. The Fargate tasks, the RDS instance, and the load balancer are standard AWS charges you already understand. The new line item is AgentCore Runtime, which uses consumption-based pricing: $0.0895 per vCPU-hour and $0.00945 per GB-hour, billed per second on active resource use. When your agent sits idle waiting on I/O, you are not paying for CPU. That model is friendly to spiky agent workloads and unfriendly to agents that never sleep, so watch the ones that poll.
Who should actually use this
Loom names its audience plainly: platform engineering teams building greenfield agent applications on fully managed AWS services. If that is you, Loom saves you from hand-rolling Cognito wiring, IAM roles, credential providers, and a deployment pipeline for every agent. If you are one developer shipping a single agent, this is far more platform than you need, and the Strands SDK on its own will get you there faster.
One honest caveat: AWS ships Loom “as-is,” with no SLA and a warning that breaking changes can land between releases. Read it as a strong reference implementation and a head start, not a product with a support contract. Fork it, understand it, and own what you deploy.
Frequently asked questions
Is Loom for AWS free?
Yes. Loom is open source under the Apache 2.0 license. You pay only for the AWS resources it deploys, mainly ECS Fargate, RDS, the load balancer, and AgentCore Runtime usage.
What is the difference between Loom, Strands Agents, and Bedrock AgentCore?
Strands Agents is the SDK you use to define an agent. AgentCore is the managed runtime that executes it. Loom is the platform layer that deploys, governs, and tracks agents built with Strands and running on AgentCore.
Do I have to deploy the full AWS stack to try Loom?
No. Phase 1 runs the entire UI locally with SQLite and no AWS compute. You can move to a hybrid setup and then full cloud deployment when you are ready.
Does Loom run agent code that a model generates on the fly?
No, and that is intentional. Loom deploys agents from configuration and pre-written Python only. There is no runtime code generation, which closes off a common security risk in agent platforms.
The takeaway
Loom for AWS is a working answer to a question most teams are still figuring out: how do you let a lot of people build agents without handing every one of them a set of IAM keys and hoping for the best. The architecture answers it with a single public load balancer, everything else private, no runtime code generation, and identity that follows the user down to the tool call. Clone the repo, run phase one locally, and read the diagram with your own security team in the room. That conversation alone is worth the download.
