This is where the graph stops being an internal tool and starts changing how the platform gets operated. Point an agent at your infrastructure without a graph and it fills gaps plausibly; give it the graph and it stops generating answers and starts looking them up.

The Context Layer AI Agents Have Been Missing Is Your Infrastructure Graph

The Queryable Platform, part 4 of 4 — a series on building an infrastructure knowledge graph and putting agents on top of it. (Part 1 · Part 2 · Part 3)

We ended part 3 at the top rung of the ladder: automation, and specifically LLM agents as the newest consumer of the platform knowledge graph. This is where the graph stops being an internal tool and starts changing how the platform gets operated.

Here’s the claim, up front: in 2026, the hard part of putting an AI agent on your infrastructure is no longer the AI. Wiring a model to tools is a solved problem. The hard part is giving the agent something trustworthy to reason over — and that’s precisely what you built in parts 2 and 3.

Why agents need the graph

Think about what an agent has to work with when you point it at your infrastructure without a graph. It can grep repos, so it sees YAML — but YAML describes intent, not reality, and it’s scattered across dozens of repos in three different templating dialects. It can call kubectl, so it sees live state — but with no notion of ownership, deployment lineage, or what’s supposed to be there. It has no durable concept of “this service depends on that database” because no single system it can reach contains that fact. So it does what LLMs do with missing information: it fills the gap plausibly. An agent confidently reasoning from plausible-but-wrong infrastructure facts is worse than no agent at all.

Now give the same agent your graph. Every question from parts 1 through 3 — what exists, where it runs, who owns it, what routes expose it, what deploys it, what depends on it, what changed recently — becomes an explicit fact the agent can retrieve, with a URI behind it and a kg:lastSeen timestamp telling it how fresh the fact is. The agent stops generating answers about your platform and starts looking them up, reserving the generative horsepower for what models are actually good at: synthesizing retrieved facts into a plan, a brief, or a diff.

That’s the difference between a toy assistant and a platform-aware operator, and the graph is the entire difference.

The wiring

The plumbing is almost anticlimactic. The lingua franca for agent tools in 2026 is MCP (Model Context Protocol), and an MCP server for platform-kg is an afternoon of work. Mine would expose three tools:

• sparql_query(query) — runs a SELECT/ASK against the GraphDB endpoint and returns rows. This is the workhorse; everything else is convenience.
• describe(uri) — given a node like ex:svc:payment-api, returns every triple it participates in, both directions. Agents reach for this constantly: “tell me everything about X” as one call instead of six queries.
• get_schema() — returns ontologies/kg.ttl so the agent knows what classes and properties exist before it writes a query. Feed it the example queries from examples/sparql/ too; models write much better SPARQL from a few worked examples than from a schema alone.

Two deliberate omissions. There’s no sparql_update — the graph is rebuilt from the source systems by make graph, and agents read it; if an agent could write to the graph you’d lose the one property that makes it trustworthy, which is that it reflects extraction, not opinion. And there’s no tool that touches the actual infrastructure. Whether an agent can act — merge, provision, delete — is a separate authorization decision per agent, made deliberately, with the read-only graph as the floor everyone starts from.

With that server registered, any MCP-capable agent — Claude in your terminal, a bot in your incident tooling, a CI job — can query your platform. Now let’s talk about what to build with it.

Agent #1: The incident triage agent

The scenario: someone types “payment-api is failing in prod” into the incident channel at 2:47 AM.

Today, the on-call engineer surfaces from sleep and begins the ritual: which cluster is that in again? Who owns it? What deployed recently? What does it talk to? Twenty minutes of tab-opening before anyone forms a hypothesis — and all twenty are pure information retrieval.

The triage agent does that retrieval in seconds, because every step is a graph query. It starts with describe(ex:svc:payment-api) and immediately has the namespace, cluster, owning team, Helm release, and container image. It follows kg:exposes to the VirtualServices and their public hosts — is customer traffic actually affected, or is this internal-only? It follows kg:deployedBy to the pipeline and checks the Argo app’s kg:syncStatus and kg:lastSeen — did something ship in the last few hours? It walks kg:dependsOn downstream to the database and Vault mounts, and kg:routesTo upstream to find every service that calls this one and is about to start timing out.

Then it posts a brief to the channel:

payment-api (Deployment, payments/prod-cluster-east, owned by payments-team) is exposed publicly via api.example.com. Argo app synced 43 minutes ago, currently Synced/Degraded. Depends on payments-db (Terraform: aws_db_instance/payments-prod) and Vault mount kv/payments. Three services route to it: checkout, billing-worker, refunds — expect knock-on failures there. Most likely change candidate: the 43-minute-old sync.

Every line of that is a lookup, not a guess. The human still runs the incident — but they start it at the hypothesis stage instead of the archaeology stage, and the agent has already paged the right team because ownership is an edge in the graph, not a wiki page.

Agent #2: The change-impact reviewer

The scenario: a PR touches a Helm values file — an ingress host changes and a Vault path moves.

This agent lives in CI. On every PR to a deployment repo, it maps the changed files back to graph nodes: the repo has a kg:declaredIn edge from its service, the release connects through kg:hasHelmRelease, and from there the whole neighborhood is reachable. It walks outward from what changed and comments on the PR:

This change affects payment-api in prod. The modified ingress host is currently served by 2 VirtualServices (payments-vs, payments-canary-vs). The Vault path being renamed, kv/payments/prod/db, is referenced by this release and nothing else — safe to move once this deploys. Downstream callers: checkout, refunds. Deploying pipeline: deploy-prod (last run 2 days ago).

The reviewer sees the blast radius before merge, computed from the platform as it is right now. And because the SHACL shapes from stage 4 are just data, the same agent evaluates the post-merge state against policy and turns violations into review comments: “this change removes the last kg:ownedBy path for a publicly-routed service — add a CODEOWNERS entry or this will page nobody when it breaks.” A policy violation caught as a review comment costs a fix-up commit; the same violation caught in a postmortem costs a weekend.

Notice how much of this agent is just stage 3 and stage 4 queries with a webhook in front. That’s the pattern of this whole article: the ladder did the work already.

Agent #3: The environment provisioning agent

The scenario: “spin up a customer-specific environment for payment-api.”

This is the request that generic AI tooling handles worst, because the correct answer is nowhere in the model’s training data — it’s in your conventions. What does “an environment” mean in your shop? Some particular constellation of namespace, Argo apps, Helm values, Vault paths, Istio routes, DNS, and Terraform resources that your team settled on two years ago and documented nowhere.

But your graph contains worked examples. The agent queries for the existing environments of payment-api — everything sharing its repo lineage, grouped by namespace — and diffs them: here’s what staging and prod both have (an Argo app from the same repo path, a release of the same chart, a Vault mount scoped to the namespace, a VirtualService bound to the shared gateway), and here’s what varies (hostnames, target revisions, resource scales). That common shape is the de facto template of “an environment,” derived from reality rather than from documentation that nobody wrote. The agent instantiates it for the new customer name and opens a PR — Argo app manifest, values file, Vault path plan, Terraform stanza.

Two guardrails, and they’re non-negotiable. The agent proposes; the PR review is where humans stay in the loop, and everything flows through GitOps so the change is auditable and revertible. And after the change merges and make graph runs, the agent verifies its own work with the same queries — does the new environment now match the shape of its siblings? Generation is cheap; verification against the graph is what makes this trustworthy.

Agent #4: The drift janitor

The least flashy and, I suspect, the best return on investment of the four.

This agent runs after every graph refresh — so, on whatever cadence you cron make graph — and executes the stage 4 orphan queries: workloads in the cluster with no Argo application behind them, VirtualServices routing to services with no kg:lastSeen, Terraform resources no service consumes, Vault paths nothing references, prod services with no kg:ownedBy edge. For each finding it does the small amount of reasoning that turns a query row into an actionable ticket: who owned the thing most recently (walk the edges that do exist), how long has it been orphaned (compare kg:lastSeen across refreshes), does it cost money (is there a Terraform resource attached?). Then it files the ticket, assigns it to the nearest owner, and includes the exact triples that triggered the finding, so the human can verify the claim in one query rather than taking a bot’s word for it.

It never pages anyone. It never touches anything. It just grinds away at entropy on a schedule — and entropy is the thing platform teams never get around to, because it’s never anyone’s incident. Six months of a drift janitor quietly filing five tickets a week is a cleaner platform than any big-bang cleanup project I’ve ever seen attempted.

The pattern across all four

Look back at what each agent actually consists of: a handful of SPARQL queries you already understood by the end of part 3, an MCP server that’s mostly one tool, a system prompt, and — for anything that acts — a human approval gate. The intelligence was already in the model. The queries were already implied by the ladder. The missing piece, the thing that made all four of these impossible last year and an afternoon project now, is a queryable, refreshed, trustworthy account of your platform.

So my advice, same as it was in part 3 but now you can see why: don’t start by building the agent platform. Build the graph — stages 1 through 4, the inventory, the topology, the impact queries, the policy shapes. That’s the whole hard part, and it pays for itself in safer deploys and faster incidents before a single agent exists. Then stand up the read-only MCP server and start with the janitor: lowest risk, immediate value, and it exercises every part of the stack. The triage agent comes next, then the reviewer, and by the time you’re ready for the provisioner you’ll trust the graph enough to let an agent draft PRs against it.

The whole climb starts with make ttl and a few thousand honest little triples.

Enjoy!