How pvot Works
pvot's usefulness comes from grounding: it always reasons against the real schema, the real code, and the real, live state of your infrastructure. This page explains the three layers that make that possible — the agent squad, the tool layer, and the agent-native state ledger that is Infrastream's core moat.
1. A squad of specialized agents
pvot is a multi-agent system built on Google's Agent Development Kit (ADK) and deployed on Vertex AI Agent Engine. Rather than one monolithic prompt, a coordinator routes each request to the specialist best suited to it — much like a real platform team:
- a business analyst that turns a fuzzy request into concrete requirements,
- software and enterprise architects that shape the solution and keep it consistent with existing patterns,
- platform / devops engineers that produce the actual manifests,
- a QA / evaluator persona that checks the output before it is proposed.
These are backed by focused sub-agents — a portal assistant, a manifests author, a github integrator, a monitoring analyst, and a knowledge base — that each own a slice of the workflow.
2. The tool layer: how pvot stays grounded
pvot reaches the outside world through a set of Model Context Protocol (MCP) tools, not by guessing:
| Grounding source | What it provides |
|---|---|
| infrastream-mcp | The live infrastructure state and dependency graph from the Spanner ledger. pvot queries state through this toolset — it does not hold a private, stale copy. |
| code-graph-mcp | A semantic graph of your source code, so suggestions line up with how services are actually built. |
| Knowledge base | The manifest schema and this documentation set (the Manifest Reference and Samples), so generated manifests are valid and idiomatic. |
| Google Cloud signals | Live metrics, traces, and logs, used for diagnosis and audits. |
3. The moat: an agent-native state ledger
Most "AI for infra" tools sit on top of raw cloud APIs and try to reconstruct what exists. pvot starts from a decisive advantage: Infrastream's state ledger is designed for the agent.
Every resource Infrastream manages is recorded in Google Cloud Spanner with fields that exist specifically so an agent can reason about it:
- Semantic embeddings of each resource's configuration and description, so pvot can find "the databases like this one" or "everything related to payments" by meaning, not string match.
- Search context and links captured per resource, giving pvot ready-made, machine-readable context and the relationships between resources.
- Root-cause and error attribution recorded on the state itself, so failures carry structured "why" information rather than just a stack trace.
- Topology markers (hub nodes and their members) that describe how resources cluster.
The result is a real-time, semantically indexed, dependency-aware view of your entire live estate — something a generic assistant simply cannot assemble from cloud APIs after the fact.
The state is a graph — so pvot can navigate and orchestrate
Infrastream's state is a directed dependency graph — the very same graph the engine executes. Because pvot reads that graph, it can:
- traverse dependencies in both directions — what does this database feed, and what would a change break (its blast radius);
- respect ordering — understand that a project's APIs and IAM must exist before the services that use them;
- orchestrate multi-resource changes in the correct sequence, rather than answering one isolated question at a time.
Diagnose and debug across desired and actual state
Because pvot holds both the desired state (your manifests) and the actual state (what the engine provisioned), plus the run history, it can close the loop from provision to operate. Ask it why something failed and it correlates the engine's run events and the state graph with live Google Cloud metrics, traces, and logs to pinpoint the offending IAM binding, quota, or missing dependency — and reason about the safe fix before proposing it.
Built to respect your data boundaries
pvot earns this reach by staying in its lane. It reasons over infrastructure state and metadata that were purpose-built for it, and operates within your organization's permission and tenancy boundaries. It does not need — and does not reach into — your applications' private data to do its job. The trust model is the same one the whole platform runs on: least privilege, deny-by-default, and every consequential change routed through a reviewed pull request.