Full-Scale Agent Use Cases

These five reference use cases demonstrate how Infrastream's manifest governance aims to turn AI agents from risky autonomous systems into auditable, governed participants in the infrastructure lifecycle.

Each use case follows the factory model defined in the New SDLC with Vibe Coding whitepaper (Osmani, Saboo & Kartakis, May 2026): the human designs the system, the agent does the work, and the governance harness checks correctness at every stage.

Reference patterns, not turnkey guarantees

The agentic layer is early and under active development: the runtime is ADK-only, deployments should be re-tested per environment, and governance (especially MCP) is still maturing. Read these as the intended model and current direction — validate before relying on them in production.

Key Principle

In all five use cases, agents never modify infrastructure directly. They generate manifests that go through the standard Git PR → human review → engine execution pipeline. The governance is structural, not procedural.

buildDefinition references aren't shown in full

Every Agent and McpConfig example below sets buildDefinition to the name of a BuildDefinition manifest, but doesn't show that manifest. For Agent, this must be a BuildDefinition with type: AGENT — see Agentic Governance for the current schema requirements and known limitations (only agent.registry is consumed today; type: AGENT has no CI workflow builder yet) and TradeStream's Native Agentic section for a full worked example.

Use Case 1: SOC2 Compliance Auditor Agent

Business Problem

Manual compliance audits take weeks, cost tens of thousands in engineering time, and miss configuration drift between audit cycles. Organizations need continuous compliance monitoring that catches violations in real-time — not quarterly.

Agent Architecture

Manifests

# Agent Definition
apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: compliance-auditor
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "SOC2 compliance auditor — continuous infrastructure audit"
  target: AGENT_ENGINE
  project: platform-core
  buildDefinition: compliance-agentic-build
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_PLATFORM_CORE_CONNECTION_STRING
      schema: platform-core
      name: main
      privileges: [SELECT]  # Read-only — cannot modify state
    secrets:
      audit-api-key:
        envVar: AUDIT_API_KEY
---
# MCP Server for Compliance Tools
apiVersion: lowops.manifests.v1
kind: McpConfig
metadata:
  name: compliance-mcp-server
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "MCP server exposing compliance-check tools"
  target: CLOUD_RUN
  project: platform-core
  buildDefinition: compliance-agentic-mcp-build
---
# MCP Server Production Deployment
apiVersion: lowops.manifests.v1
kind: McpDeploymentConfig
metadata:
  name: compliance-mcp-server
  project: platform-core
  environment: production
spec:
  version: "0.3.2"
---
# Production Deployment
apiVersion: lowops.manifests.v1
kind: AgentDeploymentConfig
metadata:
  name: compliance-auditor
  project: platform-core
  environment: production
spec:
  version: "0.10.11"
---
# Integration Deployment
apiVersion: lowops.manifests.v1
kind: AgentDeploymentConfig
metadata:
  name: compliance-auditor
  project: platform-core
  environment: integration
spec:
  version: "0.11.0-rc.1"
---
# Development Deployment
apiVersion: lowops.manifests.v1
kind: AgentDeploymentConfig
metadata:
  name: compliance-auditor
  project: platform-core
  environment: development
spec:
  version: "0.4.1"

Security Boundaries

Database: SELECT only — the agent reads state but cannot modify it
No PubSub: Compliance auditor doesn't publish or subscribe to events
Single secret: Only the audit API key is accessible
Output: All remediation is via manifest PRs — never direct infrastructure modification

How the Governance Harness Enables It

The compliance auditor embodies the whitepaper's central principle: "Structure scales, vibes don't." Every compliance rule is encoded in the agent's logic, every infrastructure constraint is enforced by the manifest schema, and every remediation action goes through the standard PR review pipeline. The agent cannot circumvent governance because the governance is the medium through which it operates.

Use Case 2: Cost Optimization Agent

Business Problem

Cloud costs grow 30%+ year-over-year without active optimization. Engineering teams lack the time and tooling to continuously right-size resources across all projects. Cost optimization is typically reactive (quarterly reviews) rather than proactive (continuous analysis).

Agent Architecture

Manifests

apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: cost-optimizer
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "Analyzes resource utilization and recommends right-sizing"
  target: AGENT_ENGINE
  project: platform-core
  buildDefinition: cost-optimization-agentic-build
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_PLATFORM_CORE_CONNECTION_STRING
      schema: platform-core
      name: main
      privileges: [SELECT]
    secrets:
      billing-api-key:
        envVar: BILLING_API_KEY

Use Case 3: Incident Response Agent

Business Problem

Mean time to resolution (MTTR) is high because on-call engineers must context-switch, investigate unfamiliar systems, correlate logs across services, and diagnose root causes — all under pressure at 3 AM.

Agent Architecture

Manifests

apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: incident-responder
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "Auto-diagnoses production incidents, proposes remediation"
  target: AGENT_ENGINE
  project: platform-core
  buildDefinition: incident-response-agentic-build
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_PLATFORM_CORE_CONNECTION_STRING
      schema: platform-core
      name: main
      privileges: [SELECT]
    secrets:
      pagerduty-api-key:
        envVar: PAGERDUTY_API_KEY
    pubsub:
      subscribeTo:
        - production-alerts

Security Boundaries

PubSub subscribe-only: Agent receives alerts but cannot publish to production topics
Database read-only: Queries state but cannot modify the ledger
Single secret: Only PagerDuty API key for enriched alert posting
Cannot deploy fixes: Remediation manifests go through PR review — on-call engineer must explicitly approve

Use Case 4: Developer Onboarding Agent

Business Problem

New developer onboarding takes days to weeks: provisioning accounts, creating repositories, setting up environments, granting access, configuring databases, wiring up CI/CD. Most of this is repetitive boilerplate that follows established patterns.

Agent Architecture

Manifests

apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: onboarding-assistant
  organization: pvotal-tech
  organizational-unit: platform-engineering
  environment: production
  project: platform-core
spec:
  description: "Provisions complete dev environments from natural language"
  target: AGENT_ENGINE
  project: platform-core
  buildDefinition: onboarding-agentic-build
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_PLATFORM_CORE_CONNECTION_STRING
      schema: platform-core
      name: main
      privileges: [SELECT, INSERT]  # Can create draft records for dev envs
    pubsub:
      publishTo:
        - installation-requests

Example: Generated Manifests from a Single Request

When a developer asks: "Set up a new microservice called payment-gateway with Postgres and Redis", the agent generates:

# Generated by onboarding-assistant agent
# PR: feat/payment-gateway-service-setup
---
apiVersion: lowops.manifests.v1
kind: Application
metadata:
  name: payment-gateway
  organization: acme-corp
  organizational-unit: fintech
  environment: development
  project: fintech-core
spec:
  description: "Payment gateway microservice"
  target: CLOUD_RUN
  project: fintech-core
  buildDefinition: payment-gateway-build
---
apiVersion: lowops.manifests.v1
kind: Database
metadata:
  name: payment-gateway-db
  organization: acme-corp
  organizational-unit: fintech
  environment: development
  project: fintech-core
spec:
  description: "Postgres database for payment-gateway"
  alloydb:
    cpuCount: 2
    clusterSize: 2   # primary + 1 read replica
    configuration:
      maxConnections: 1000
    backupConfig:
      quantityBasedRetention: 30
---
apiVersion: lowops.manifests.v1
kind: Redis
metadata:
  name: payment-gateway-cache
  organization: acme-corp
  organizational-unit: fintech
  environment: development
  project: fintech-core
spec:
  enabled: true
  memorySizeGb: 2
---
apiVersion: lowops.manifests.v1
kind: DeploymentConfig
metadata:
  name: payment-gateway
  organization: acme-corp
  organizational-unit: fintech
  environment: development
  project: fintech-core
spec:
  version: "0.1.0"
  container:
    env:
      - name: DB_HOST
        value: payment-gateway-db.fintech-core.development.fintech.acme-corp.internal
      - name: REDIS_HOST
        value: memory-payment-gateway-cache.fintech-core.development.fintech.acme-corp.internal
  scaling:
    min: 1

Governance Controls

Dev environments: Auto-merge after schema validation passes — developers don't wait for manual approval on dev
Staging/production: Full human review required — tech lead must approve manifest set
Template enforcement: Agent generates from organizational templates, ensuring consistency with established patterns
No ad-hoc infrastructure: Even "quick" dev setups go through the manifest pipeline

Use Case 5: Security Posture Management Agent

Business Problem

Security policies are documented in wikis and Confluence pages but not systematically enforced. Configuration drift accumulates silently: egress rules get relaxed for debugging and never tightened, IAM bindings get added for one-off tasks and never removed, mesh strategies diverge between environments.

Agent Architecture

Manifests

apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: security-posture-manager
  organization: pvotal-tech
  organizational-unit: security
  environment: production
  project: security-core
spec:
  description: "Enforces organizational security policies across all projects"
  target: AGENT_ENGINE
  project: security-core
  buildDefinition: security-posture-agentic-build
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_SECURITY_CORE_CONNECTION_STRING
      schema: security-core
      name: main
      privileges: [SELECT]
    pubsub:
      publishTo:
        - security-findings

Generated Remediation Manifests

When the agent detects configuration drift, it generates corrective manifests:

# Generated by security-posture-manager agent
# Detected: egress rule relaxed beyond baseline
apiVersion: lowops.manifests.v1
kind: Project
metadata:
  name: analytics-platform
spec:
  allowedEgress:
    - "storage.googleapis.com"
    - "bigquery.googleapis.com"
    # Removed: "0.0.0.0/0" — violated security baseline

Remediation manifests go through the standard PR review pipeline — the security team reviews and approves before the engine applies the fix.

Pattern: Delegated User Authorization (3-Legged OAuth)

Business Problem

The Developer Onboarding Agent (Use Case 4) generates manifests — but some agent actions aren't manifest changes at all. Opening a GitHub pull request, commenting on an issue, or reading a private repository should be attributable to the specific developer who asked for it, not a shared bot account. A shared credential means every PR the agent opens looks identical in GitHub's audit log regardless of who actually requested it — and it means the agent's GitHub token is scoped to whatever the broadest user of the agent needs, for every user.

How It Works

Instead of holding a standing GitHub credential, the agent requests one at the moment it's needed, scoped to that single action, via Google's Agent Development Kit (ADK) credential-request flow.

Why It Matters

Attribution is real, not cosmetic. The PR is opened as the developer, so code review, CODEOWNERS, and audit history all reflect the actual requester.
No standing over-privileged token. The agent doesn't hold a GitHub App installation token scoped to every repo it might ever need — it asks, per action, for exactly what this request requires.
Consent is revocable and visible. The developer sees exactly what they're approving, when they're approving it — not a one-time blanket authorization buried in a signup flow.

This pattern generalizes beyond GitHub to any tool call where the correct identity is "the human who asked," not "the agent." See Authentication, Managed by Default for how this fits alongside the agent's own managed identity.

From Vibe Coding to Governed Agents

The whitepaper's conclusion resonates: "Generation is solved. Verification, judgment, and direction are the new craft."

For infrastructure, generation has been solved for years — Terraform modules, Pulumi components, and now AI-generated HCL can produce any configuration in seconds. What hasn't been solved is governance: ensuring that generated infrastructure is safe, compliant, auditable, and reversible.

Infrastream's manifest system transforms AI agents from risky autonomous actors into governed participants:

Aspect	Ungoverned Agent	Infrastream-Governed Agent
Output	Raw Terraform / API calls	Typed manifests in a PR
Review	Post-hoc (if at all)	Pre-execution (mandatory)
Permissions	Inherited from CI/CD	Declared in manifest `accessControl` + managed identity
Acting as a user	Shared bot credential	3-legged, per-action consent
Scope	Implicit, unbounded	Per-project scoping via manifest
Rollback	State file manipulation	`git revert` + engine re-converge
Audit trail	CloudTrail (unstructured)	Spanner State Ledger (typed, temporal)
Blast radius	Unknown until incident	Known — engine computes dependency graph

The path from vibe coding to agentic engineering is the path from implicit governance to explicit governance. Infrastream makes that path concrete.

Ready to Deploy Your First Governed Agent?

Start with the Agent manifest reference or explore the Agentic Governance vision for the strategic framework.

Use Case 1: SOC2 Compliance Auditor Agent​

Business Problem​

Agent Architecture​

Manifests​

Security Boundaries​

How the Governance Harness Enables It​

Use Case 2: Cost Optimization Agent​

Business Problem​

Agent Architecture​

Manifests​

Use Case 3: Incident Response Agent​

Business Problem​

Agent Architecture​

Manifests​

Security Boundaries​

Use Case 4: Developer Onboarding Agent​

Business Problem​

Agent Architecture​

Manifests​

Example: Generated Manifests from a Single Request​

Governance Controls​

Use Case 5: Security Posture Management Agent​

Business Problem​

Agent Architecture​

Manifests​

Generated Remediation Manifests​

Pattern: Delegated User Authorization (3-Legged OAuth)​

Business Problem​

How It Works​

Why It Matters​

From Vibe Coding to Governed Agents​

Use Case 1: SOC2 Compliance Auditor Agent

Business Problem

Agent Architecture

Manifests

Security Boundaries

How the Governance Harness Enables It

Use Case 2: Cost Optimization Agent

Business Problem

Agent Architecture

Manifests

Use Case 3: Incident Response Agent

Business Problem

Agent Architecture

Manifests

Security Boundaries

Use Case 4: Developer Onboarding Agent

Business Problem

Agent Architecture

Manifests

Example: Generated Manifests from a Single Request

Governance Controls

Use Case 5: Security Posture Management Agent

Business Problem

Agent Architecture

Manifests

Generated Remediation Manifests

Pattern: Delegated User Authorization (3-Legged OAuth)

Business Problem

How It Works

Why It Matters

From Vibe Coding to Governed Agents