Infrastructure Automation That Behaves Like Reality: System Initiative’s “Digital Twin” Approach to DevOps (and Agents)
What if the reason infrastructure automation feels brittle isn’t because teams are doing it wrong, but because the underlying assumptions are wrong?
In this Commit & Push episode, host Damien Filiatrault talks with Brit Myers, VP of Engineering at System Initiative, about why the Terraform/GitOps era hit a ceiling, and what an “AI-native” platform looks like when you rebuild infrastructure automation around collaboration, simulations, and a true one-to-one model of the real world.
Rethinking the Old DevOps Contract
System Initiative positions itself as an AI-native infrastructure automation platform: if Terraform or GitOps pipelines can do it, System Initiative can too, but with a different foundation.
Brit describes the motivation as dissatisfaction with where the industry landed after 10–15 years of DevOps tooling. The promise was always smoother automation, safer change, faster feedback. The reality for many teams is still “merge and pray.”
System Initiative’s bet is that you don’t fix that with more pipelines or more glue, you fix it by changing the core model.
The Two Assumptions They Want to Break
1) “Infrastructure automation must be static declarative files”
Terraform assumes infrastructure automation starts with declarative configuration: authored, versioned, and processed in a largely one-way flow.
Brit argues that’s only clean when everything behaves like “cattle” (disposable, stateless). But real infrastructure includes plenty of “pets” too, systems that need care, constraints, and flexibility.
In practice, teams often need to:
- handle non-stateless applications gracefully
- modernize incrementally (not rebuild from scratch)
- respond to incidents immediately, even if the “right” IaC change would take too long
2) “State is managed somewhere else (and it’s scary)”
Terraform’s state file is powerful, and famously risky. Anyone who has had to manually edit state knows how quickly things can go sideways.
System Initiative’s approach keeps declaration, observed state, and transitions tightly controlled inside the same model. The goal is not just to describe what you want, but to understand:
- what exists right now
- how reality changed (including changes made outside automation)
- how to safely move from A → B (or B → A)
That last part matters because one of the most common “real life” infrastructure events is: someone logs into AWS/GCP console to stop a problem fast. Terraform assumes changes come through Terraform. Reality doesn’t.
System Initiative wants teams to be able to do what they must, when they must, without carrying hidden penalties later.
“Digital Twin” Means More Than a Diagram
Damien pushes on the “one-to-one model” idea: isn’t this just what Terraform already does?
Brit’s answer is: Terraform models across repos/files/modules, and the actual behaviors (how transitions happen) often live elsewhere, with long feedback loops and limited control. In System Initiative, state transitions are first-class and always “in the room.”
Everything is modeled as functions, so behavior is adjustable directly inside the product, instead of being trapped behind a provider repository, PR process, and adoption delay.
Functions Everywhere: Infrastructure, Policy, and Guardrails
System Initiative uses TypeScript functions to define behavior. Brit describes a model where:
- relationships (like region) propagate reactively
- downstream dependencies update automatically
- org policy can run as a reactive function too
- changes that violate cost/security/compliance can be flagged immediately
A concrete example: someone selects a very expensive instance size. Instead of finding out later (or blocking merges with blunt rules), the system can run policy feedback live as part of the modeling workflow.
The idea: faster feedback, more confidence, fewer “surprises after apply.”
Change Sets: Safe Sandboxes for Humans and AI Agents
The most “2026” part of the conversation is how System Initiative thinks about AI.
Brit is blunt: most infrastructure engineers are (rightfully) not eager to give an agent direct access to production. The blast radius is huge, and the cost of being wrong is real.
System Initiative’s answer is change sets, simulated environments representing potential changes to the real world.
In a change set, you can collaborate:
- with teammates
- with an AI agent
- with automation checks
…and only apply to the real environment when a human (or your configured checks) says it’s safe.
This is also where System Initiative pushes past Terraform’s “plan” concept. Their simulation doesn’t just show diffs, it shows:
- how values propagate through the model
- what operations would be required (create vs update vs delete+create)
- what checks/scans/policy functions trigger
- what the real-world impact looks like before you commit
Agents Aren’t Built In—They Plug In Through an API
Damien asks if this is a built-in agent that takes English instructions.
Not exactly.
Brit says the agent can be external (Claude, etc.) and interacts with System Initiative via API (think MCP-style tool access). The critical advantage is the one-to-one model: agents already “understand” AWS from their training data, and System Initiative presents AWS in a faithful, high-fidelity way inside change sets.
One standout example Brit shares:
- a user uploads an AWS architecture diagram image
- the agent uses what it knows about AWS + the System Initiative model
- it iterates (not perfect one-shot), self-corrects, gathers more context
- and produces in ~15–20 minutes work that could take hours or days manually
Another example: “discover everything I have.”
The agent starts from networking (VPCs), pulls those in, then subnets, and so on—building the digital twin progressively while you watch it happen in a collaborative web UI.
Discovery Today, Expansion Tomorrow
Right now, System Initiative’s coverage is AWS (implementation isn’t AWS-specific, but coverage is). Brit also mentions active work toward:
- GCP
- Azure
- DigitalOcean
- and even providers like Hetzner
A key detail: they generate coverage from provider specs via an internal pipeline that runs daily, so expanding to new providers becomes an engineering scaling problem—not hand-building endless schema.
Pricing: Pay for Managed Resources, Hour by Hour
System Initiative uses usage-based billing: resources under management per hour. Brit mentions a rough number around ~0.7 cents per managed resource per hour (with the caveat that it’s hard to map neatly to “% of cloud spend” because “value of managing” doesn’t always correlate with raw spend).
The Real Message: Find Where This Breaks
Brit closes with an interesting challenge: they haven’t yet found an AI+infra use case that truly flops within this model—and they want people to bring them the hardest cases.
If Terraform-era DevOps optimized for pipelines and files, System Initiative is optimizing for:
- faithful state and reality modeling
- simulation-first change
- fast feedback loops
- collaboration with humans and agents
- safer autonomy through guardrails
Bottom line: the next leap in infrastructure automation might not be a better “apply.” It might be building systems that behave like reality—so humans and agents can iterate safely until the change is obviously correct.