New Blog Post! The Citizen Developer
Read 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.
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
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.