Platform Engineering 2.0: The Agentic Development Platform
While a secure, automated, and efficient infrastructure is the necessary foundation for digital excellence, it is only part of the equation. True velocity is achieved when the process of building, delivering, and deploying software is as streamlined as the infrastructure it runs on. Infrastream is architected to provide this holistic capability, functioning as a true platform engineering solution that bridges the gap between code and cloud.
The industry frames the current evolution as Platform Engineering 2.0 — not a ground-up rebuild, but a purposeful evolution of platform foundations to serve AI-era demands. The reasoning is that the delivery bottleneck has moved: for years the constraint was developers writing code; AI-assisted coding removed that, and the pressure shifted downstream to the platform itself — pipelines, provisioning, security, and compliance. Traditional internal developer platforms, built for containerized workloads, lack native support for GPUs, model registries, MCP gateways, or autonomous agents — a gap that is structural, not configurational. Infrastream closes it, evolving into what the industry calls an Agentic Development Platform (ADP).
The Five Pillars of Platform Engineering 2.0
Platform Engineering 2.0 is best understood as five pillars — not a backlog to work through, but five faces of a single, coherent evolution. Here is how Infrastream delivers each one today.
| Pillar | What it means | How Infrastream delivers it |
|---|---|---|
| 1. AI-Native Platform | The IDP evolves into an Agentic Development Platform where AI workloads are first-class citizens — native model runtimes, tool gateways, and agents as legitimate users with guardrails. | AI agents and tools are typed manifests (Agent, McpConfig), deployed to Vertex AI Agent Engine and Cloud Run under the same GitOps control as every other GCP resource. See below for the full model. |
| 2. Multipersona Experience | The platform serves beyond developers — data scientists, security, FinOps, and non-human personas — through the same APIs, each at the right abstraction. | A product manager states intent in plain language, a platform engineer works in manifests, and an agent operates through the same APIs — an agent is simply another user. See The Infrastream Agent. |
| 3. Embedded FinOps | Cost moves from a quarterly report to a provisioning-time primitive enforced by design, making the cost-aware choice the default. | Model and quota ceilings, per-environment budgets, usage attribution, and intelligent hibernation are declared and enforced alongside the infrastructure. See Business Impact. |
| 4. Security Shifts Down | Security embeds into platform and runtime layers — invisible to developers and immutable by design — and covers new AI attack surfaces. | Least-privilege service accounts, mTLS, controlled egress, immutable Spanner audit trail; for agents, managed identity and consent-scoped authorization. See The Security Framework. |
| 5. Composable By Design | Modular, independently deployable blocks linked by API contracts — swap components without cascading changes. | Compute abstraction lets one container move between targets by changing a manifest field — Cloud Run and Compute Engine today, GKE in active development — compose and evolve rather than build-vs-buy. See below. |
These pillars are sourced from the industry framing of Platform Engineering 2.0 and mapped to Infrastream in the launch announcement, which carries the full references.
What Is an Agentic Development Platform?
An ADP is a platform, built and run by platform engineering, that provides the paths, interfaces, and guardrails that let both humans and agents work reliably at the autonomy levels the organization chooses. Its defining idea is deceptively simple: an agent is simply another type of user — one that needs an identity, permissions, documentation, and boundaries, except it calls those interfaces repeatedly, in parallel, at volumes no human workflow anticipates.
The ADP is an evolution of the Internal Developer Platform (IDP), not a replacement. The prerequisite is strict: a clean, deterministic infrastructure foundation comes first, and agentic autonomy is layered on top. See the launch announcement for the full framing.
Infrastream's infrastructure engine is mature and in production; the agentic layer is early and under active development. Today that means: the agent runtime is ADK-only; agentic deployments should be re-tested per environment before production use and still carry known limitations; governance covers the shipped Agent, AgentDeploymentConfig, and McpConfig kinds, while broader policy controls are still maturing. Treat the agentic examples in these docs as reference patterns, not turnkey guarantees.
Clean foundation first, autonomy second
The single most important rule of building an ADP is that you cannot bolt autonomy onto a shaky foundation — if you don't yet have a good IDP, you have no business building an ADP.
This is exactly how Infrastream is architected. It is a deterministic, GitOps-governed infrastructure engine for Google Cloud first — 47+ resource types, typed manifests, a JIT graph engine that provisions directly against Cloud APIs, and a Spanner state ledger with millisecond-granularity history. The agent layer is built on that same substrate second. Everything an agent does flows through the identical deterministic, reviewed, audited path a human uses. For the underlying IDP capabilities this builds on, see the Internal Developer Platform guide.
The three layers of the Infrastream ADP
An ADP is best understood as three layers. Here is how Infrastream implements each.
1. Tooling layer — the muscles
The reliable, API-driven capabilities that actually change the world: provisioning, delivery, security, and observability, all backed by Infrastructure as Code. In Infrastream this is the manifest system and the Go execution engine. The shift for the agentic era is not a new kind of tooling but a new demand on it: agents call tools repeatedly and in parallel, so the platform must offer reliable APIs, predictable behavior, and structured outputs — which a deterministic, typed engine provides by construction.
2. Path definitions layer — how work flows
A path is the unit of operation in an ADP, and there are three kinds. Infrastream expresses all three:
| Path type | Definition | In Infrastream |
|---|---|---|
| Deterministic | Pipeline-driven, gated, repeatable | The engine itself — manifests resolve to Cloud API calls with zero probabilistic drift |
| Probabilistic | Agent/LLM-driven, verified by review | An agent interprets natural-language intent and generates typed manifests |
| Hybrid | Probabilistic step → deterministic gate → loop until it passes | Agent generates a manifest → schema validation + CODEOWNERS PR review + engine reconciliation → failures route back to the agent |
The hybrid path is the heart of the model: the probabilistic model only ever proposes intent; the deterministic engine is the gate that decides what actually reaches the cloud.
3. Agent Infrastructure layer — the substrate (AIaC)
The constant substrate beneath every agent, managed as Agent Infrastructure as Code (AIaC). Infrastream provides its components as engine behavior and manifest fields, not as plumbing each team hand-rolls:
| Substrate component | Infrastream implementation |
|---|---|
| Identity | Managed agent identity — scoped IAM grants and proactively refreshed tokens, provisioned automatically per Agent |
| Context | Manifests as dense, high-signal context; Spanner state ledger as queryable memory |
| Capability | Agent accessControl (databases, secrets, Pub/Sub); MCP tool access via governed McpConfig |
| Execution | Vertex AI Agent Engine runtime; the JIT graph engine for provisioning |
| Evaluation | Schema validation, CODEOWNERS-gated PRs, and the append-only state ledger as the record of every action |
| Security | The Secure Agent Sandbox — deny-by-default access, 3-legged consent, no privilege self-escalation |
| Observability | RunEvents streaming and millisecond-granularity temporal reconstruction |
See Technology for the runtime detail and Agentic Governance for how identity and consent are enforced.
A maturity model — and where Infrastream sits
Adoption of an ADP is best measured by how the human role changes across the value stream, along four levels:
| Level | Human role | Path mix |
|---|---|---|
| Level 1 | Human-in-the-loop; agents assist in the IDE | Mostly deterministic |
| Level 2 | Parallel work; identity, workspaces, evaluation, and security become non-negotiable | First hybrid loops |
| Level 3 | Full substrate operational; hybrid paths common | Hybrid dominant |
| Level 4 | Full autonomy; paths respond to signals rather than human triggers | Autonomous |
Infrastream customers operate at Levels 1–2 today — every agent action lands as a reviewable pull request, and the identity, sandboxing, and evaluation substrate that Level 2 makes non-negotiable is already in place. Because the full AIaC substrate exists, the platform is built to carry teams to Level 3 without re-platforming. The deliberate constraint — human review on every change — is a choice about autonomy level, not a missing capability.
Teams that chase high autonomy without the substrate underneath find their agents running faster than their guardrails can keep up. Infrastream ships the guardrails and the substrate together, so autonomy can be dialed up safely rather than raced toward.
Because the substrate is reusable, the same governed-agent foundation extends past software delivery — to agentic workflows in finance, operations, and beyond. The hard parts an ADP solves — identity, capability scoping, cost control, auditable execution — are the same wherever autonomous agents touch real systems. Infrastream solves them once, at the infrastructure layer.
Pillar Detail: The Platform Engineering Foundation
A Unified Core Project for the Software Development Lifecycle
A unique and powerful aspect of the Infrastream architecture is its management of both the Google Cloud organization and the source code repositories (via GitHub). This dual visibility creates a unified core management project that allows for the complete automation of the software supply chain.
Because Infrastream understands both the application's source code and its target infrastructure, it can create a seamless, secure, and fully automated pathway from a developer's code commit directly to a production deployment. This eliminates the manual handoffs, configuration errors, and security gaps that typically exist between development, security, and operations teams.
Automating the Software Supply Chain
Infrastream provides a framework for automating the critical stages of software delivery:
- Automated Builds: The platform automatically configures CI (Continuous Integration) pipelines. Based on a simple manifest in the application's repository, Infrastream determines the application type (e.g., Go, Java, Python) and provisions the correct build executors and processes.
- Secure Artifact Management: All build artifacts, such as container images, are automatically versioned and stored in a secure, managed artifact registry. The platform handles all authentication and permissions, ensuring that only authorized pipelines can publish or consume these artifacts.
- Intelligent Deployments: Infrastream orchestrates the deployment of new application versions to the appropriate environments. The declarative nature of the platform ensures that every deployment is consistent, repeatable, and fully audited.
For a complete technical reference on branching strategies, CI provisioning, automatic versioning, and the CD lifecycle, see the Internal Developer Platform guide.
A powerful platform engineering feature of Infrastream is its ability to abstract the underlying compute platform from the application itself. A containerized application can move between compute targets by changing a manifest field, without touching application code. Cloud Run (serverless) and Compute Engine VMs are supported today; Google Kubernetes Engine (GKE) support is in active development and not yet generally available.
This is more than a technical convenience; it is a strategic advantage:
- Optimize for Cost and Performance: A low-traffic service can be migrated to Cloud Run to take advantage of its scale-to-zero capabilities, reducing costs without requiring any application code changes. As GKE support matures, the same portability will extend to Kubernetes workloads.
- Future-Proofing the Architecture: This abstraction decouples the application architecture from the infrastructure architecture. It provides the flexibility to adopt new compute technologies as they emerge and to continuously optimize the cost and performance of the application portfolio without engaging in expensive and time-consuming refactoring projects.
By integrating the application lifecycle directly with the infrastructure, Infrastream delivers a holistic platform that accelerates the entire value stream, from a developer's initial concept to the end-user experience.
Further Reading
- Infrastream Is Now Public — the launch announcement — the primary reference for this positioning, including the ADP definition and the Platform Engineering 2.0 pillars, with sources.
- Agentic Governance — how agent identity, consent, and access boundaries are enforced.
- The Infrastream Agent — the AI-native layer in practice.
- Agent manifest reference — full specification of the
Agentkind.
Infrastream is publicly available with self-serve sign-up at accounts.infrastream.io.