Skip to content

Why Agents Need an Infrastructure Package Manager

BigConfig as an infrastructure package manager for Agentic DevOps

Kief Morris recently published Why I have my agents write infrastructure code , and it is one of the clearest articulations of Agentic DevOps I have read. His central observation is hard to argue with: when you let an agent drive the AWS CLI directly, it takes multiple tries, casually blows away data, and replaces solid implementations with slow, less-reliable alternatives. But when you ask an agent to write reusable infrastructure code instead of executing low level CLI tools, you get something much safer: a composable, auditable artifact that a human can review before anything touches production.

We agree with everything in that post. In fact, we have been building exactly the ecosystem he envisions—we just call it a package manager.

Morris frames the problem as an agent adapting pre-existing components to specific needs. The missing piece, as he notes, is the ecosystem of components itself. Without it, agents fall back to generating raw HCL or shell scripts from scratch, which is precisely where hallucinations and cascading failures live.

This is the same gap the web ecosystem solved between 2010 and 2015. Before React and npm, every JavaScript developer rewrote the same DOM manipulation logic from scratch. After React, the ecosystem converged on components. A developer—or today, an agent—doesn’t write a date-picker from scratch; they install one from a registry and wire it into the application.

DevOps needs the same shift. BigConfig is the attempt to make it happen.

BigConfig is a Clojure-based infrastructure package manager. The mental model is intentionally close to npm or Maven:

  • Packages are versioned, composable units of infrastructure logic (compute, DNS, SMTP, Kubernetes controllers, etc.)
  • The lock file records the exact versions resolved, so every bb bigconfig apply is deterministic
  • Babashka executes the packages locally—no server, no daemon, no state machine to manage

When an agent works with BigConfig, it is not guessing Terraform resource attributes or wrestling with provider schema drift. It is composing packages the same way a React developer composes components: declare what you want, let the abstraction handle the how.

bb.edn
{:deps {io.github.amiorin/once {:git/url "https://github.com/amiorin/once"
:git/sha "8ffbbc2ea0974365575c7ee44b7d890e69447144"}}
:tasks {:requires ([io.github.amiorin.once.package :as pkg])
package {:doc "bb package create | bb package delete"
:task (pkg/once*
*command-line-args*
{:big-config.render/profile "online"
:big-config.workflow/params
{:domain "bigconfig.online"
:package "online"
:once {:applications [{:host "www.bigconfig.online"
:image "ghcr.io/amiorin/big-config-website:latest"}]}
:provider-compute "oci"
:oci-config-file-profile "DEFAULT"
:oci-display-name "bigconfig-online"
:oci-shape "VM.Standard.A1.Flex"
:oci-ocpus 1
:oci-memory-in-gbs 6
:oci-boot-volume-size-in-gbs 50
:oci-boot-volume-vpus-per-gb 30
:oci-ssh-authorized-keys "~/.ssh/id_ed25519.pub"
:provider-smtp "resend"
:resend-server "smtp.resend.com"
:resend-port 587
:resend-username "resend"
:provider-dns "cloudflare"
:provider-backend "s3"}})}}}

An agent reading this file understands the intent immediately. It does not need to know the Hetzner API, the Cloudflare zone API, or the Resend domain verification flow. Those details are encapsulated inside the package.

Morris notes that unlike static libraries, agents can adapt code to specific needs. This is where the language matters. Clojure’s data-driven programming model means that infrastructure packages are, at their core, plain data maps. An agent can read them, modify them, and reason about them without parsing a DSL or reverse-engineering a class hierarchy. The code that acts on the data is small and testable independently.

Babashka—the scripting runtime we use—runs the same Clojure source without a JVM startup penalty, which means an agent can invoke bb package create as naturally as it runs terraform apply, but with far more predictable outcomes.

One concern Morris raises is the tension between reusability and adaptability. A static library forces you into its abstractions; you fight it the moment your requirements diverge. BigConfig avoids this by treating packages as data transformations rather than black-box executables. Each package exposes its intermediate data before it runs, so an agent—or a human—can inspect and override specific values without forking the package.

This is the same principle as React’s props. You do not rewrite the component; you pass different props. In BigConfig, you pass different configuration keys.

The once package is the first published example: a complete personal PaaS (compute + DNS + SMTP) that an agent can provision on Hetzner or OCI with a single command. More packages are in progress for Kubernetes namespaces, observability stacks, and database clusters.

Each new package is a node in the ecosystem Morris envisions. Each one reduces the surface area an agent must hallucinate, and increases the confidence that what gets applied to production is what was intended.

Morris’s post ends with a hopeful note: if agents can adapt working, pre-built code to specific needs, we may have the basis for a healthy ecosystem of infrastructure components. We share that hope, and we think the path there is clear:

  1. Stop asking agents to write raw Terraform. They are being asked to generate “assembly code” for infrastructure, and they will keep making assembly-level mistakes.
  2. Build or adopt a package layer. The package is the unit of trust, not the generated file.
  3. Let the agent compose, not author. The moment the agent’s job becomes “pick the right packages and supply the right configuration,” the error rate drops dramatically.

If you are thinking about how to structure infrastructure for an agentic world, the package manager mental model is worth exploring. BigConfig is one implementation of that idea, built in Clojure with Babashka, and it is open source.

To see how your agent can operate a BigConfig package that encapsulates multiple Terraform resources and Ansible playbooks, start at the BigConfig Demo .