Posts

In 2011, I wrote about the first day of the Opscode Community Summit. What stood out was the mix of people. Network engineers, sysadmins, and developers were in the same room, bringing different experience to problems they shared. People chose the discussions where they could contribute or learn something. The arrangement trusted them to decide where their time was useful. Reading Swamp’s Behavior-Centric AI Design brought me back to that post. The article explains an architecture, but the reason I care about it starts with the same belief: people who understand a problem should have the means to do something about it. Swamp gives that belief a practical form for working with AI. ...

Swamp launches officially today. The team asked whether I’d write something for the launch, and I said yes on the condition that it be what I actually think. I’m a user, a community contributor, and a paying customer. Best effort I was trying to get an agent to work with the infrastructure tools I already had. CloudFormation ran some stacks and Terraform ran others. I wanted an agent in the middle to plan changes, apply them, and tell me what happened. ...

Short enough to remember, precise enough to disagree with. 1. Observation is the primary operation Action follows observation; it never precedes it. A system that acts without first observing is blind, regardless of how sophisticated its declaration layer is. 2. Scaffolding is removable. Principles are not Autonomy, locality of knowledge, voluntary commitment, evidence over authority. These survive every tool generation. Sprint ceremonies, state files, approval queues, and required reviewers are scaffolding. The work is knowing which is which. ...

Mark Burgess shipped CFEngine in 1993, formalized promise theory with Siri Fagernes around 2005, and published In Search of Certainty in 2015. The model is precise: autonomous agents observe their environment, reason locally about what they find, and make promises about their own behavior. The agent does not receive instructions from a controller. The agent looks around, decides what to do, and commits to doing it. Every infrastructure tool since has claimed some lineage from this idea. Chef called its resources “convergent.” Puppet called its catalogs “desired state.” Terraform called its plans “declarative.” Ansible called its playbooks “idempotent.” ...

I opened issue #265 against my own extension after a load test told me something I didn’t want to hear. Ten workers, seven hours, and the sync rate had fallen by a factor of ten: throughput workers down from 0.10 iterations per second to 0.01, write-stress workers (one model, continuous writes) failing every single iteration once they passed number two hundred. The extension is a DynamoDB backend for swamp’s datastore layer, and the datastore layer treats storage as a path-addressable file tree: every model’s data lives at data/{model-type}/{model-id}/{data-name}/{version}/raw, with a metadata file alongside it. Sync follows a fixed sequence: acquire a lock, pull changed paths from remote, do the work locally, push the dirty paths back, commit an index update, release the lock. Whatever backend serves this sequence, S3, DynamoDB, or something else, sees whole-file transfers. It never sees an individual field write. ...

On July 20, @swamp/container-image merged into the official swamp extensions repository. @webframp/container-image, my extension covering the same domain, had been on the registry for 38 days already. Both handle OCI image builds, pipe passwords via stdin, branch on container runtime, and store digest and timing metadata. My first reaction was territorial. Someone rebuilt what I built, in the privileged namespace, without referencing the prior work. But the impulse to prevent overlap or require acknowledgment both lead to the same place: an ecosystem that discourages people from building things. That is worse than any amount of duplication. ...

I wanted to know if a swamp datastore could survive a swarm, so I asked an agent to design one, pointed it at ECS Fargate, and stepped away. A custom Docker image, a fleet of remote workers, and a simple execution plan: model method calls firing events as fast as the workers could generate them. The final cluster ran 517 tasks: 500 loop workers each pushing telemetry at roughly 1.22 events per second, a single orchestrator running swamp serve against 50 models on a shard-first S3 datastore, and 16 serve-dispatch workers standing by for workflow batches. At full tilt that’s north of 600 events a second, sustained. The point was lock contention: S3 versus my Postgres extension, under real concurrent write pressure, the kind a global team of hundreds would eventually produce whether I tested for it or not. ...

The drift-state extension makes zero AWS API calls. It reads data that other models already produced, diffs it against a stored baseline, and writes the result as typed versioned state. The “drift detector” is a composition function over existing observations. This matters because drift detection is usually sold as a feature of a specific tool. CloudFormation has drift detection. Terraform has plan. AWS Config has compliance evaluations. Each one instruments its own slice and reports on what it manages. Nothing composes across them. ...

Hand someone a typed model in swamp and ask them to define what data they want to capture. Watch what happens. The schema requires them to name the fields, specify the types, declare what constitutes a valid observation. Most people stall. Not because the tooling is hard. Because they have never been asked to articulate what they actually want to know with that level of precision. The same pattern repeats at every layer. Ask them to write a workflow DAG and they cannot specify which steps depend on which, because they have never separated their assumptions about sequence from actual causal dependencies. A CEL query against versioned data exposes the same gap from a different angle: you must know the question before you can ask it, and most people have never distinguished “what do I want to know” from “what does the system happen to show me.” ...

The declaration authorized the reconciler and the ceremony authorized the team, and neither required a trust decision because the scaffolding decided for them. The declaration told the blind tool what reality should look like. The ceremony told the blind organization what the work should look like. Both existed because the system could not observe for itself, so we built structures that made observation unnecessary by embedding the answer in advance. ...