Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
Your infrastructure context is buried in old docs, old PRs, and CI logs.
Answering a real question about infrastructure today means rebuilding context by hand: the design doc that went stale two quarters ago, the PR thread where the decision actually happened, a dig through GitHub Actions logs to figure out what deployed and when. Every question starts from zero, for you and for any agent you point at the problem. The Context Engine holds that context as data and lets you dial in as many dimensions as the question needs: environment, team, status, bundle, even individual configuration parameters. This query finds every provisioned Postgres the payments team runs in prod that is still on engine 14.
The graph, the API, and policy on the graph itself.
01
The graph
Every bundle deploys into a graph. Nodes are running resources with their actual configuration. Edges are typed connections defined by artifact definitions, which act as contracts: the link between a database and the app that uses it carries a known schema. Environment, ownership, lineage, cost, deployment history, and audit events all live in the model. Imported inventories drift; this graph is written by the deployments themselves, updated the moment anything ships.
02
The API
A public GraphQL API exposes the graph. Anything that needs infrastructure context reads from the same place: the CLI, the Backstage plugin, CI, an MCP server feeding Claude Code, or your own agents. Writes go through the same governed interface, so acting on infrastructure and knowing about infrastructure use one system. Anything a human can do through Massdriver, an agent can do through the API, with the same guardrails.
03
ABAC on attributes
Policy is attached to the graph itself. Resources carry structural attributes like environment, team scope, and blast_radius, and grants are evaluated against those attributes. Access rules apply automatically to infrastructure that doesn't exist yet, so permissions scale with the org instead of rotting into sprawl. The access decision becomes “can this actor modify a production resource with this blast radius,” answered against the graph.
The agentic harness for infrastructure.
Agents don't operate on raw cloud APIs. They propose changes through typed contracts and IaC modules. Inputs are validated up front, policies are enforced automatically, and execution runs through deterministic, ephemeral pipelines. Massdriver was built to keep humans from breaking prod, and now it keeps agents from doing it too.
01
Agents propose
Agents generate IaC wrapped in Massdriver bundles with schema-validated inputs, so every proposal is a valid configuration of a reusable, production-ready module.
02
Humans review
The bundle is the contract: actual code your team can read, diff, and edit before anything touches production.
03
The system executes
Once approved, changes run through deterministic, ephemeral pipelines. Same inputs, same outputs, every time, with a full audit trail of every iteration.
Environment boundaries
Agents work in non-prod sandboxes, away from the resources that matter.
Schema validation
JSON Schema rejects invalid configurations before anything runs.
Policy enforcement
SOC2, HIPAA, and CIS benchmarks are checked automatically on every deployment.
Ephemeral pipelines
Each run gets a clean execution environment, with no CI/CD sprawl to maintain.
Audit trail
Every iteration is tracked, so you can see exactly what an agent did.
Deletion protection
Critical resources can't be destroyed by accident.
Agents rebuild context from scratch, every session.
Give an agent a CLI and an MCP server and it can act on your cloud. It forgets everything between sessions. Finding one VPC means listing every region. Mapping one service's dependencies means paging through API responses, every session, at token prices. And nobody wants to hand an agent broad cloud credentials just so it can look around. So teams fence agents out of infrastructure, or let them work from stale text and hope review catches the damage.
Agent on a repo
Agent on the Context Engine
Guesses topology from tfvars and module names
Queries what's deployed and how it's connected
Burns tokens crawling files and cloud APIs
Answers in one structured query
Needs broad cloud credentials to act
Acts through governed interfaces under ABAC
Output verified by humans reading every diff
Output pre-verified by the constraints of the system: schema validation, policy checks (SOC2, HIPAA, CIS), blast radius containment
See the Context Engine and its guardrails at work.
A walkthrough of how Massdriver sits between AI agents and your cloud: the Context Engine (a live, queryable model of your bundles, dependency graphs, IAM relationships, and cost context) informs what agents do, and the guardrails keep them to what your platform team allows.
Everything your agents need to know, in one queryable place.
What's deployed, how it's connected, who owns it, what it costs, and what's permitted. That grounding is what makes generated infrastructure trustworthy.
The same model that powers self-service.
The Context Engine is the structured model behind Massdriver's catalog, and agents are a new consumer of it. Developers self-serve infrastructure without reading Terraform. DevOps teams answer impact questions by querying the graph instead of grepping repos. Governance becomes data the system enforces. Self-host it and all of that context stays inside your network.
Ground your agents in what's real.
The Context Engine feeds Architect, the develop workflow, and anything else you point at the API.