Skip to main content

pvot — the Infrastream Agent

pvot is Pvotal's AI platform engineer, embedded directly in the Infrastream control plane. It lets anyone — a developer, a product manager, a data scientist — express infrastructure intent in plain language and get back schema-valid manifests, a live diagnosis, or an architectural plan, grounded in the real state of your estate.

pvot is not a generic chatbot bolted onto cloud APIs. It is built on Google's Agent Development Kit (ADK), deployed on Vertex AI Agent Engine, and wired into Infrastream's own state ledger, dependency graph, and manifest schema. That grounding is what makes it trustworthy enough to put in front of real infrastructure.

pvot is the AI-native layer of Infrastream's Agentic Development Platform — the point where an AI agent becomes a first-class user of the platform, governed by the same manifests, PR review, and engine as every other resource.

Go deeper on governance and identity
Current status & limitations

The agentic layer is early and under active development. The agent runtime is ADK-only today, agentic deployments should be re-tested per environment before production use, and governance is still maturing (MCP governance and broader policy controls are in progress). Treat the examples here as reference patterns rather than turnkey guarantees.

Vibe-ops, with the human always in the loop​

Infrastream turns operations into vibe-ops: you describe the outcome you want, and pvot does the mechanical work of translating it into correct, compliant configuration.

"Give the AstraPay project a highly-available Postgres database and let the payments-api use it."

pvot interprets that, checks the current topology, drafts the required manifests (reusing the platform's best-practice templates), and opens a pull request.

Crucially, pvot never mutates infrastructure directly. Every change flows through the same GitOps pipeline a human would use:

  1. pvot proposes manifests as a pull request.
  2. CODEOWNERS review and ReleaseTrack approval gates apply — a human must approve.
  3. Only after merge does the Infrastream engine provision anything.

This is the "vibe" of natural-language ops with the guardrails of GitOps: every AI-authored change is reviewable, auditable, and reversible, and nothing reaches production without human sign-off.

Because the platform is deny-by-default, even an experimental, "vibe-coded" application pvot helps scaffold is fully contained — it can't reach a database, secret, or external endpoint unless a reviewed manifest grants it. (See the Security Framework.)

What you can ask pvot to do​

  • Author configuration — "Write a DeploymentConfig for billing-service that scales 2→10 and injects DB_PASSWORD from Secret Manager." pvot produces a valid manifest and opens the PR.
  • Diagnose and debug — "Why did the AstraPay database fail to provision?" pvot correlates the engine's run events and the live state graph with Google Cloud metrics, traces, and logs to pinpoint the failing IAM binding, quota, or dependency.
  • Reason about the estate — "Which applications depend on the payments database, and what breaks if I resize it?" pvot walks the dependency graph to explain blast radius before you act.
  • Audit and plan — "Are any VMs in staging attached to an insecure subnet?" or "Draft the manifests to stand up a new trading platform."

Why pvot is different​

The next pages go deep, but the short version is a single idea: Infrastream's state is designed for the agent.

  • How pvot works — the multi-agent squad, its MCP toolset, and the agent-native state ledger + dependency graph that give pvot a real-time, semantically indexed view of your infrastructure no generic assistant can match.
  • Using pvot in the portal — day-to-day workflows for writing manifests, troubleshooting, and running audits.