Running crews of coding agents as always-on infrastructure in AWS

Problem

Our infrastructure was IaC in AWS. In order for us to respond to the behavior of that infrastructure (orchestration runs, events, etc.) we wanted our Software Factory in the cloud, rather than local, hooked directly into what was actually running.

First principles

• An agent crew is a workload like any other. It needs isolation, scheduling, autoscaling and durable state.
• Agents need to be deployed as a layer on top of the infrastructure, not separate from it.
• Each business domain needs its own specialized processes, which requires its own crew and repositories, and communicate via EventBridge to identify when a downstream error requires an upstream fix.

Approach

Gas City is an open-source SDK for multi-agent coding workflows. A mayor plans, worker agents build, a refinery merges, a witness and a deacon watch health, and work items live in Beads. I built the AWS side:

• one EKS cluster per environment, with Karpenter adding and removing nodes as crews scale;
• CDK stacks for the network, the platform and the hand-off between them, with an IAM role per service account;
• jobs that keep each crew’s repositories in sync;
• about 12 “cities”, each bound to one business domain, such as the vehicle graph and the client platform.

Running it under load exposed bugs in the runtime itself, which I fixed upstream: for example #2712 keeps live session claims during the orphan sweep, and #2668 keeps Dolt error details in reaper escalations.

Skills I taught myself

• Kubernetes on AWS (EKS, Karpenter, IAM roles for service accounts).
• Multi-agent runtimes: roles, work queues and session lifecycles.
• Debugging agent systems from their logs, then fixing the runtime upstream.

Result

About 12 domain crews running on EKS, and fixes merged into Gas City, and an entirely AWS-native software factory with git repos, code changes, and deploys hosted inside AWS itself.