Workflow

Picture three agents running concurrently against the same repository. One is implementing a feature. One is scanning the dependency tree for known vulnerabilities. One is validating that the infrastructure change will not violate the compliance baseline. They share typed state through a common data layer. When the security agent finds a vulnerable transitive dependency, the implementation agent sees that result immediately via a CEL query and adjusts its import before the PR is even open. ...

By default, swamp stores everything in local SQLite. This works until you close your laptop, sit down at your desktop, and discover that your agent has no memory of what happened an hour ago. The models are there (they live in YAML), but the runtime data, the execution history, the versioned outputs from every method run, all of it is trapped on whichever machine produced it. If you work on one machine, this is fine. If you work on two or three, it is a problem. Your agent starts cold every time you switch. The voice profile you refined yesterday on your laptop does not exist on your desktop. The health check workflow that ran at 03:00 on your VM has results you cannot see from anywhere else. You are running the same models against the same code, but the data layer is fragmented across physical locations. ...

If you have used swamp.club at all, you probably think of it as an infrastructure automation tool. The ecosystem gravitates that way. The most-pulled extension is @john/k8s with 15 model types wrapping the Kubernetes API. The examples in the docs show pod health checks and deployment workflows. The leaderboard is full of people automating infrastructure tasks. That framing is incomplete. What swamp actually provides is a typed, versioned, schema-validated data layer for AI agents. The primitives are: models with Zod schemas, immutable versioned data, method execution, and composable workflow DAGs. Those primitives do not care whether the data flowing through them is pod status or prose rules. ...

A collision is coming that most teams have not noticed yet. On one side you have the workflow your team actually uses. If you run a platform or operations team, it probably looks something like Kanban: pull-based flow, WIP limits, design sessions before implementation, a small number of states that everyone understands. The workflow exists to serve the people. You have spent years tuning it. It works. On the other side you have the lifecycle your AI agent needs. If you are using an agentic framework — Swamp, or something like it — the agent operates through a state machine with enforced transitions, upfront planning, adversarial review gates, and checks that physically prevent skipping steps. The lifecycle exists to constrain the agent. It works. ...