Adage #
Configuration-driven AWS infrastructure evolving into an agent-ready engineering control plane.
Adage separates desired infrastructure state from reusable Terraform implementation and runtime metadata. Built around explicit configuration, composable components, dynamic dependency resolution, and controlled deployment, it gives engineering agents a system they can inspect, develop, test, and plan—while humans retain authority over consequential AWS execution.
Read the guide · Explore components · Source and evidence
Cloud architecture came first #
Adage was not originally designed for AI agents. It was designed to make cloud infrastructure explicit, declarative, decoupled, reusable, and understandable without tribal knowledge. Those same properties turned out to be what autonomous engineering agents need to reason safely about infrastructure. The agent fit was emergent.
The May 2025 documentation records the original architecture. Design principles explain why it still matters.
Intent, implementation, and runtime #
| Part | Role |
|---|---|
| Adage | Infrastructure control model: intent, reusable implementation, discovery, environments, and controlled deployment. |
| aws-config | Desired state: environment bindings and component instances expected or allowed to exist. |
| aws-iac | Reusable Terraform/Terragrunt components that consume configuration and publish runtime metadata. |
| SSM Parameter Store | Bridge between published configuration, infrastructure deployment, and runtime dependency discovery. |
| aws-lambda | Application functions and runtime integration where applicable. |
| Karma | Real workload and proving ground for Adage. |
| Agent business solution template | General methodology: objective → specification → agent work → deterministic verification → evidence → human release decision. |
Controlled agent engineering #
Agents can inspect repositories and AWS read-only, develop components, modify code/configuration, run checks, generate plans, analyze cost and drift, and prepare evidence and pull requests.
Agents get broad authority in the reasoning and verification space, while humans retain authority over consequential execution.
Production apply, destroy, data deletion, sensitive IAM/security changes, and irreversible operations require explicit human authorization. So do SSM configuration publishing and environment rebinding. Configuration existence does not prove approval; IAM and execution controls must enforce the boundary. Architecture and authority describes the complete loop.
Karma makes the objective measurable #
The first cost experiment compares desired state vs. actual AWS state vs. actual cost.
| Deployment | Exact expected steady-state target |
|---|---|
| strall.com | $0.51/month |
| usekarma.dev | $0.61/month |
| Combined | $1.12/month |
These are owner-specified targets, not verified current bills or guaranteed AWS pricing. Billing scope, usage assumptions, and attribution must be established by evidence.
Explain every cent of AWS spend above the expected $1.12/month steady-state target, identify its infrastructure cause, map it back to desired state/IaC where possible, and produce a safe remediation plan without performing destructive changes.
Cost proof and acceptance criteria defines how the experiment will be measured.
What is established—and what is being proven #
| Status | Evidence |
|---|---|
| Established architecture | Configuration-driven components, SSM discovery, environment bindings, and deployment documentation. These do not certify every component. |
| Implemented, under review | Agent safeguards, planning, verification gates, and evidence workflows in aws-iac PR #1 and aws-config PR #1. They are not yet default-branch capabilities. |
| Still being validated | Complete account/region coverage, resource-level billing attribution, target assumptions, and safe remediation. No complete public end-to-end cost proof is claimed here. |
| Future direction | Repeatable reconciliation, broader component verification, and observed savings after separately authorized changes. |
Get started #
Follow the setup guide, then the serverless site or serverless API quickstart. The local guide covers accounts, configuration, components, and the agent-first evolution.