Your agent is clicking in the console, just faster

You have a coding agent running on your laptop and an infrastructure change to make. Count the options. It can shell out to the AWS CLI one command at a time, which is ClickOps with a different operator. The CLI automates fine when somebody saves the script and reviews it. What an agent produces that way is a string of ad hoc commands nobody keeps. The model underneath is non-deterministic as well, so the sequence it ran this morning isn’t reliably the one it runs this afternoon. Overrun the context window and it forgets what it already created and fills the gap with guesses. Point it at Terraform instead and you get repeatability, but Terraform was built for a different paradigm: a person writes the file, reads the plan, argues about the module in review.

So the question isn’t whether an agent can change your infrastructure. It can, and quickly. It’s whether what it did can be run again next week by someone else, and whether you saw it before it hit production. The tools that exist were designed for the other operator.

Paul Stack, Director of Product at System Initiative, has spent two decades in infrastructure and wrote providers for both Terraform and Pulumi. The product he has been working on for the last few years built infrastructure by connecting components on a canvas. It no longer exists. What replaced it is a local CLI called Swamp, released under AGPL v3 with nothing built in, and the reasoning behind the swap is worth more than the product news.

Why the drag-and-drop editor lost

Start with the part that failed, because it shapes what came after.

Why throw away five and a half years of product?

The part customers liked had only existed for a few months, and it was a CLI with an agent in front of it.

Visual composition was slow and cumbersome, and it sat at an angle to the ecosystem. Everyone is used to code: to artifacts in a repository, to reading a diff before anything ships. Changes did get held back for review, in change sets that need approval before they apply, but that review happens inside the tool and over a graph, rather than in the pull request your team already runs. In summer 2025 System Initiative spiked a public API with an OpenAPI spec, and a customer built an MCP server on top of it. It was a rough prototype with no thought given to token usage, and people had tremendous success with it anyway. That was the signal. An official MCP server and a CLI followed, and users iterating from a terminal got a better experience than the canvas ever gave them.

Then the bill arrived.

Three weeks in December went into rebuilding that server around progressive disclosure, the idea Anthropic describes for Agent Skills: a name and a description up front, the rest loaded only when it matters. Even rebuilt, the architecture underneath kept costing money. A hosted API pushes data up and down in the hope that it’s the data the agent wants, and an agent wants a lot of context.

By Christmas 2025 the conclusion was that the product’s future wasn’t a SaaS platform, while the company was still carrying hundreds of thousands of lines of Rust across several services built for the old one. The decision came in mid-January 2026, and a company of 17 became a company of five. The reasoning given is blunt: when you don’t know what you’re building, swinging that many people around is unfair to them, bad for their careers, and expensive. The five who stayed have initials that spell SWAMP, which nobody planned and everybody kept.

Models, workflows, and no batteries at all

The name is a joke. What it describes is not: a pile of data that isn’t pretty, isn’t a data lake, and is shaped for something other than a human to read.

What does Swamp ship with?

No models at all. The schema for the thing you want is written on demand.

It’s general purpose rather than infrastructure-specific, and two concepts carry it. A model is a schema with explicit inputs, outputs and methods. The methods aren’t the four an IaC tool gives you: alongside create, read, update and delete you can define analyze, or anything else, with the logic inside the method. It isn’t declarative; it’s an imperative model you chain operations through. A workflow is the part that touches the real world, whether that’s an API, a CLI or some engine you have to talk to, and workflows chain data between steps with CEL expressions, the same dot-notation referencing Kubernetes uses in its API.

The hello world is a VPC and two subnets. You have a model for each. Step one of the workflow creates the VPC, and the subnet’s input is the VPC model’s resource.attributes VPC id, where a Terraform file would have carried both resources and the dependency between them implicitly.

That’s the piece the old product got wrong. System Initiative called itself extensible, and in retrospect it was extensible the way anything is if you’re willing to write the code yourself. On the morning we recorded, a user in Discord asked Swamp for a schema to issue Let’s Encrypt certificates and got the model, the methods and the interactions on the first try, without writing code. There is history behind that: System Initiative’s own models were derived from real interfaces, AWS from CloudFormation and the Cloud Control API, Azure from the REST specs, Google from the discovery documents.

Where this sits next to skills, scripts and MCP

If the agent writes the models, the obvious question is what the agent is reading when it does that.

Is Swamp a tool the agent calls?

No. It’s the structure the agent builds inside, and the agent reaches it through ordinary shell commands.

Three things already live in your agent setup. A skill is a Markdown file the agent loads at runtime to learn how you do something, and installing one is a fancy way of saying you copied someone else’s Markdown file. A script ships next to it, so the agent runs one command instead of stumbling through five. A tool is what the agent calls: Bash runs, output comes back, it decides what to do next.

Swamp is none of those. It isn’t an AI wrapper and it isn’t a chatbot. It’s a structured interface that makes the agent’s work repeatable, plus a workflow engine underneath: evaluation before a run, tags, multiple environments, workflows that trigger other workflows. The skills are how the agent learns the architecture it has to stay inside.

Proxmox in a home lab is the example that makes it concrete. One of the Swamp team runs his hypervisor through it: create a VM, start it, inspect it, report versions and utilisation across the box. He wired it to Discord the week we recorded, so friends who run game servers on that hardware can ask for a VM in chat and get one, inside the automation rather than around it. The workflow goes further than provisioning usually does: check what exists, create what’s missing, wait for the VM to initialise, SSH in, install the agents and tools. Terraform reaches the same place with provisioners and a local exec or two.

Who presses run

A workflow engine the agent can write for you raises the question of who is allowed to run it.

Does the agent run the workflow it just wrote?

It can. The recommended setup is that it doesn’t.

You can run this in YOLO mode and let the agent execute its own workflows. That isn’t the suggested way to use it. The suggested way: the agent generates the models and workflows, all of it goes into Git, and a person runs the right workflow against the right environment, or GitHub Actions does at a time somebody chose. On the machine where Swamp itself gets built, a Claude Code deny rule on workflow run stops the agent from starting one. Read that as a guard against an accidental run rather than a wall. Claude Code’s own documentation says a Bash rule matches the command text the agent writes and isn’t a security boundary around the program, because the same binary invoked another way goes straight through. What bounds a bad run is the credentials the agent’s shell can reach. Peers review the workflow before it touches production, which is the part the ops world has a compliance story around.

Reuse follows from the same place. Say the workflow logs into an EC2 instance, installs Prometheus and Grafana, and checks that an alert actually lands. You don’t copy it for the next host. Models and workflows take inputs, so the second run is the same workflow with different parameters, and a run missing a required one stops and tells you what it doesn’t know. It’s code, so you refactor it like code: split a workflow that grew unmanageable, and have a parent orchestrate the children and collect the results, the way a GitHub Actions workflow calls other workflows and waits on them.

Written for an agent to read, not a team to debate

That reusability argument applies to Terraform modules too, which raises the fair objection: why not point the agent at the modules you already have?

Why isn’t a good Terraform module enough for an agent?

Because its interface was designed to be argued about by people, and most of what the agent needs isn’t in it.

Take the AWS VPC module Anton Babenko maintains, which is as good as Terraform modules get. It carries something in the region of 237 inputs, and variables.tf at v6.6.0, the release current when we recorded, defines 236 of them. Many of the internals are stylistic, decided by maintainers, written so a team can read the result and agree to it. An agent working through that has to hold the Terraform version, the module version, the module structure and the house style all at once, and it will guess at some of them.

The second difference is history. Gradle, Terraform and the rest give you one-off runs. Whatever record exists of the last five days lives somewhere else, in your CI logs or your build server, and you have to go collect it and feed it back in. Swamp keeps its data in the .swamp/ directory next to the code, where the agent already is. Ask what happened in this workflow over the last five days and the answer comes from there.

Getting Terraform out the other end

None of this helps if adopting it means a migration, which is the first thing anyone with a live estate asks.

Can it produce Terraform?

Yes, and that’s a reasonable thing to want it to do.

Someone asked whether Swamp could shell out to Terraform and write Terraform configuration. It can. The output format isn’t the interesting part from the model layer’s side, because what it owns is the type system the agent reasons inside.

The relationships between resources came out right, for the reason that runs through the whole argument: the agent had a model to work within, so its decisions were narrow enough to make well. That’s also the limit of the demo, which ran live on a Discord call, by the person who wrote the tool, on infrastructure he had just modelled.

The adoption path is the same shape. You don’t throw away years of Terraform for Swamp to be worth anything. Run it alongside what you have, ask it questions about your infrastructure, use it to check what your existing IaC actually does. Swamp isn’t a better Terraform and isn’t trying to be. It makes different assumptions about who is doing the work.

An AGPL licence and the money question

A tool with nothing built in and no hosted service has an obvious hole in it, and it was worth asking about directly: where does the money come from?

How does a company make money from a CLI it gives away?

It hasn’t worked that out yet, and says so plainly.

The sketch is a marketplace: the community publishes models and workflows, and the company sells supported, maintained versions of the ones everybody needs, a well-kept EC2 instance model next to the fifteen community ones. Docker Hub is the reference point, official images sitting beside everything else, and Terragrunt is the other, supplying workflows the Terraform ecosystem was happy to adopt. None of it is the current focus, and monetisation is an easier problem once users care about the tool.

Underneath sits a blunter claim about the market.

If someone dislikes Terraform enough, they will build their own, and the design time is no longer the barrier it was. So the bet is extensibility rather than ownership: make it cheap for users to write their own schemas and workflows, so they extend the thing instead of cloning it. For you the practical question is the licence rather than the business model. AGPL v3 obligations bite when you modify the program and offer the modified version to users over a network, which is a conversation to have with whoever signs off licences before it becomes load-bearing in your platform.

Ops teams, or testing?

There’s a claim buried in all of this about who is slowing delivery down, and it’s where we disagree.

Where is the bottleneck once AI writes the code?

Paul says ops teams are about to become it. Andrey says it’s testing, and he’s going by his own week.

The argument runs like this: productivity in software development is going through the roof, and ops teams are on their way to becoming the bottleneck they used to be. We have been here twice. Physical servers to cloud was one such moment, cloud to infrastructure as code another, and each time the tooling changed before the teams could move faster.

Andrey agrees with the premise and disagrees about the constraint. Developers do ship faster now, they don’t want an infrastructure team standing in front of them, and infrastructure teams do need to work differently. But the thing stopping his own loop isn’t deployment. Idea to analysis to design to plan to implementation to pull request already runs on its own. The gap is testing. With end-to-end tests and a serious harness you’re golden, because the agent has something to fall back on that keeps the work aligned. Without them you spend the time building the harness, and never get to the deployment part to find out whether the infrastructure tooling was the problem.

That lands, and the reply is a reframe rather than a defence: peel away the layers that make you slow, and if nobody has to hand-write a hundred models for one use case, that time goes into the harness instead.

What this means for teams

Whether to adopt Swamp isn’t the useful question. If your agent already has cloud credentials, what it may execute and who starts the run are decisions somebody has to make, and the parts of this that transfer don’t need anyone’s CLI.

Four things worth doing this week:

• Decide what your agent may apply, then back it with credentials. Put the apply or run command behind a deny rule in the agent’s settings, keep the generated plan in Git, and make a person the one who starts it. A deny rule catches the accidental run and not the creative one, so give the agent’s shell read-only credentials and keep the ones that can change infrastructure on the path a human or CI starts.
• Price one MCP server. Take the one your team uses most, run a typical task, and look at what it pulled into context. A server that ships everything on every call charges you for it on every call.
• Turn one runbook into something with inputs. Pick the sequence you repeat per environment, have the agent write it as a parameterised workflow, review the diff, run it yourself. Whether it lands in Swamp, a Makefile or GitHub Actions matters less than the parameters.
• Check whether your tests can referee. If the agent can produce a change you can’t validate automatically, invest there first, whatever your IaC tooling looks like.

Common questions, answered

How do I stop my coding agent from applying infrastructure changes I haven’t seen?

Deny the apply command in the agent’s permission settings, and give the shell it runs in credentials that cannot make the change. The deny rule is the cheap half: in Claude Code it names the command in the settings file, and the documentation is explicit that a Bash rule is not a security boundary, since the same program invoked another way is not matched. Read-only credentials hold when the rule misses. Commit the generated automation to Git so a reviewer reads it as a diff, then run it from CI, where the credentials that can write live.

Can I try an agent-native infrastructure tool without migrating off Terraform?

Yes, and running it alongside is the sensible first move. Install it against an environment you already own, model one or two resources, then ask it questions about what’s deployed and compare the answers with what your Terraform says should be there. Nothing takes over the state file or the apply. It can also generate Terraform configuration from the models you build, so the thing that provisions your infrastructure stays as it is while you find out whether the model layer earns its place.

What does AGPL v3 mean for using this at work?

Running an unmodified AGPL v3 program on your own machines triggers no obligation to publish anything. The clause that separates AGPL from GPL applies once you modify the program and let people interact with your modified version over a network: GNU’s own FAQ says those users must be offered the corresponding source, and it draws no line around users who happen to be colleagues. So the test is whether you changed the code and exposed that copy over a network, not who the users are. Ask whoever approves licences before it reaches the critical path.

Related episodes

• Episode 70, System Initiative Goes GA is the same product at general availability, built around the canvas that this pivot discards.
• Episode 55, Unpacking System Initiative with Paul Stack is the original pitch, and the clearest picture of what the visual approach was trying to fix.
• Episode 89, Agents, Reviews, and Secrets: Real Talk on AI in Dev covers what else an agent reaches on the way through your environment, credentials included.
• Episode 86, MCP plugins: your next security blind spot? is the other half of the MCP story: every server you connect adds attack surface as well as tokens.

Resources

• Swamp on GitHub is the CLI itself, including the licence, the models and workflows, and the skills it installs for the agent.
• System Initiative change sets documents the isolated proposed changes and the approval before apply that the hosted product worked through.
• Anthropic, Equipping agents for the real world with Agent Skills settles what a skill is and how progressive disclosure keeps one cheap until it’s relevant.
• Claude Code permissions documents the allow, ask and deny rules, and states that a Bash rule covers the invocation the agent usually writes rather than the program itself.
• CEL, the Common Expression Language is the syntax used to chain data between workflow steps, and Kubernetes CEL shows the same dot-notation in a system you probably already run.
• AWS Cloud Control API is the uniform AWS interface System Initiative derived its AWS models from in the hosted product that preceded Swamp.
• terraform-aws-modules/terraform-aws-vpc, variables.tf at v6.6.0 is the input list behind the 237 figure, with 236 variables in the release current when we recorded.
• GNU Affero General Public License v3 is the licence text, including the network clause that separates it from the GPL.

Since we recorded

Swamp now lives under the Swamp Club organisation: systeminit/swamp redirects to swamp-club/swamp, and the project manual sits at swamp-club.com. The vocabulary moved with it, so what this piece calls models are now behaviors, with swamp model kept as a supported legacy spelling and no migration needed for existing repositories. The tool has also grown an extension registry, credential vaults and a datastore that still defaults to the same .swamp/ directory. Paul came back three weeks later for Episode 94, Small Tasks, Big Wins: The AI Dev Loop at System Initiative, the how-they-build-it conversation this one ran out of time for, and Episode 101, Infrastructure as Code in 2026 picks up the wider question of what IaC is for now.