Traditional DevOps already provides powerful forms of reuse: infrastructure modules, pipelines, containers, configuration management, runbooks, and platform APIs. Agentic DevOps does not replace these foundations. It adds a reasoning layer capable of discovering, combining, adapting, executing, repairing, and verifying them.
As the library of previous work grows, that reasoning layer has increasingly more material to use.
New deployments no longer start from an empty canvas
The colors workspace contains a growing collection of Package Skills. Each Package Skill turns desired state into a tested, reproducible deployment.
A new Package Skill does not begin with an empty directory and a software manual alone. The agent can inspect existing packages and find examples of:
- Configuration schemas and parameter defaults
- Validation behavior and boundary invariants
- Provider integration (DigitalOcean, Hetzner, AWS, GCP, OCI)
- Credential handling and strict
COLORS_PAR_*environment indirection - Infrastructure provisioning via OpenTofu
- DNS and TLS configuration through Cloudflare and Caddy
- Service installation via Ansible templates and systemd units
- Health and acceptance checks with automated assertions
- Backup and recovery procedures (S3, Cloudflare R2, WAL streaming)
- Safety guards like
compute-prevent-destroy - Testing and documentation conventions with golden fixtures
These examples reduce uncertainty. Instead of inventing every decision, the agent can identify the closest existing architecture, reuse established components, and focus its reasoning on what is genuinely different about the new software.
Reuse happens at two levels
Package Skills can be composed at both the function level and the workflow level.
At the function level, an agent can reuse focused capabilities such as:
- Discovering a cloud network
- Creating a server
- Rendering configuration
- Installing a service
- Managing DNS records
- Issuing certificates
- Running health checks
- Producing backups
At the workflow level, it can reuse larger operational sequences:
- Validate configuration
- Build generated artifacts
- Provision infrastructure
- Configure the machine
- Deploy the application
- Verify public health
- Test restart recovery
- Report evidence
Workflow-level reuse is especially important. It preserves not only implementation code, but also operational ordering, safety boundaries, failure handling, and verification behavior.
The result is more than a code library. It is a library of proven operational decisions.
The workspace becomes executable knowledge
Every successfully completed Package Skill contributes several reusable assets:
- Functions: Composable Clojure/Babashka, TypeScript, or Python modules.
- Workflows: Deterministic DAGs with clear phase boundaries and error recovery.
- Tests & Golden Fixtures: Byte-for-byte snapshots ensuring regression-free generation.
- Security Patterns: Principle of least privilege and strict credential indirection.
- Recovery Procedures: Automated snapshot streaming and verified restore drills.
- Architectural Examples & Evidence: Complete transcripts of autonomous multi-node deployments.
Together, these form an agent-readable corpus of executable operational knowledge. That creates a reinforcing loop:
- An agent reads a software manual.
- It builds and verifies a Package Skill.
- The Package Skill adds reusable components and examples.
- Future agents inspect and reuse those components.
- The next Package Skill requires less exploration and invention.
- The workspace becomes more valuable with every successful deployment.
This is the source of the proposed compounding advantage. Traditional reuse still depends heavily on people knowing that a component exists, understanding its assumptions, and integrating it correctly. An agent can search a much larger body of examples, compare their structures, and adapt the most relevant patterns during execution.
Documentation becomes an agent interface
This transition also changes the role of software documentation.
Most deployment manuals are written for human operators. They often rely on implicit knowledge, mix development and production instructions, omit failure modes, and leave persistence or security decisions to the reader.
That ambiguity becomes expensive when an agent is the installer. Agent-ready documentation needs to state:
- Supported production topologies
- Exact dependencies
- Stable versions and checksums
- Required ports and trust boundaries
- Persistence guarantees
- Health and readiness semantics
- Backup and restoration procedures
- Upgrade and rollback paths
- Failure behavior
- Executable acceptance checks
In this model, documentation is no longer supplementary prose. It becomes an operational interface.
A good deployment manual allows an agent to transform intent into a correct deployment with minimal interpretation. A poor manual increases tool calls, tokens, retries, defects, and human intervention. Documentation quality therefore becomes measurable through the quality of the infrastructure agents produce from it.
Benchmarking the hypothesis
I recently used isolated agents to create Package Skills for Restate, Temporal, and DBOS.
Each agent received comparable requirements: deploy to one DigitalOcean machine, configure DNS and TLS, implement a durable workflow, test retries and duplicate IDs, survive a complete reboot, and document operations and recovery.
All three agents produced working deployments. Their efficiency and quality differed, partly because the software architectures differed and partly because the available documentation led them through different implementation paths.
That experiment measures the current quality of agent-produced artifacts. A larger longitudinal experiment could test the acceleration hypothesis itself. Useful measurements would include:
- Delivery time for each new Package Skill
- Input and output tokens
- Agent cost
- Tool calls and retries
- Human interventions
- Reused functions and workflows
- First-attempt deployment success
- Independent quality scores
- Upgrade effort
- Defects propagated from reused components
If the hypothesis is correct, later Package Skills should become cheaper and faster to create while maintaining—or improving—quality.
Compounding reuse can also compound mistakes
The same mechanism that accelerates good patterns can propagate bad ones. An insecure firewall rule, unreliable backup process, mutable dependency, or flawed validation convention may be copied into many future packages.
Agentic DevOps therefore requires strong controls:
- Immutable dependency pins
- Explicit authorization boundaries
- Independent evaluation
- Reproducible builds
- Destructive-operation safeguards (
compute-prevent-destroy) - Golden and acceptance tests
- Security checks
- Regular recovery drills
The objective is not unrestricted autonomy. It is autonomous execution within testable and enforceable boundaries.
From automation to accumulated capability
Traditional DevOps automates known procedures.
Agentic DevOps can discover the procedure required to reach an outcome, compose it from existing capabilities, execute it, diagnose failures, repair the implementation, and verify the result.
Most importantly, the completed work becomes input for the next agent. That leads to the central hypothesis:
Agentic DevOps has a compounding advantage. Every successful deployment produces reusable code, workflows, tests, and examples that reduce the reasoning and implementation required for the next deployment. As this operational corpus grows, infrastructure delivery can accelerate faster than traditional human-centered DevOps.
The future of deployment may therefore depend on two related assets: software designed to be operated by agents and documentation designed to be executed by them.