What loomster is

loomster deploys awslabs/loom — an AWS Labs sample for building and running Bedrock agents — as real, tiered infrastructure you can stand up yourself. Six components, three tiers (light / production / production-ha), generated CI, and a seed step that leaves the app usable on first login, not only serving. It is pinned to Loom v1.6.0; upstream is a moving as-is sample, so expect breaking changes between versions.

It is built with chant, which types and lints the infrastructure and generates the pipeline — but you don’t need to know chant to run loomster. You need the verbs in the Tutorial, and an agent can run them for you.

Drive it with your agent

Clone the repo and your agent already knows how to operate it:

git clone https://github.com/INTENTIUS/loomster
cd loomster && npm install

The commands run from here, and two things are already wired in the checkout:

• A loomster skill (skills/loomster/SKILL.md) — the capability map an agent reads on its own: every lifecycle verb (deploy, seed, validate, back up, reconcile, tear down), the golden paths, and the guardrails that keep a deploy from locking itself out.
• chant’s MCP server — chant serve mcp (stdio) exposes build, lint, list, describe, diff, and the Op tools, for inspecting and building the graph directly.

Once you’re in the checkout, ask your agent to “stand up Loom locally” or “deploy the light tier and validate it” — the skill tells it which commands to run and what not to touch.

Where it runs today

• The full stack builds Loom’s real images and runs on Floci, a local emulator, at localhost:8080 — no AWS account.
• The light tier is deployed end to end to a real AWS account: a real ALB, backed by real RDS and Cognito.
• production is validated end to end on a real AWS account — 7/7 stacks CREATE_COMPLETE, including RDS Proxy, PrivateLink, an ACM cert on a custom domain, backend autoscaling, and the agents wave: the Strands assistant’s code-config Runtime reaches READY on Bedrock AgentCore, and the app is served over HTTPS. All 15 screens are validated behind real (MFA-enforced) Cognito: the harness mints a throwaway admin against the deployed pool, seeds the foundation floor through that token, and reads every screen — so the live proof covers the stacks, the tier resources, the served app, the agent runtime, and the authenticated UI.
• production-ha is validated end to end on a real account too — 7/7 stacks CREATE_COMPLETE, adding Multi-AZ RDS and a live HostedRotationLambda credential rotation. It also proved multi-deployment: it ran as a second instance alongside production in the same account.

The Screens reference maps the running app back to the deployment decisions behind it — what each screen shows, what’s seeded, and what is left empty on purpose.

Components

Six stacks, deployed in dependency order:

Component	Depends on	What it is
shared-foundation	—	ALB, ECS cluster, ECR, KMS, S3 artifact bucket, DNS, agent IAM role
loom-cognito	—	Cognito user pool, hosted-UI domain, resource server, clients
loom-db	shared-foundation	RDS Postgres, Secrets Manager; production adds RDS Proxy + rotation
loom-frontend	shared-foundation	The frontend ECS Fargate service
loom-backend	shared-foundation, loom-db, loom-cognito	The backend ECS Fargate service
loom-agents	shared-foundation, loom-cognito, loom-backend	The Bedrock AgentCore agents — the low-code Strands assistant (code-config Runtime, every tier). No-code harness agents are created on demand through Loom’s own app; a bring-your-own container agent can be pre-provisioned with LOOM_HARNESS_AGENT_IMAGE_URI

loom-frontend and loom-backend each run build, publish, apply, verify, with a rollback compensation phase. Cross-stack inputs (cluster ARN, security group, target group, the DB secret, the Cognito pool, and more) resolve via stackOutput(...). A seventh stack in the graph, downstream-stub, is verification-only: it consumes shared-foundation’s outputs to prove they resolve, and is not part of Loom.

Org topology

Loom is one control plane with logical, group-based multi-tenancy, not hard isolation between teams. Two topologies:

• Single-boundary keeps one Loom and many Cognito groups. RBAC plus ABAC give each team a scoped view without a second deployment. Right when every team fits inside one compliance and account boundary.
• Multi-boundary runs many Looms, one per account, prod-vs-nonprod, or compliance domain, each a different instance. A shared org-level Cognito pool (or external OIDC IdP) is referenced by every instance, with groups and scopes defined once.

Rule of thumb: groups inside a boundary, a new Loom per boundary. The Tutorial’s Org topology section has the runnable proof that the two axes are orthogonal.

Known gaps

• production / production-ha aren’t yet applied to a live account. They deploy end to end on Floci — just production-floci-e2e stands the full stack up against a bring-your-own VPC and checks every tier-distinguishing resource — but the real-account apply is still the light tier’s alone.
• Agents deploy locally; only real agent execution needs AWS. The AgentCore Floci image emulates the control plane, so the agents wave reaches CREATE_COMPLETE locally and definitions are manageable everywhere. Invoking an agent returns a canned stub, not real reasoning — that needs AgentCore on a live account. See Run Loom on your laptop and Local caveats.
• No bastion composite, and Loom’s own upstream template doesn’t define one either.

The full seam-by-seam detail is in Adoption.