This is a short builder diary from my startup journey: a bunch of customer conversations about "architecture context" (and the usual incident-review pain) turned into an experiment I couldn't stop thinking about.
Skip ahead?
The cloud isn't a list of resources. It's a web of relationships.
Kubernetes isn't "a cluster." It's code → image → workload → pod → node → exposure → identity.
Once those relationships live in a graph, your assistants/agents can stop guessing and start answering.
The model (one sentence)
Ingest truth into a graph, then expose MCP tools that return answers + evidence.
Layer 1: baseline graph (Cartography + simple queries)
This is the "out of the box" win: Cartography syncs cloud resources into Neo4j so you can query relationships, not inventories.
What the baseline graph gives you:
MCP tools you can build on Layer 1:
Layer 2: heavy lifting (Kubernetes + "which code runs where?")
Layer 1 answers "what's exposed?" and "what can assume what?" for the cloud graph.
Layer 2 answers the question teams actually live in: Where is this code running, what version is live, and what can it reach?
How I built this
I created two lightweight services to keep the graph fresh:
- •A CI/CD integration that runs on every build — captures commit → image digest → registry links as artifacts flow through the pipeline
- •A cronjob that periodically syncs live cluster state — workloads, pods, services, RBAC bindings, and network policies
Together they keep the "code → runtime" path current without manual effort.
What to ingest (minimal set with maximum payoff):
- •Workloads: Deployments/StatefulSets/DaemonSets/CronJobs, pod templates, labels/annotations
- •Placement: Pods → Nodes → Cluster (and Node → cloud instance if you want)
- •Exposure: Services, Ingress/Gateway, LoadBalancers, ports, hostnames
- •Identity: ServiceAccounts + RBAC bindings (+ cloud identity links like IRSA/workload identity)
- •Network intent: NetworkPolicies (or "none exist")
- •Supply chain: image digests, provenance (CI run → commit), SBOM/CVE summaries
- •Ownership: owner, service, tier, oncall (whatever you can standardize)
The "code → runtime" graph (conceptually):
MCP tools that become possible in Layer 2:
The wow moment: "Where is this code running?"
The moment it clicked
This is the moment it clicked for me that "architecture context" can be queryable.
I asked Claude Code: "Where is this code running?" (and waited for it to hallucinate).
Instead, it walked the graph:
- •repo → CI provenance → ECR repo + image digest
- •image digest → workloads/pods pulling it
- •pods → exact node/host
- •workload → egress/gateway path (how traffic leaves), with evidence you can paste into a ticket
Real-world win
We found a "fixed" service that was still serving traffic from an older pod set in one cluster — and had concrete pod/node evidence to clean it up fast.
Want early access?
I've built a first beta and I'm opening it up to a small group of people for early feedback.
Join the beta
If this resonates with the problems you
'
re facing, I
'
d love to get your input. Reach out at shaylivni@outlook.com or connect on LinkedIn — looking for honest, no-filter feedback on what works, what
'
s confusing, and what you
'
d actually use.