Pulumi Blog: Pulumi neo

How to Run AI Agents on Kubernetes with Pulumi

Joe Duffy — Tue, 28 Jul 2026 00:00:00 +0000

Kubernetes has become the default place teams run agentic AI workloads: CNCF’s 2026 annual survey found that 66% of organizations hosting generative AI models use Kubernetes to manage some or all of their inference workloads.¹ An entire ecosystem has grown up around that fact — agent runtimes, model servers, GPU schedulers — and most of it assumes the infrastructure underneath is already handled. It usually isn’t. An AI agent is not a stateless web service, and provisioning for one takes more than copying a Deployment YAML and swapping the image.

I spend a lot of my time these days thinking about what changes when the thing consuming your infrastructure isn’t a person or a fixed pipeline, but an agent making its own calls about what to do next — and Kubernetes is where I keep seeing that question show up first, because it’s already where most teams run everything else. This post is about that gap: what changes about Kubernetes infrastructure when the workload is an agent, what the current agentic-Kubernetes ecosystem actually looks like, and how to provision and govern that infrastructure with Pulumi using TypeScript and Python — plus where Pulumi Neo fits once the infrastructure itself has to answer to an agent. If you haven’t read our take on the broader shift toward agentic infrastructure, What Is Agentic Infrastructure? is a good companion piece; this post stays specific to the Kubernetes layer.

What makes agentic AI workloads different from ordinary Kubernetes workloads?

An agent’s resource and governance profile looks nothing like a typical web service, largely because it schedules accelerators, holds state across long sessions, and reaches out to systems a normal Deployment never touches.

Dimension	Typical web service	Agent workload
Compute	CPU, predictable	Often GPU/accelerator, bursty
Session shape	Short-lived, stateless requests	Long-lived sessions, conversational state
Egress	Internal services, one database	Model provider APIs, arbitrary tools, other agents
Credential surface	A handful of scoped secrets	API keys for one or more model providers, plus whatever tools/MCP servers the agent is allowed to call
Access/RBAC	Fixed, narrow	Potentially broad — an agent that can act on infrastructure needs infrastructure-shaped permissions
Cost profile	Roughly linear with traffic	Token- and GPU-time-driven, harder to predict

None of this means Kubernetes is the wrong place to run agents — the opposite: its scheduler, autoscaling, and RBAC primitives are exactly the right building blocks for these problems. It means the infrastructure around an agent deserves more deliberate design than “reuse the Deployment template,” particularly around GPU scheduling, secrets, and the blast radius of what the agent is allowed to do.

What does the agentic Kubernetes stack look like in 2026?

There isn’t one “agents on Kubernetes” product; there’s a stack, and most of it is open source and CNCF-adjacent. Being fair to that ecosystem matters here, because Pulumi’s job is to provision and govern the infrastructure underneath these tools, not to replace them.

Project	What it does	Status
kagent	Framework for running AI agents on Kubernetes, with its own MCP server and CRDs for agents and model providers	CNCF Sandbox (accepted May 22, 2025)²
KServe	Model-serving on Kubernetes	CNCF Incubating (accepted Sept 29, 2025)³
Kueue	Job queueing for batch and ML workloads	CNCF Sandbox
KubeRay	Runs Ray (and Ray Serve) clusters on Kubernetes	Kubernetes SIG / Ray ecosystem project
vLLM + llm-d	High-throughput, Kubernetes-native distributed LLM inference	Red Hat-launched, community project
LeaderWorkerSet / JobSet	Multi-node inference and batch training workload APIs	kubernetes-sigs
Dynamic Resource Allocation (DRA)	Kubernetes-native API for scheduling GPUs and other accelerators	GA in Kubernetes v1.34⁴
Gateway API Inference Extension	Routing and load balancing tuned for LLM inference traffic	GA
NVIDIA GPU Operator	Manages NVIDIA drivers and device plugins on cluster nodes	NVIDIA-maintained

kagent is worth a closer look since it’s the piece most directly aimed at “run an agent on Kubernetes.” As of its current release (v0.9.9), it defines its own custom resources — Agent, ModelConfig, ModelProviderConfig, RemoteMCPServer, and SandboxAgent — and ships an MCP server with built-in tools for Kubernetes, Helm, Istio, Argo, and Prometheus, plus the ability to connect to any external MCP server via the RemoteMCPServer CRD.⁵ It’s a genuinely useful abstraction for defining what an agent can do; it isn’t, on its own, an answer for how the cluster the agent runs on got there, who’s allowed to change it, or how secrets get to it safely. That’s the layer Pulumi sits at.

How do you provision Kubernetes infrastructure for AI agents with Pulumi?

A minimal but representative path from “no cluster” to “an agent running on it, governed” looks like this:

Provision a Kubernetes cluster with a GPU-enabled node group sized for your model workload.
Install the kagent CRDs and controller onto the cluster using a Pulumi Helm chart resource.
Store the model provider’s API key as a Pulumi secret sourced from a Pulumi ESC environment, rather than a plaintext Kubernetes Secret.
Declare the agent itself as a custom resource so it’s versioned and reviewed the same way as everything else in the stack.
Attach a policy pack so specific classes of change — like exposing a service publicly, or granting a service account cluster-admin — require an explicit review.
Roll changes out through CI, or through the Pulumi Kubernetes Operator if you want the cluster itself to reconcile against a Pulumi stack.

Steps 1–4 in TypeScript:

import * as pulumi from "@pulumi/pulumi";
import * as kubernetes from "@pulumi/kubernetes";
import * as eks from "@pulumi/eks";

// 1. GPU-enabled node group alongside your existing EKS cluster.
const gpuNodeGroup = new eks.ManagedNodeGroup("agent-gpu-nodes", {
 cluster: eksCluster,
 nodeRole: nodeRole,
 instanceTypes: ["g6.8xlarge"],
 gpu: true,
 scalingConfig: { minSize: 1, desiredSize: 2, maxSize: 4 },
});

const k8sProvider = new kubernetes.Provider("k8s", {
 kubeconfig: eksCluster.kubeconfig,
});

// 2. kagent CRDs and controller via the Helm v4 Chart resource.
const kagentCrds = new kubernetes.helm.v4.Chart("kagent-crds", {
 chart: "oci://ghcr.io/kagent-dev/kagent/helm/kagent-crds",
 namespace: "kagent",
}, { provider: k8sProvider });

const kagent = new kubernetes.helm.v4.Chart("kagent", {
 chart: "oci://ghcr.io/kagent-dev/kagent/helm/kagent",
 namespace: "kagent",
 values: {
 providers: { default: "openAI" },
 },
}, { provider: k8sProvider, dependsOn: [kagentCrds] });

// 3. Model provider API key, sourced as a secret from a Pulumi ESC
// environment (declared in Pulumi.<stack>.yaml, not hardcoded here).
const config = new pulumi.Config();
const openAiApiKey = config.requireSecret("openAiApiKey");

const providerSecret = new kubernetes.core.v1.Secret("openai-credentials", {
 metadata: { namespace: "kagent" },
 stringData: { apiKey: openAiApiKey },
}, { provider: k8sProvider });

// 4. The agent itself, as a versioned custom resource.
const agent = new kubernetes.apiextensions.CustomResource("k8s-ops-agent", {
 apiVersion: "kagent.dev/v1alpha2",
 kind: "Agent",
 metadata: { namespace: "kagent" },
 spec: {
 description: "Answers questions about cluster state and proposes fixes",
 modelConfig: "openai-gpt",
 tools: ["kubernetes", "helm"],
 },
}, { provider: k8sProvider, dependsOn: [kagent] });

The same four steps in Python:

import pulumi
import pulumi_eks as eks
import pulumi_kubernetes as kubernetes
from pulumi_kubernetes import apiextensions

# 1. GPU-enabled node group alongside your existing EKS cluster.
gpu_node_group = eks.ManagedNodeGroup("agent-gpu-nodes",
 cluster=eks_cluster,
 node_role=node_role,
 instance_types=["g6.8xlarge"],
 gpu=True,
 scaling_config={"min_size": 1, "desired_size": 2, "max_size": 4})

k8s_provider = kubernetes.Provider("k8s", kubeconfig=eks_cluster.kubeconfig)

# 2. kagent CRDs and controller via the Helm v4 Chart resource.
kagent_crds = kubernetes.helm.v4.Chart("kagent-crds",
 chart="oci://ghcr.io/kagent-dev/kagent/helm/kagent-crds",
 namespace="kagent",
 opts=pulumi.ResourceOptions(provider=k8s_provider))

kagent = kubernetes.helm.v4.Chart("kagent",
 chart="oci://ghcr.io/kagent-dev/kagent/helm/kagent",
 namespace="kagent",
 values={"providers": {"default": "openAI"}},
 opts=pulumi.ResourceOptions(provider=k8s_provider, depends_on=[kagent_crds]))

# 3. Model provider API key, sourced as a secret from a Pulumi ESC
# environment (declared in Pulumi.<stack>.yaml, not hardcoded here).
config = pulumi.Config()
openai_api_key = config.require_secret("openAiApiKey")

provider_secret = kubernetes.core.v1.Secret("openai-credentials",
 metadata={"namespace": "kagent"},
 string_data={"apiKey": openai_api_key},
 opts=pulumi.ResourceOptions(provider=k8s_provider))

# 4. The agent itself, as a versioned custom resource.
agent = apiextensions.CustomResource("k8s-ops-agent",
 api_version="kagent.dev/v1alpha2",
 kind="Agent",
 metadata={"namespace": "kagent"},
 spec={
 "description": "Answers questions about cluster state and proposes fixes",
 "modelConfig": "openai-gpt",
 "tools": ["kubernetes", "helm"],
 },
 opts=pulumi.ResourceOptions(provider=k8s_provider, depends_on=[kagent]))

The Pulumi.<stack>.yaml for the stack pulls the API key from an ESC environment instead of a plaintext value in source control:

environment:
 - agents-team/production

Verify the exact CRD group/version (kagent.dev/v1alpha2 above) against kagent’s own CRD manifests before you ship this in production — CRD APIs move faster than blog posts do.

Why write agent infrastructure in a general-purpose language instead of templated YAML?

Because an agent’s infrastructure has exactly the kind of conditional, repeated, testable shape that general-purpose languages are built for, and templated YAML is not. A for loop that provisions one GPU node pool per region, a function that returns a standard “agent + its guardrail policy” bundle, a unit test that asserts a policy pack actually blocks an over-privileged service account before it ships — all of that is native to TypeScript, Python, Go, C#, and Java, and bolted-on at best in Helm templates or raw manifests.

This isn’t a knock on Helm or Kustomize, which remain genuinely good tools for packaging and distributing charts — including kagent’s own install, which is a Helm chart for a reason. The distinction is what you’re doing with the result. Distributing a reusable, versioned package is a job Helm is built for. Composing that package into your specific cluster, wiring its secrets, gating its rollout with policy, and testing the whole thing before it ships is software engineering, and it benefits from a real language: loops, functions, types, unit tests, and the same CI/CD your application code already runs through.

How do you keep agent workloads governed, least-privileged, and cost-aware?

An agent that can act on infrastructure needs infrastructure-shaped guardrails, not just a service account and a prayer. Three pieces of the Pulumi platform apply directly:

Policy as code. Pulumi Policies let you write rules — in the same general-purpose languages, not a separate policy DSL — that run before a change is applied: block a Deployment requesting cluster-admin, require GPU node pools to carry a cost-center label, or flag any RemoteMCPServer pointed at a host outside an allowlist.
Pulumi ESC for secrets and configuration, so model-provider API keys and other credentials are centrally managed, rotated, and scoped, rather than copy-pasted into Secret manifests across every cluster an agent touches.
RBAC scoped to the agent’s actual job. The same custom-resource pattern used to declare the agent (shown above) is the natural place to also declare its ServiceAccount, Role, and RoleBinding — as code, reviewed the same way as the agent’s own configuration, not layered on afterward.

I want to be precise here about Pulumi Insights, because I see the two products get conflated more than almost anything else we ship: Insights gives you discovery (a searchable inventory of resources across Pulumi, Terraform, CloudFormation, and manually created infrastructure) and policy enforcement, including pre-built compliance packs. Cost-optimization recommendations are a Neo capability, not an Insights one.

Where does Pulumi Neo fit when the infrastructure itself is agentic?

Neo is Pulumi’s own infrastructure agent, and it’s worth being specific about what it actually does today rather than leaning on the general “AI for infrastructure” framing. Documented capabilities include answering questions about your existing infrastructure, proposing changes and opening a pull request for them, running a preview before anything lands, reviewing PRs, and taking on recurring maintenance work using your team’s established Pulumi practices.⁶ The Infrastructure AI docs cover each of these in more depth.

The thing I care about most with Neo is trust, and trust gets earned one reviewed pull request at a time, not granted upfront. That’s why every capability starts human-in-the-loop and only earns more autonomy once the guardrails have proven themselves in practice — the same discipline this post argues for everywhere else an agent touches your Kubernetes infrastructure. Pulumi’s own product blog has also described Neo handling things like Terraform-to-Pulumi migrations and containerizing and migrating a service onto Kubernetes.⁷

The relevant framing for this post: Neo doesn’t replace kagent, KServe, or any other workload-level agent framework running inside your cluster — it operates one layer up, on the infrastructure that provisions and governs the cluster itself. If your team is running kagent-based agents on Kubernetes, Neo is the thing that can propose the PR that adds a new GPU node pool, review the policy-pack change that locks down a RemoteMCPServer, or handle the maintenance toil around keeping that stack current.

Frequently asked questions

How do you deploy AI agents on Kubernetes?

Provision a cluster (with GPU node pools if your agent needs them), install an agent runtime — kagent is one of the more Kubernetes-native options as of 2026 — and declare the agent as a custom resource alongside its model configuration and any MCP tool servers it needs. Doing this with Pulumi means the cluster, the runtime install, the secrets, and the agent definition are all one reviewable, testable stack rather than a mix of kubectl apply commands run by hand.

Do you need GPUs to run AI agents on Kubernetes?

Not always. An agent that only calls a hosted model API (OpenAI, Anthropic, and similar) needs CPU nodes to run its own logic and tool calls; the GPU-heavy work happens on the provider’s infrastructure, not yours. GPUs matter once you’re self-hosting inference — running an open-weight model via vLLM, KServe, or Ray Serve — which is where projects like Kueue, LeaderWorkerSet, and Dynamic Resource Allocation come in.

How is kagent different from running an agent as a plain Deployment?

A plain Deployment gives you a running process; it doesn’t give you a standard way to describe an agent’s model configuration, its tool access, or its connections to MCP servers as first-class, versionable objects. kagent’s CRDs (Agent, ModelConfig, ModelProviderConfig, RemoteMCPServer, SandboxAgent) exist specifically to make those concepts declarative, so a policy engine, a reviewer, or another automation can reason about them the same way it reasons about a Deployment or a Service.

Can Pulumi manage Kubernetes resources that Helm or Terraform already created?

Yes. Pulumi Insights discovers and inventories resources regardless of what provisioned them — Pulumi, Terraform, CloudFormation, or manual changes — which is useful precisely because most clusters running agent workloads already have Helm-installed components like kagent, an ingress controller, or a GPU operator on them. You don’t need to rip those out to bring the rest of the stack under Pulumi; kubernetes.yaml.v2.ConfigFile and ConfigGroup can also adopt existing manifests directly into a Pulumi program.

What are Kubernetes best practices for AI workloads in 2026?

Match node pools to the workload (GPU pools for self-hosted inference, CPU pools for orchestration and tool-calling), use a queueing layer like Kueue for batch and training jobs so they don’t starve latency-sensitive agent traffic, keep model-provider credentials in a secrets manager (not plaintext Secret objects), and scope every agent’s RBAC to the specific tools it’s allowed to call. For general Kubernetes hygiene beyond the AI-specific pieces, see Kubernetes Best Practices I Wish I Had Known Before.

How does Pulumi Neo help manage Kubernetes infrastructure for AI agents?

Neo operates at the infrastructure layer underneath your agent workloads: it can answer questions about the state of your cluster, propose infrastructure changes as a reviewable pull request, run a preview before anything is applied, review incoming PRs, and take on the recurring maintenance that keeps a Kubernetes-plus-agents stack current — all using your team’s existing Pulumi practices rather than a separate workflow.

Where to go next

If you’re starting from zero, the Kubernetes get-started guide and the Kubernetes provider registry cover the provisioning basics this post builds on. If you’re already running agent workloads and want the governance layer, start with Pulumi Policies and Pulumi ESC. And if agent sprawl — not just agentic Kubernetes workloads, but the broader proliferation of agents across your org — is the more pressing problem, Agent Sprawl Is Here. Your IaC Platform Is the Answer. is the companion read.

CNCF Annual Survey Report, January 2026: cncf.io/wp-content/uploads/2026/01/CNCF_Annual_Survey_Report_final.pdf. ↩︎
“kagent was accepted to CNCF on May 22, 2025 at the Sandbox maturity level.” CNCF Projects: cncf.io/projects/kagent/. ↩︎
KServe accepted as a CNCF Incubating project, September 29, 2025: cncf.io/blog/2025/11/11/kserve-becomes-a-cncf-incubating-project/. ↩︎
Dynamic Resource Allocation reached general availability in Kubernetes v1.34 (released August 27, 2025). Kubernetes blog: kubernetes.io/blog. ↩︎
kagent CRD kinds (Agent, ModelConfig, ModelProviderConfig, RemoteMCPServer, SandboxAgent) per the kagent-dev/kagent v1alpha2 API types, and MCP server tooling per the project README: github.com/kagent-dev/kagent. ↩︎
Pulumi Infrastructure AI / Neo documentation: pulumi.com/docs/ai/. ↩︎
“10 Things You Can Do with Neo” and “10 More Things You Can Do with Neo,” Pulumi blog: pulumi.com/blog/10-things-you-can-do-with-neo/, pulumi.com/blog/10-more-things-you-can-do-with-neo/. ↩︎

Introducing Usage Limits for Pulumi Neo

John Keiser — Tue, 14 Jul 2026 08:00:00 -0700

Pulumi Neo is an AI agent that takes on real infrastructure work, and it’s natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it.

How usage limits work

Your organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one:

In the Pulumi Cloud console, navigate to Settings → Billing & usage → Neo token usage.
In the Manage token usage panel, enter an organization limit.
Save your changes.

When usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then.

Enforcement happens at a natural boundary in Neo’s work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit.

Per-member limits and alerts

You can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization’s. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller.

Turn on Enable email notifications to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses.

Get started

Set your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an Admin or Billing Manager can set them.

Sign in to Pulumi Cloud and set your first organization limit
Read the Neo usage limits documentation for per-member limits, alerts, and enforcement details
Join the Community Slack to share your feedback

Neo code reviews: AI code review built for infrastructure

Pulumi Neo Team — Mon, 22 Jun 2026 08:00:00 -0700

Today we’re introducing Pulumi Neo code reviews, now in public preview. Neo code reviews analyze pull request changes in conjunction with what Pulumi Cloud knows about your running infrastructure, providing both high-level and code-level feedback.

Normal code review agents can’t reliably anticipate the impact an infrastructure-as-code change will have. This is because they don’t have access to critical aspects of the IaC workflow: the potential impact the update will have, in this case the pulumi preview output; and the current state of the cloud infrastructure. Neo not only has access to both of those, but also to the entirety of your other cloud context, such as stack relationships and dependencies.

Running reviews

Neo can review every pull request automatically, or only when someone mentions @pulumi-neo. Either way, it skips draft pull requests and those opened by bots by default.

A review is a comment, so it informs the person approving the merge and sits alongside the required checks and branch protection you already enforce. Neo code reviews run inside the same governance as every other Neo task, with the RBAC, guardrails, and audit logging your organization has set.

Enable code reviews

Neo code reviews are available on GitHub during public preview. They require Pulumi Neo to be enabled for your organization, the Pulumi GitHub App installed on the repositories you want reviewed, and a one-time grant from each organization user to access their GitHub account under Management > Version control. If Neo currently posts preview summaries on your pull requests, code reviews are already enabled, and they take the place of those summaries.

Neo code reviews are free while in public preview. On July 1, 2026, they’ll be generally available, and reviews will begin counting toward your organization’s Neo token usage, at the same per-token rate as any other Neo task. The pricing page shows that rate and the monthly token allotment included with each plan.

Give it a try

Open a pull request against a stack Pulumi manages and see Neo’s review. We want to hear what it catches and what it misses, so hop into the Pulumi Community Slack and tell us.

Stop Prompting. Design the Loop.

Engin Diri — Tue, 09 Jun 2026 00:00:00 +0000

For about two years, the unit of work with a coding agent was the prompt. You wrote a good one, you gave it enough context, you read what came back, and you wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another.

That part is ending. Addy Osmani, a director of AI at Google Cloud, has a name for what replaces it, and I have not stopped thinking about it since: loop engineering. You stop being the person who prompts the agent. You design the loop that prompts it for you.

In my phrasing: you stop being the thing that runs, and start designing the thing that runs. The leverage moves up a layer. What I want to do here is take an honest look at the pieces, and at the part nobody automates.

The leverage moved up a layer

The people building these tools have already made the jump. Peter Steinberger has been posting it as a monthly reminder.

Peter Steinberger (@steipete) on X.

Boris Cherny, who heads Claude Code at Anthropic, says the same thing about his own job. He does not prompt Claude anymore. He has loops running that prompt Claude and decide what to do next, scanning the issue tracker, the team chat, and the timeline for what to build. “My job is to write loops.”

A loop is a goal that prompts itself. You set the purpose, and the system keeps iterating until it’s met. In practice it finds the work, hands it out, checks the result, writes down what got finished, and decides the next thing, then it pokes the agent instead of you. You build that small system once and let it run.

Look closer, and a loop is really two loops nested. The inner one does the work against a spec. The outer one decides what the work should be: it watches an issue tracker, an error feed, a changelog, then writes the next spec and hands it down. Most people are still running that outer loop by hand, in their head, and calling it a backlog.

The part that surprised me is that this is barely a tooling problem anymore. A year ago a loop meant a pile of bash you wrote and maintained forever. Now the pieces ship inside the products, and the same shapes show up in Claude Code and in Codex. Osmani puts loop engineering one floor above the harness, the context and tooling you wire around a single agent. I wrote about that harness a couple of weeks ago. The loop is the thing that runs on top of it: it runs on a timer, it spawns helpers, and it feeds itself.

The five pieces, and the one that holds them together

Strip loop engineering down and you get roughly five building blocks, plus one place to remember things. Both Claude Code and Codex have all five now. The names differ here and there; the capability is the same.

Automations are the heartbeat. They are what make a loop an actual loop and not one run you did once. A prompt or command on a cadence, a scheduled task, a hook that fires at a point in the agent’s lifecycle, or a job on CI that keeps running after you close the laptop. Discovery and triage run themselves, and the findings that matter come to you.
Worktrees keep parallel from turning into chaos. The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines with nobody talking first. A git worktree is a separate working directory on its own branch, so one agent’s edits cannot touch another’s checkout.
Skills are intent, written down. An agent starts every session cold and fills any hole in your intent with a confident guess. A skill is that intent written on the outside: the conventions, the build steps, the “we don’t do it like this because of that one incident,” recorded once where the agent reads it every run. Without skills, the loop re-derives your whole project from zero every cycle.
Connectors let the loop touch your real tools. Built on MCP, they let the agent read the issue tracker, query a database, hit a staging API, or drop a message in chat. This is the difference between an agent that says “here is the fix” and a loop that opens the pull request, links the ticket, and pings the channel once CI goes green.
Sub-agents keep the maker away from the checker. The model that wrote the code is far too generous grading its own homework. A second agent with different instructions, and sometimes a different model, catches the things the first one talked itself into. Worktrees and a cold-context reviewer are two pieces I have written about before, back when the question was running agents in parallel without them trampling each other.

Then the sixth thing: memory. A markdown file, a Linear board, a state file, anything that lives outside the single conversation and holds what is done and what is next. It sounds too dumb to matter, and it’s the whole game. The model forgets everything between runs, so the memory has to live on disk, not in the context window. The agent forgets. The repo does not.

What makes a loop hold together

A loop running unattended is also a loop making mistakes unattended. The one thing that keeps it honest is verification, and verification needs an oracle, something outside the model that returns a hard yes or no. Passing tests, a clean build, a green pipeline, a real production signal. Without an oracle, the loop compounds confidently wrong work, faster than you can read it.

The cleanest version of this already ships in the tools. Claude Code’s /goal keeps working across turns until a condition you actually wrote holds, something like “every test in auth/ passes and lint is clean,” and after every turn a separate, faster model reads the transcript and decides whether you are there yet. The agent that wrote the code is not the one that grades it. That is the maker-and-checker split applied to the stop condition itself. Codex’s /goal reaches the same finish line a different way: the agent audits its own work against the evidence before it can call the goal done.

What the loop still won’t do for you

The loop changes the shape of the work. It does not take it off your desk. And a few things get sharper as the loop gets better, not softer.

Verification is still on you. The split reviewer is what makes “it’s done” mean something, but “done” is a claim, not a proof. Your job is still to ship code you confirmed works, which is harder to remember when the diff arrived while you were at lunch.

The bill comes in two currencies. Tokens and attention. A single unattended run can burn through millions of tokens, and that is only worth it when the tokens buy something worth more than they cost. The quieter trap is the second currency: memory is what lets a loop compound over time, and slop compounds right alongside it. A loop pointed at a vague goal does not get tired and stop. It gets faster.

Your understanding rots if you let it. The faster the loop ships code you did not write, the wider the gap between what exists in the repo and what you actually understand. A smooth loop grows that gap faster, not slower, unless you read what it made. The comfortable posture, where you stop having an opinion and take whatever the loop gives back, is the risky one. Two engineers can build the exact same loop and get opposite results, one moving faster on work they understand deeply, the other avoiding the work entirely. The loop cannot tell which one you are.

When the loop reaches production

Most of this thinking grew up around application code, where a bad run costs you a revert. When the loop reaches into infrastructure, the blast radius is a production outage rather than a revert, and the verification bar has to rise to meet it. The upside is that infrastructure hands the loop a better oracle than application code does. A plan diff is deterministic and machine-readable, a policy check returns a hard verdict, and drift and cost are numbers you can put a threshold on. A reviewer, whether human or agent, can read the change cold, with no memory of the prompt that produced it. That cold-context check is exactly what an unattended loop needs, and it’s the reason an infrastructure loop can be built to hold together while you sleep. Pulumi Neo reasons over the state graph directly, so the checker grounds every claim in what the change actually does, not in what the writer says it does.

Give your loop a real oracle

Infrastructure gives an agent loop a strong oracle: a deterministic plan diff to read and policy checks that return a hard verdict before anything ships. Wire that verification in through the Pulumi MCP server, Agent Skills, or Pulumi Neo.

Get started

Where to start

Pick the loop you can actually trust first. In order:

Start where “done” is unambiguous. CI triage, dependency bumps, a flaky-test hunt, a failing job you keep re-running by hand. Loops need an oracle, so begin where the oracle already exists.
Write the memory file before the loop. One markdown file, or a board. What is done, what is next, what was tried and failed. This is the spine, and everything else hangs off it.
Split the checker from the maker. Use /goal with a verifiable condition, or a second agent with its own instructions. Never let the agent that did the work be the one that decides the work is finished.
Cap it, then read everything. A max-iteration count, a token budget, a teardown step. Run it once, end to end, then read every line it shipped. The first run is the measurement, not the payoff.

Then look at what you built. You designed it once, and it ran without you steering each step. That is the real shift. But the leverage only holds if you wire the loop like an engineer, not like someone looking for permission to stop thinking. Read what it ships. Keep an opinion. Judgment is the one part that does not move up a layer.

The loop will do the typing. The thinking is the work.

See how Pulumi Neo closes the loop on your infrastructure

Five Stacks Before Lunch: The Parallel Coding Playbook for Pulumi

Engin Diri — Tue, 02 Jun 2026 00:00:00 +0000

AI coding has two shapes right now. One agent in a loop, sequential work, you babysitting the chat window. Call that 2x. Most teams live here. Five agents in worktrees, parallel work, fresh-context review on every change. Call that 10x. The trick: 2x is mostly prompting, 10x is mostly plumbing.

The parallel coding playbook is a five-pattern setup for running multiple AI coding agents at the same time without them stepping on each other: an issue used as the spec, a plan/build/validate loop, parallel git worktrees, fresh-session review, and a self-healing layer. The whole thing targets application code. The interesting question, and the one I keep ending up at, is what changes when the five agents are touching infrastructure.

2x is prompting, 10x is plumbing

2x is one human, one agent, one repo, one branch. The agent writes, you review, you tell it to try again, it tries again. The bottleneck is your attention. Whatever the agent’s raw throughput, your reading speed sets the ceiling.

10x moves you out of the per-change loop and into the issue loop. You write five issues with sharp acceptance criteria, send each one to its own agent in its own worktree, and let them plan, build, and validate end-to-end. You read five PRs at lunch instead of pair-programming on one all morning.

Concurrent isolation does the work. And isolation is mostly an infrastructure problem.

The five pillars

The five pillars, in one sentence each.

Issue is the spec. The GitHub issue carries the acceptance criteria. The pull request is the artifact that gets validated. Input and output of every implementation are versioned, scoped, and reviewable on their own.
Plan, build, validate. Three stages, three artifacts. A markdown plan you can read in thirty seconds. A build that produces a diff. A validate step that checks the diff against the spec.
Parallel worktrees. Each agent runs in its own git worktree so concurrent changes never trample each other. One repo, five working trees, five branches.
Fresh-session review. A different agent, a different conversation, no shared context, reads the output and judges it. The reviewer never sees the writer’s chat. An agent reviewing its own output in the same context is theater.
Self-healing layer. When the same issue keeps coming back, fix the system that allowed it. Update the rules, the skills, the AGENTS.md. The agent gets better; the bug class disappears.

The application-code version of this playbook leans on ports, node_modules, and databases to get isolation right. The infrastructure version has a different toolbox.

What changes when the agents are touching infrastructure

Walk the pillars again, this time with a Pulumi shop in mind.

Issue is the spec. For application code, the spec describes behavior. For infrastructure, the spec is a Pulumi component contract plus a Pulumi Policies excerpt. “The resulting bucket is private, lives in eu-west-1, has SSE-KMS, and is tagged owner=team-x.” That sentence compiles to a typed component signature and three policy assertions. The agent does not get to interpret “looks right.” The acceptance criteria are deterministic, which is the whole reason this works.

Plan, build, validate. Pulumi already ships the validate step. pulumi preview produces a deterministic, machine-readable diff a second reviewer can judge without the conversation that produced it. The plan is a markdown doc the agent writes before touching code. The build is pulumi up --target against a review stack scoped to the resources the issue covers. The validate step is the preview output plus the Pulumi Policies verdict.

Parallel worktrees. Worktrees alone are not enough. Two worktrees pointing at the same Pulumi stack will fight over state on the first concurrent up. The unit of isolation for infrastructure is the stack, not the worktree. Each worktree gets its own ephemeral review stack and its own ESC environment for credentials. State branches with the work, credentials branch with the work, and the cloud account does not see five agents elbowing each other.

Fresh-session review. The hardest part of the application-code version is keeping the reviewer cold. For infrastructure, the substrate hands you the cold context. The pulumi preview JSON has no memory of the prompt that produced it. A separate agent reading it has the same starting point a human reviewer has: a diff, a stack name, a policy report. Pulumi Neo reasons over the state graph directly, so the reviewer grounds every claim in what the change actually does, not what the writer says it does. Reviewer quality still depends on how well your policies cover the stack, but the cold-context part comes built in.

Self-healing layer. Most Pulumi Policies rule messages today read like assertions. “S3 bucket has no encryption.” A self-healing layer needs them to read like instructions. “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single rewrite is the difference between an agent flailing and an agent fixing the violation on the first try. When the same rule keeps tripping, the fix is upstream of the next pull request: in the rules, in the skills, in the policy itself.

The five catches, infra edition

Every parallelism story has a catch list. The application-code version lists port conflicts, node_modules sprawl, database conflicts, token blowouts, and PR pile-up. The infrastructure equivalents map almost one to one.

Port conflicts become stack-name collisions. Two agents naming their stack dev and racing each other into Pulumi Cloud. The fix is the same hash-the-path trick the app-code playbook uses: derive the stack name from pulumi.getProject() plus a hash of the worktree path. Resource names follow the same pattern. Collisions go away.

node_modules sprawl becomes provider plugin sprawl, mostly already solved. Three worktrees each pulling their own copy of pulumi-aws would add up fast, except Pulumi already shares plugins through a single cache at ~/.pulumi/plugins. Identical provider versions are reused across worktrees automatically. Per-worktree language SDKs (node_modules, venv) still need the usual care, but the provider layer is free.

Database conflicts become state conflicts. Two agents racing each other into pulumi up on the same stack is the same hazard as two agents writing to the same migrated database. The app-code playbook reaches for Neon branches or per-worktree SQLite files to isolate state. The infra answer is simpler: each worktree gets its own review stack. State branches with the work, by construction.

Token blowouts become cloud spend per ephemeral stack. The cost vector flips. For app code, the worry is LLM bills. For infrastructure, the worry is what your five agents just spun up in five review stacks. The mitigations are boring and they work. Use TTL stacks to tear review stacks down on a schedule. Avoid retainOnDelete on review-stack resources so the teardown actually frees them. Cap retries per spec. Watch the bill.

PR pile-up is the same problem. Five reviewed diffs are still five things waiting on the merge queue. The infra-flavored mitigations: stack-scoped reviewers (the human who owns the stack approves the change to it), the Pulumi Cloud audit log for grouping by stack and time, and auto-merge for the narrow class of changes where the preview diff is clean and every policy passes. That last one is where most of the throughput hides.

Run any agent on your stacks

Pulumi hands every coding agent a deterministic preview, isolated stacks, and policy as code to work against, whether that agent is Claude Code, Cursor, or Pulumi Neo.

Get started

Where to start, this afternoon

Three steps, in order, on a stack with a small blast radius.

Write an AGENTS.md for the repo. Five paragraphs is enough. The component library, the stack naming convention, the policy rules, the review-stack TTL, and the one thing in this repo that bites every newcomer. Neo reads AGENTS.md natively, as do most coding agents. This file is the spec for how the agent should behave even before you write a spec for what it should build.
Cut a 24-hour review-stack TTL. Spin up a review stack on PR open, tear it down on PR close or after 24 hours, whichever comes first. This is the gate that turns “ephemeral” from a slogan into a line item that does not appear on next month’s bill.
Run three issues in parallel. Pick three open issues that touch unrelated resources. Spin up three worktrees, three review stacks, three ESC environments. Let each agent run end-to-end against its own stack. Then have a fourth agent read each preview JSON cold and produce a one-paragraph review. Read three PRs plus the reviewer’s summary at lunch.

That last step is the measurement. The first time you run it, half of the changes will fail validation. The second time, fewer. By the third time you will know whether your spec quality, your policies, and your stack hygiene are good enough to scale this to five, then ten, then to every issue tagged infra:fix.

If three issues finish cleanly, you have the substrate. If they do not, the gap is almost always in the spec or the policy rules, not the agent. Fix the spec, tighten the rule, run it again.

Five stacks before lunch

10x is five concurrent agents, working from five issues, against five stacks, behind five fresh-session reviews. The substrate is already there. Stacks isolate state. ESC isolates credentials. pulumi preview is the deterministic artifact a fresh reviewer can read cold. Pulumi Policies is the self-healing layer when you write the rule messages as instructions.

The remaining work is small and mostly wiring. Write the AGENTS.md. Cut the TTL. Pick three issues that touch unrelated resources. Read three PRs at lunch. Five stacks before the room empties out is a realistic Monday.

See how Pulumi Neo runs your stacks

Bringing Neo to GitHub and Slack

Pulumi Neo Team — Thu, 21 May 2026 08:00:00 -0700

This week, Pulumi Neo started working in two more places: GitHub and Slack. The agent that already runs Pulumi tasks from the Cloud console and the terminal now participates in the threads where your team discusses changes.

Mention @pulumi-neo in a pull request or issue and Neo replies in the thread. Mention @Neo in a Slack channel and Neo starts a task, continuing the conversation as you reply.

Neo in GitHub

Mention @pulumi-neo in a pull request description, a top-level or inline review comment, or an issue. Neo sees the diff, the stacks linked to the repository, and their current state. Reviewers can ask Neo to walk through what a proposed change does, including resources that change in stacks the PR doesn’t touch directly. Responses land in the same thread, so the analysis becomes part of the review record and any follow-up stays with it.

Neo in Slack

Mention @Neo in any channel where Neo has been added, and Neo starts a task in the thread. The reply lands in the same thread, and follow-up messages continue the conversation there. The rest of the channel can see what was asked and what Neo found. Neo has the same capabilities here as in the Pulumi Cloud console or the terminal: check stack state, investigate failures, walk through what a change will do, or carry out actions the team has approved.

Integrations in action

A teammate posts in #platform-engineering: “API latency p95 has been climbing for two days, nobody can figure out why.” You reply:

You: @Neo check the production API stack. Anything change in the last 72 hours?

Neo starts a task in the thread, walks the stack history, and finds a configuration change to the load balancer’s idle-timeout setting that landed Friday afternoon. It posts the change, who deployed it, and when. The rest of the channel sees the finding without you having to retell it.

You: @Neo open a PR to revert idle-timeout to the previous value.

Neo edits the stack’s Pulumi program, runs pulumi preview to confirm the change touches only the load balancer, and opens a pull request with the diff and the preview output. A reviewer pulls it up:

Reviewer: @pulumi-neo what else does this change affect downstream?

Neo replies in the same review thread with the resources that change: the listener config and the target group health check. The reviewer reads, approves, and the change ships.

The investigation moved from Slack to GitHub, and both threads keep the record.

Permissions and governance

Whether the conversation starts in GitHub or Slack, Neo runs with the RBAC permissions of your Pulumi Cloud user. Stack-level controls, organization-level guardrails, and audit logging apply the same way they do for a task started from the console. Starting a conversation in a new place doesn’t grant Neo new permissions; it just changes where the conversation happens.

Try it out

Both integrations are available now for Neo-enabled organizations. The Code Reviews docs and Slack integration docs cover the one-time setup. From there, every engineer with a linked Pulumi Cloud identity can mention Neo from the threads they already work in.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, the Neo CLI launch post for Neo’s new home in the terminal, and the Neo Integrations post for the MCP servers and cloud CLIs that ship with this release.

As always, we’d love to hear what you think — and if you have any suggestions for places we should put Neo next, file an issue in pulumi-cloud-requests.

Neo Automations: Scheduled Tasks Shipped as Pull Requests

Pulumi Neo Team — Thu, 21 May 2026 07:00:00 -0700

Recurring platform work slips: provider versions fall behind, drift accumulates between checks, and the quarterly audit keeps getting pushed back another month. Pulumi Neo can now run any task on a cadence you set, opening a pull request for each run.

Automations in action

Your platform team runs stacks across staging and production, and the AWS, GCP, and Kubernetes providers keep shipping new versions. Nobody has time to bump them stack by stack.

You write one automation:

Every Monday at 8 AM, check the infra/ project for stacks where the AWS, GCP, or Kubernetes provider is more than two minor versions behind. For each one, bump the out-of-date provider, run pulumi preview, and open a PR if the preview is clean.

Monday morning, Neo runs the prompt. It finds three stacks behind on the AWS provider, edits each program, runs preview, and opens a PR for each clean run. You review the PRs like you would any other dependency bump, merge them, and Neo runs again next Monday.

What automations are for

The launch includes four built-in templates: a provider freshness check, an encryption audit, a backup audit, and an activity digest. You can also skip the templates and write your own prompt.

Pick from hourly, daily, weekdays, or weekly cadences. Each automation gets its own page in the Automations tab, where you can edit the prompt, change the schedule, run it once on demand, or pause it.

Safe by default

Automations default to two settings that fit recurring work. Approval mode is auto, so a run doesn’t wait for human confirmation between steps. Permission mode is read-only, so a run can read state and propose changes through pull requests but can’t apply changes directly. You can override either default per automation.

How automations fit with the rest of Neo

A scheduled task uses the same context as an interactive Neo task. Custom Instructions at the organization and project level apply, so a scheduled run respects the same naming conventions, tagging policies, and architecture rules your team has written down.

MCP integrations and CLI integrations work in scheduled tasks the same way they work in interactive ones, so a weekly drift check can query AWS through the aws CLI, file Linear issues, and link related PagerDuty incidents. Scheduled tasks also run with the RBAC permissions of the user who scheduled them, checked at run time; if permissions change between scheduling and execution, the new permissions apply.

Try it out

Open Neo in Pulumi Cloud, switch to the Automations tab, and pick a template or write your own prompt. The automations docs cover the form, scheduling options, and per-automation overrides.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, and the Neo Integrations post for the third-party tools and CLIs your automations can use.

As always, we’d love to hear what you think — and if you have any suggestions for automations that’d make Neo even better, file an issue in pulumi-cloud-requests.

Seven Rules for Building an AI-Native Software Factory

Ewan Dawson — Thu, 21 May 2026 06:00:00 -0700

Ewan Dawson is CTO of Compostable AI, where five engineers run an AI-native software factory: nineteen clients, custom AWS deployments, most of them shipped within a day of contract signing. This article is adapted from his recent Pulumi webinar, and covers rules in more depth than we had time for on stage.

For the past twenty years, I’ve viewed software development as a craft. The best engineers drew on decades of experience to get every function right.

But two years into the agentic AI revolution, I realised software is going to look more like a factory than a craft. The economics have changed. We can’t treat code as bespoke anymore. To scale, we have to think industrial — use the tools to ship more value with fewer engineers.

I joined Compostable AI soon after it was founded 2.5 years ago, and I built the engineering org AI-native from day one. The technology has come a long way since then, and so has my understanding of what AI-native actually means. Here are seven rules I keep coming back to.

An AI software factory is a software operation where autonomous agents write and ship most of the code. The engineers stop writing it by hand and spend their time deciding what gets built and talking to customers. The rules below are our rules for building and running an AI-native software factory.

1. Transform, don’t enhance

Going AI-native isn’t an upgrade to your existing process. If you treat AI as a way to hand your developers smarter tools, you leave most of the value on the table. You get the leverage by rebuilding how you write software — and the culture and processes around it.

I know that’s a tall order for a large, mature engineering org. My advice: start small. Pick one team or one business area and run it as a fully AI-native function. Take what you learn and roll it out from there. And do the political work early, especially with your Governance, Risk, and Compliance function. Get GRC on your side early. Otherwise AI becomes a compliance fight instead of a structural advantage.

Don’t bolt AI onto your existing workflow. Redesign the workflow around what agents can do.

Most of the leverage in this technology comes from rebuilding around it. The tool change is the small part.

2. Remove the problem, don’t solve it

Going AI-native flips which problems are hard and which are easy. The right move often isn’t to engineer a solution. It’s to reframe the problem so it goes away.

Here’s an example. Serving multiple clients with agents writing the code, blast radius wasn’t a hypothetical. One bad agent run could trash a customer’s database, or leak one client’s data into another’s. Our instinct was to build a secure multi-tenant sandbox with guardrails, approvals, rollback. But every version we tried still had agents loose in a shared environment, one bug away from making one customer’s data visible to another’s. So we removed the problem: every client gets two dedicated AWS accounts, one for production and one “digital twin” staging account. Agents iterate on staging until the work checks out. Only then does it ship to production. We have nineteen accounts now, one per client.

Managing nineteen AWS accounts with five engineers used to be an administrative nightmare. When code is cheap, infrastructure-as-code tools like AWS Control Tower and Pulumi make it the easier path.

Remove the problem before you try to solve it.

It’s cheaper to reframe the problem than to engineer your way through it.

3. Pick tools your agents can drive

Removing problems is the process side. The other side is tooling. If you want an automated factory, your tech stack has to be something agents can drive. This overlaps a lot with tools that have great developer experience. If a tool has a robust API plus a clean CLI, agents can drive it. If it’s heavy click-ops around a web UI, agents stop there.

We didn’t get there first try. Our first IaC tool worked fine when we had a couple of clients. As we added more, accounts drifted, deployments slowed, retries got complicated. We needed something built for where we were heading.

I went looking, and Pulumi fit. We express infrastructure as type-safe code — TypeScript, in our case, rather than HCL — and agents are good at writing it. Pair that with Pulumi Neo — pre-loaded with domain-specific Pulumi skills — and we ship infrastructure that follows best practices. One of my colleagues put it: “The scary thing about Neo is it just seems to know everything about what we do.” Pulumi IaC plus Pulumi ESC for configuration beats stitching tools together. And TypeScript lets us build higher-level abstractions that keep the AWS account fleet tractable.

“I don’t actually care if it’s HCL or TypeScript, as long as my software development agents can write it. And they do a better job with TypeScript than HCL.”

Tools have to share your AI-native mindset. If they don’t integrate deeply, the human becomes the glue.

If part of your stack still requires a human to click through a web UI to provision an account, your agents stop there.

4. Don’t let one agent do everything

When I first started with agents, I reached for a god prompt: one massive system prompt meant to guide a single agent through the whole software lifecycle. It didn’t work. Agents struggle when you give them multiple goals. The writer is lenient on its own work — it won’t catch what it just shipped. You don’t want it reviewing the code, checking for security flaws, or hunting bugs.

We get better results from a constellation of specialized agents, each handling one part of the line. Pulumi Neo handles infrastructure. Alongside it sit agents specialized in:

Code implementation
Code review and testing
Security auditing
Internal standards compliance
Documentation updates

Tasks pass down the line. Clean code comes out the other end, with almost no human involved.

Don’t let any agent mark its own homework. Specialize by job.

Treat agents the way you’d treat a team. The one who writes the code shouldn’t be the one signing it off.

5. Measure human hours per unit of value

Once we had agents writing and agents reviewing, throughput went up — but the bottleneck moved past the PR. Engineering hours were still the most expensive thing in the building, so my core metric is human hours per unit of value produced. Minimize that.

That means hunting for every step that still goes through a person — especially the mid-pipeline steps between ideation and production. Automate the human touchpoints along that line, and the factory runs 24/7.

Pushing automation this hard also forces good engineering. A chaotic, undocumented process is impossible to automate. Good engineering is still good engineering, AI or not. Agents won’t fix a weak process.

Measure human hours per unit of value. Treat every one as a bottleneck to remove.

You can’t automate what you can’t describe. Every human in the pipeline marks a piece that hasn’t been described yet.

6. Design for convergence, not one-shot correctness

Even with the human touchpoints removed, the agents don’t ship right the first try. Once you embrace the factory pipeline, you stop needing them to. We design for convergence instead — a system that lands on the right answer through automated iteration.

The loop we run looks like this:

Refinement: agents iterate on the Product Requirements Document until the problem is clear.
Planning: agents draft multiple technical approaches, and evaluation agents pick the best one.
Implementation: coding agents write the software.
Review: specialized checking agents look for bugs, API misuse, and security flaws.

If the checkers find a problem, they hand it back to the implementation agent. The loop repeats until the tests pass and the agents agree on a clean PR. Once it converges, we merge and deploy to staging.

Two things have to be true. You need a way to evaluate the output. Without that, you don’t know when to stop. And the loop has to converge — each pass has to get closer. A checker that fails every PR for a different reason isn’t helping — it just keeps the work going in circles. The feedback has to narrow the search, not widen it.

Once it converges, the question moves on. How cheap can we make it? Lower the time to PR, reduce token count, drop the overall cost. The optimization never really ends.

Don’t aim for one-shot correctness. Design for convergence.

It doesn’t matter how many tries it takes, as long as the loop closes without a human in it. Get convergence first. The optimization comes after.

7. Run the factory in the cloud, not on a laptop

Even a converged factory has to live somewhere. Try running a fully automated factory on individual developers’ laptops, and it falls apart. Laptops are highly trusted machines. Put autonomous agents on them and your security posture drops, fast. And the factory has to run 24/7. Events come from elsewhere — PR comments, Slack threads, errors in test environments.

Cloud also kills configuration drift across a dozen developer machines. The same prompts run against different model versions, and env vars sit half-set on half the laptops. The thing you’re trying to optimize lives in different states across the team. Cloud isn’t just where the factory runs; it’s the only place a team can iterate on it together. Keep everything in one place — AWS, Pulumi Cloud, GitHub. The specific stack matters less than the principle of one place.

And the part that matters most: the factory keeps running, testing, and deploying long after we’ve closed our laptops and gone to sleep — the dark factory pattern, where the line keeps producing with the lights off.

Build the factory somewhere you can work on it — not just somewhere it can run.

A factory scattered across laptops can’t be improved as a system. Cloud keeps it in one shape, 24/7, and lets the team iterate together.

How to build an AI-native software factory

There’s no single blueprint for how to build a software factory, but these seven rules are the software factory model we run at Compostable AI: transform the workflow rather than bolt AI onto it, remove problems instead of engineering around them, pick tools your agents can drive, split work across specialized agents, measure human hours per unit of value, design for convergence over one-shot correctness, and run the factory in the cloud so it operates 24/7.

Closing thought

I’ve shipped more code in the last two years than I did in the fifteen before that. Most of it in languages I couldn’t write by hand. And that’s after a stretch in leadership where I wrote almost none.

If you’re where I was two years ago: don’t ask how AI fits into what you already do. The factory is built one rule at a time, and it’s not a template — it’s the practice of finding where you’re taking advantage of the new economics and where you’re not, where your practices still need an update. The leverage is in finding these places and improving them.

Frequently asked questions

What is a software factory?

A software factory runs software delivery as a repeatable industrial process instead of hand-crafting each feature, the way a physical factory turns out products on a line. The idea predates AI. An AI-native software factory is the version where agents do most of the building and the engineers steer.

How is a software factory different from traditional software development?

Traditional development treats code as a craft, each function written and reviewed by hand. A software factory treats software delivery as an industrial process: agents handle the writing and checking through an automated, converging loop, and the expensive human hours move to defining the work and deciding what to build. The goal is to minimize human hours per unit of value shipped.

How do you keep AI agents from breaking things across customers?

Rather than build a shared multi-tenant sandbox, Compostable AI removes the problem: every client gets two dedicated AWS accounts, one for production and a “digital twin” staging account. Agents iterate on staging until the work checks out, and only then does it ship to production. Infrastructure-as-code tools like AWS Control Tower and Pulumi make running that account fleet tractable for a small team.

What tools does an AI-native software factory need?

Tools your agents can actually drive, anything with a solid API and a clean CLI, rather than click-ops around a web UI. Compostable AI expresses infrastructure as type-safe TypeScript with Pulumi, pairs it with Pulumi Neo for domain-specific infrastructure skills, and uses Pulumi ESC for configuration. If part of your stack still requires a human to click through a UI, your agents stop there.

Watch the original Pulumi webinar. Read the Compostable AI case study, and learn more about Compostable AI and Pulumi Neo.

Neo, Now in the Terminal

Pulumi Neo Team — Wed, 20 May 2026 00:00:00 +0000

Since launching Pulumi Neo, over 4,500 organizations have used it to delegate real infrastructure work: scaffolding, migrating, investigating, operationalizing, and more. Though that usage has come entirely through Pulumi Cloud, we know a large portion of Pulumi users live in the terminal, and increasingly that’s where AI tools run too. Now we’re bringing Neo there.

pulumi neo brings the same Neo experience you’ve had in Pulumi Cloud to your terminal. Running locally means there’s no separate branch to push, no credentials to provision, and no context to paste: Neo picks up the setup you already have.

What local execution unlocks

Neo inherits your setup when it runs locally. The CLIs you’ve authenticated, the environment variables and kubeconfigs you’ve configured, and the project you’re editing right now are all available without any setup on your part. That means Neo can run the same commands you would, against the same systems you have access to.

That makes pulumi neo a fit for paired, interactive sessions where you and Neo work through a problem together. For asynchronous, autonomous tasks you set up and come back to, Pulumi Cloud Neo is still the surface to reach for. Both reach the same Neo.

You can also hand tasks to Neo from other agent sessions. Simply ask your agent, such as Claude Code or Codex, to hand the task off to Neo, and the Neo handoff skill packages the current thread (goal, repo pointers, conversation summary) and starts a Neo task using pulumi neo under the hood. This works anywhere skills are supported, without leaving your current session.

What carries over

Local tools and context are what’s new. The full set of controls you have in Pulumi Cloud Neo applies in the terminal: approval modes (manual, balanced, auto) for tool calls, permission modes (default, read-only) for what Neo can change, and Plan Mode for research and planning before execution.

Integrations carry over too. The integration catalog (connectors to Atlassian, Datadog, Linear, PagerDuty, and others) works the same way from the terminal. Identity, RBAC, and audit all run through your pulumi login, the same way they do in the console. See the Pulumi Neo docs for details.

Get started

pulumi neo ships with the latest Pulumi CLI. To start a session:

Authenticate to Pulumi Cloud with pulumi login.
Run pulumi neo, or pass an initial prompt: pulumi neo "what's in this stack?".

pulumi neo is part of a broader launch on agentic infrastructure. See the pulumi neo command reference and the Pulumi Neo docs for details. 10 things you can do with Neo is a good starting point for tasks to try. The Pulumi Community Slack is the place for questions and feedback.

Neo Integrations: MCP Servers and Cloud CLIs

Pulumi Neo Team — Wed, 20 May 2026 00:00:00 +0000

Pulumi Neo already understands your infrastructure: your code, your stacks, your state. Today we’re launching new capabilities that extend Neo’s reach in two directions: into the third-party systems your team uses to plan and observe, and out to the cloud CLIs that actually drive your infrastructure.

The first half is MCP integrations: connections to Atlassian, Datadog, Honeycomb, Linear, PagerDuty, and Supabase that show up as tools Neo can call during a task. The second half is CLI integrations: scopable access to aws, gcloud, az, and kubectl. Both are configured once at the org level and available to every Neo task in the organization.

Integrations in action

A PagerDuty alert just fired: RDS storage on payments-prod is at 90% and climbing. You want to know how fast, and whether you can buy yourself any runway before it fills.

You: Neo, RDS storage on payments-prod just paged at 90%. How fast is it growing, and what do we have configured?

Neo pulls the active incident from PagerDuty, decides on its own to check Datadog for the storage-utilization curve over the last 30 days, and runs aws rds describe-db-instances --db-instance-identifier payments-prod through your production-aws CLI integration (the name your org gave its production AWS credentials). The database has been growing about 5 GB a day. The instance has AllocatedStorage at 200 GB and MaxAllocatedStorage also at 200, so storage autoscaling is effectively disabled. At current growth, the disk fills in three days.

You: Bump max allocated storage to 500. Open a PR.

Neo edits the payments stack’s Pulumi program to raise maxAllocatedStorage from 200 to 500 on the RDS instance, runs pulumi preview to confirm the change is scoped to that one resource, and opens a pull request with the diff, the preview output, and links to the PagerDuty incident and the Datadog graph. You review the PR and merge it. Pulumi applies the change, and Neo posts the resolution back to PagerDuty.

With three integrations and one conversation, the change is reviewed, shipped, and the alert resolved a few minutes later.

MCP integrations: context from your existing tools

The launch catalog covers six services that show up most often in infrastructure investigations: Atlassian for Jira issues and Confluence runbooks, Datadog for metrics and logs, Honeycomb for traces, Linear for issue tracking, PagerDuty for incidents and on-call schedules, and Supabase for managed database changes. Each connects Neo to a remote MCP server hosted by the provider, so the agent has access to the full set of tools the vendor chooses to expose.

Integrations can be enabled by organization administrators on the Neo Settings page. Once configured, they’re available to every Neo task in your organization.

CLI integrations: live cloud insights

CLI integrations cover what MCP doesn’t reach: live cloud insights. With AWS, GCP, Azure, or Kubernetes connected, Neo can check live database utilization, look up the current state of a running service, verify a service quota before scaling, or reach into resources that aren’t managed by any Pulumi stack.

An admin enables a CLI integration the same way as an MCP one, from your org’s Neo settings. Each integration gets a name your team chooses, like production-aws or staging-gcloud, and tasks reference that name to tell Neo which environment to reach into. You can connect multiple instances of the same CLI (for example, production-aws and staging-aws) so Neo can investigate staging without touching production. Credentials are backed by Pulumi ESC environments your org owns; the CLI integrations docs walk through setup.

Per-task control and failure handling

Both surfaces default to org-wide availability, with per-task overrides. Before starting a task, you can toggle individual MCP integrations off. The toggles only affect that task; the org-level configuration is unchanged.

Failures behave the same way for both. If an integration can’t be reached, Neo logs a warning, skips it, and continues with the rest. A single broken integration doesn’t stop a task. CLI integration connect and disconnect events go to your organization’s audit log, and Neo’s individual CLI calls appear in the task transcript alongside its other tool calls.

Try it out

Both MCP and CLI integrations are available now for Neo-enabled organizations. Open your org’s Neo settings, connect the MCP server or CLI of your choice, and let Neo do the next investigation against the tools you already use. The MCP integrations docs and CLI integrations docs walk through credential setup for each one, and the Neo integrations hub ties it all together.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, and the Neo CLI launch post for Neo’s new home in the terminal.

As always, we’d love to hear what you think — and if you have any suggestions for integrations that’d make Neo even better, file an issue in pulumi-cloud-requests.

Ten More Things You Can Do With Pulumi Neo

Adam Gordon Bell — Tue, 19 May 2026 05:00:00 -0700

Last fall, after launching Pulumi Neo, we wrote up 10 things you could do with it. In the months that followed, as platform teams handed Neo more real work, we watched and listened, shipping a steady stream of features like plan mode, read-only mode, AGENTS.md, an integration catalog, cross-cloud migration, and task sharing. With today’s release, Neo extends beyond the Pulumi Cloud console into the Pulumi CLI, GitHub, and Slack.

So here are 10 more things you can do with Neo.

1. Deploy your app to AWS without writing IaC

Hand Neo a repo. Neo picks the right services — ECS, AWS Fargate, ALB — writes the Pulumi, and opens a PR.

The cloud infrastructure part of getting a new service running, especially one in a new language, is always a few hours of boilerplate: a VPC and subnets, an IAM role, security groups, a load balancer, DNS, and a TLS cert.

With Neo, that work collapses into a prompt. Point Neo at a repo and ask:

Deploy this app to AWS as a publicly accessible service.

Plan mode comes back with the resources Neo will create, named and sized: ECS running on AWS Fargate, an ALB, and the VPC wiring. Approve, and Neo writes the Pulumi program, runs a preview, and opens a PR. You, the human in the loop, merge it after review.

Neo planning a PR and deploying an app to AWS.

Start a Neo task Ask Neo to deploy your app to AWS and make a PR

2. Diagnose a slow API from metrics, logs, and code

Slow endpoints live at the seam between runtime metrics and the stack that runs them. Neo reads both and proposes a fix with the metric evidence as the rationale.

Production incidents often involve multiple tools. When the checkout endpoint’s p95 latency climbs from 200ms to 1.2s, the metric is in Datadog, but the cause might be somewhere in your AWS account: maybe RDS is out of IOPS, maybe the connection pool is too small, maybe the autoscaler isn’t keeping up. Connecting “this metric looks bad” to a recent backend change and then to a one-line fix in your Pulumi program is an exercise in detective work.

Neo’s integration catalog bridges this gap. With built-in Datadog APM, PagerDuty, and Honeycomb integrations sitting alongside your Pulumi state, Neo can read traces and metrics from the tools your team already uses and take action.

Ask Neo:

Find the scaling bottleneck on /checkout from the last 7 days of metrics and propose a fix.

Neo pulls the metric history, matches the Datadog tag db.cluster=checkout-rds to the RDS instance in your prod-checkout Pulumi stack, and opens a PR with a Pulumi diff that bumps the storage IOPS and raises the connection-pool ceiling. You review and roll out the fix.

Toggle on the Honeycomb integration so Neo can read traces and metrics alongside your Pulumi stacks.

3. Automate PagerDuty incident response from Slack

A page comes in. You paste it into your on-call channel and tag Neo, and Neo replies with the cross-system view you’d otherwise spend the first 20 minutes assembling.

On-call triage is often about getting up to speed quickly. You get paged because something is in the red, and you don’t know why.

You mention Neo in the on-call Slack channel:

@neo, what’s going on with this alert?

Neo starts querying metrics and traces. With PagerDuty and Datadog in the integration catalog, it correlates the alert with every deploy and stack change tagged with the alert’s service in the last hour, and finds the change that lines up:

Two deploys in the last hour touched services tagged service:checkout: checkout-api@a3f9c2 (12 min ago, app-layer deploy) and Pulumi stack prod-checkout-rds (45 min ago, decreased max_connections from 200 → 100). p99 latency inflection at 14:03 lines up with the stack change. Likely cause: the connection-pool reduction is starving the API under current load.

You ask a couple of clarifying questions in-thread, then ask Neo to open a rollback PR against the Pulumi stack.

Authorize PagerDuty and Datadog in Neo's settings. Neo can then read alerts in your on-call Slack channel, find the change that correlates, and open a PR when you ask.

4. Implement a Jira or Linear ticket end-to-end

Hand Neo a ticket number from Linear, Jira, or GitHub Issues. Neo reads the description and acceptance criteria, plans against your stack, and opens a PR.

Tickets often pile up not because they’re unimportant, but because they’re not urgent. Ongoing maintenance quietly accumulates. Bumping a provider version, centralizing secret management, working through small policy violations: each one matters, but none of them ever moves to the top of the queue. Explaining each one to an agent is its own overhead.

The fix is letting Neo read the ticket itself. Connect Linear integration or Jira automation through the integration catalog (GitHub Issues works too), and Neo pulls the ticket the same way an engineer would: title, description, acceptance criteria.

Ask Neo:

Implement CAD-1234 in our payments stack.

Neo reads the ticket, plans against your existing stack, opens a PR, and drops a comment back on the ticket. The ticket and the PR end up linked, and your backlog shrinks.

Neo running locally in the Pulumi CLI: fielding a Linear issue, analyzing the codebase, and producing a PR that upgrades multiple projects to the latest Pulumi and AWS provider versions.

Start a Neo task Implement a Linear ticket end-to-end

5. Audit and tighten over-privileged IAM roles

Neo audits each role against what your stack code actually does, and proposes scoped policies that improve your security posture.

IAM cleanup is the kind of work nobody has the time to prioritize. Production has 40 roles. Half of them started with s3:* because nobody had time to scope them, and the cleanup slips quarter to quarter.

Ask Neo:

Audit IAM permissions across my accounts and propose narrower policies for over-privileged stack-managed roles.

Neo cross-references each role’s policy against what the stack code actually calls, and opens a PR per role. The PR body lists the API calls Neo found in the stack code, like s3:GetObject on audit-logs-* and s3:PutObject on audit-logs-staging, as the justification for the scoped policy. The evidence sits next to the diff.

If you’re unclear about which roles count as in-scope or what your team considers over-privileged, start in plan mode and agree on that with Neo first.

Neo auditing an over-privileged IAM role and proposing a narrower policy, with the actually-used permissions as evidence.

Start a Neo task Audit IAM and tighten over-privileged roles

6. Migrate from AWS CDK onto your platform’s golden paths

Neo reads your existing AWS CDK app and lands a PR that swaps AWS’s defaults for your team’s published components.

CDK’s L2 constructs encode AWS’s defaults. s3.Bucket with encryption: BucketEncryption.S3_MANAGED is a sane choice, but it’s AWS’s idea of sane, not yours. A platform team that’s published its own components to the Pulumi Private Registry has already decided what your bucket defaults look like: encryption with the right KMS key, tagging by cost center.

Ask Neo:

Migrate the payments-vpc CDK stack to Pulumi using our published components.¹

Neo reads the source CDK app and your registry side by side. It maps each CDK construct to its closest team-published equivalent, clarifying with you where the mapping is ambiguous.

// Before (AWS CDK, AWS's defaults)
const bucket = new s3.Bucket(this, "Assets", {
 bucketName: "payments-assets",
 encryption: s3.BucketEncryption.S3_MANAGED,
 versioned: true,
});

// After (Pulumi, your team's published component)
import * as platform from "@payments/platform";

const bucket = new platform.Bucket("assets", {
 bucketName: "payments-assets",
 classification: "internal",
});

Start a Neo task Migrate CDK onto your golden paths

Neo handles Terraform and Azure ARM migrations the same way.

7. Containerize a service and migrate it to Kubernetes from a runbook

Write the containerization pattern down once. Every service after that is a prompt away.

Containerizing an application and moving it to Kubernetes involves several small decisions: which Docker image, what labels go on deployments, how ingress is wired, and how secrets reach the pod. But after a team has moved two or three services, the pattern is set. The decisions get written down in a runbook, and every subsequent migration is mostly the same shape.

Ask Neo:

Containerize the billing-api service and write its Kubernetes manifests, following our K8s migration runbook in Confluence.

Neo reads the source repo and the runbook in Confluence via the integration catalog and starts working on your request.

You can save this as a Neo skill that splits the work into multiple PRs — Dockerfile first, ECR config next, Deployment/Service/Ingress manifests after — and link back to each runbook convention for ease of review. The output reflects your conventions: the labels you actually use, the ingress class you’ve standardized on, and the External Secrets Operator config your team prefers.

You’re still the one reviewing the PRs and deciding what the cutover looks like in production. Neo follows your internal standards, so the new service ends up shaped like the last one you migrated.

Neo migrating a VM-based service to Kubernetes step by step, following the team's Confluence runbook.

Once you’ve delegated something a few times, the next move is to automate it. The remaining three tasks are the kind Neo doesn’t need to be asked for. Drift, deps, compliance: they’re the operations you put on a schedule via Neo Automations.

8. Schedule daily configuration drift detection across your cloud infrastructure

Schedule a daily drift check across your cloud. Wake up to PRs that fix what changed overnight.

Configuration drift is an ongoing challenge. The security team rotated an IAM role at 04:47 UTC. Someone changed a security group in the AWS console three weeks ago. Left alone, drift turns into security gaps, into compliance issues, and into the kind of “wait, who changed that?” confusion nobody wants to chase down.

Pulumi Cloud is already good at configuration drift detection. Neo takes it a step further.

Ask Neo:

Every morning at 6 AM, check all production infrastructure for drift and create PRs to fix any issues you find.

From then on, the task runs on its own, and you wake up to a PR per drifted resource. The description spells out what happened (iam_role.audit-reader had inline policy AllowReadAuditLogs added at 04:47 UTC) and cites the section of infra/runbooks/drift.md Neo followed.

Some drift gets encoded into the Pulumi program, like the IAM rotation above. Some gets reverted, like the security group rule added from the console. Some gets ignored entirely, like autoscaler-managed Lambda concurrency reservations the runbook tells Neo to skip. You write the runbook once; Neo follows it every morning to decide what to do.

Neo's morning drift PR. The body names the resource, the change, when it happened, and the section of the runbook Neo followed to decide what to do.

Start a Neo task Schedule a daily drift check

9. Schedule weekly upgrades for outdated Lambda runtimes and providers

Lambda runtimes and container base images age out. Schedule the upgrade pass; review the PRs Neo opens.

AWS Lambda end-of-life notices come out months ahead. Node 20 stopped receiving updates as an AWS Lambda runtime at the end of April. Python 3.9 reached end-of-support last December. After the deadline, AWS blocks new deploys and eventually stops invoking the function. Each one needs to move to a supported runtime before the cutoff.²

Schedule it:

Every Sunday night at 10 PM, check our Lambda functions for runtimes nearing end-of-support and open PRs to upgrade them.

Neo reads the AWS Lambda runtime deprecation page, matches the end-of-support runtimes against every Lambda function in your stacks, and opens one PR per stack.

If Python 3.9 is reaching end-of-support, the upgrade is to Python 3.12, and datetime.utcnow() calls need to move to datetime.now(datetime.UTC). Neo can make all of those replacements in the same PR.

The same task can catch container base images with critical CVEs and bump them too.

Setting up a weekly task in the Scheduled Tasks UI. Once saved, Neo runs the prompt every Sunday night and opens PRs you review on Monday.

Start a Neo task Schedule a weekly runtime upgrade check

10. Fix AWS CIS Benchmark failures with daily PRs

Run the AWS CIS Benchmark on a schedule. Wake up to PRs that fix every failure.

The CIS AWS Foundations Benchmark, available through AWS Security Hub, is something every team should be keeping an eye on. The benchmark finds issues like S3 buckets that allow public read access (S3.1), root user access keys that shouldn’t exist (IAM.4), or CloudTrail not being enabled (CloudTrail.1). Scanning for these issues is a solved problem, but closing and addressing them is not. They pile up between audits because each one is a code change in a different stack, and nobody owns the cross-stack cleanup.³

Schedule the cleanup:

Every morning, read CIS Benchmark failures from Security Hub. For every failure on an IaC-managed resource, open a PR with the fix.

Neo opens one PR per failure. A bucket failing S3.1 arrives as a Pulumi diff that adds blockPublicAccess to the bucket in your prod-checkout stack. The PR body lists the CIS rule number, the resource ID, the diff, and a clean pulumi preview against the live infrastructure.

The runbook is where your security team writes down what each control means for your stacks. Block public S3 buckets, except the ones tagged public-content=true for CloudFront origins. Don’t auto-touch the break-glass IAM roles; page a human instead. Multi-region CloudTrail stays on, no exceptions. Neo reads that file, checks each Security Hub finding against it, and only opens a PR for the ones you’ve said are safe to fix. The rest get routed or ignored, the way your team already handles them.

A PR raised by Neo to fix a CIS Benchmark failure, with the failing rule, the resource, and the runbook decision laid out in the body.

Start a Neo task Schedule daily AWS CIS Benchmark scans

Neo: your newest platform engineer

Over the past year, many product teams have stopped treating AI as a request-by-request assistant and started delegating to it outright.⁴ Agents open pull requests, investigate issues, and iterate on review feedback.

But platform engineers have held back because a bad infrastructure change doesn’t just fail, it can take production down. Coding agents benefit from fast, forgiving feedback loops, but infrastructure recovery is rarely as simple as reverting a commit.

What was missing wasn’t the appetite. It was an agent with enough organizational context and grounding to plan reliably, enough guardrails to feel safe and contain mistakes, and enough discipline to keep working without being asked.

The theme across these tasks is clear. A thing platform engineers used to keep in their heads becomes a task you delegate, then becomes work that runs without you. Neo isn’t generating infrastructure from a template. It’s a teammate who knows your code, your providers, your conventions, your production metrics, and can raise PRs for you to review.

Neo now lives in your terminal, in your pull requests, in your Slack workspace, and in Pulumi Cloud. Pick one of these workflows and give it a try.

The observant reader will notice Terraform-to-Pulumi was covered in the original post. ↩︎
Also covered in the original post. Last year you could ask Neo to do it once. This year you can put it on a schedule. ↩︎
Also covered in the original post. Last year Neo could remediate violations on demand. This year Security Hub feeds findings to a scheduled task that knows your runbook’s interpretation of each control. ↩︎
For a concrete example, see Seven Rules for Building an AI-Native Software Factory: Ewan Dawson, CTO of Compostable AI, runs nineteen client deployments with five engineers, using Pulumi Neo to handle most of the infrastructure work. ↩︎

The Agentic Infrastructure Era

Joe Duffy — Tue, 19 May 2026 03:00:00 -0700

The first frontier agents excelled at was coding. The reason is evident: we have billions of lines of self-documenting code available on the internet for the LLMs to learn from. We can measure their performance on coding thanks to linters, type checkers, compilers, and test suites. The most advanced agentic systems to hit product/market fit have been coding-oriented, and it has resulted in an intense velocity increase in how much and how fast code we can write.

But as the AI tsunami whips up reams of code, what happens to it becomes just as critical. As an industry, we’ve moved beyond just coding to engineering, which includes documentation, tests, automation, and, yes, managing the very infrastructure our applications need to run. The deeper into production you go, however, the less good agents naturally are at helping. At Pulumi, we live and breathe infrastructure, and have seen this firsthand. But we’ve also been hard at work building the platform this new era runs on. In this post, I’ll share our point of view, what we’ve built, what we’re launching today, and why all infrastructure is about to be agentic.

See Pulumi Neo in action → Neo is the agent at the center of everything below: it previews changes, checks them against policy, and opens PRs for your review.

LLMs are natural coders

It is remarkable to look back and note that frontier models, less than two years ago, in August 2024, scored just 33% on SWE-bench Verified. Present-day models score 86%, which represents a 4x reduction in the errors models will make when coding. This enables models to solve increasingly difficult coding problems, and humans can lean more heavily on them to offload tasks. Anthropic’s new Mythos model scores 94% and, although it isn’t generally available at the time of this article, there’s no question we’ll close in on 95% by the end of 2026. That is another 2.3x reduction in error rates. This very naturally puts us onto the last mile of fully agentic coding.

This has been the result of code being highly in-distribution combined with the relentless pursuit of solving coding problems from the frontier labs, especially with Anthropic’s Claude Code, but now with OpenAI’s Codex, driving a tight feedback loop that turns into an improvement flywheel.

Given that LLMs are natural coders, most of us simply assumed that the breakout success we’ve seen with agents for coding would automatically translate into new problem domains. And for sure, we have seen some success. But perhaps not as much as we’d like. Not all problem domains are documented equally well so that the models can naturally learn about them.

Andrej Karpathy noted nearly a year ago that, “Building a modern app is a bit like assembling IKEA furniture,” observing that, though writing the code was easy, fun, and fast, the next mile of actually getting the application running in production entailed many things the LLM wasn’t naturally good at, including “services, API keys, configurations, dev/prod deployments.”

At the same time, we’re seeing something magical happen here at Pulumi: LLMs are now doing over 20% of the infrastructure deployments, up from virtually zero a year ago. We expect this to grow to over 50% before the end of this year and well beyond afterwards.

The agentic infrastructure era is here. Today we’re announcing several new platform capabilities to accelerate it further.

Before getting to what’s new, however, why are we seeing this happening in reality?

Turning infrastructure problems into coding problems

We began our journey with our open-source infrastructure-as-code project nearly ten years ago. Having spent much of my career working on programming languages and compilers, I had a strong conviction that the right substrate for infrastructure was the languages developers already knew and loved, not yet another DSL and certainly not piles of YAML. So we focused first on great ergonomics for humans, and for us, that meant letting you use programming languages, tools, and ecosystems that humans already know and love. Languages like Python, TypeScript, Go, C#, Java, and more. Infrastructure as code also, importantly, comes with guardrails to make infrastructure deployments dependable, reviewable, and auditable. Over time we’ve built out an entire platform with security, compliance, and governance capabilities.

One way of thinking about this is we modeled the realm of cloud infrastructure inside the realm of programming languages: cloud resources become objects, configurations are just variables, dependencies between resources are just references, standard blueprints become classes. Doing so turns the cloud into something that is suddenly programmable, and allows us to apply real software engineering patterns and practices to infrastructure.

Here’s the twist we’ve realized this past year. It is a happy accident that the combination of this plus the verifiability of every change is the exact combination that empowers agents to do infrastructure. LLMs are natural coders. By mapping infrastructure space in code space, agents can do what they’re great at – code – and the infrastructure as code engine is the link that maps those code edits back down into infrastructure space. And as the SWE-bench curve plays out, every domain expressed in code rides it. Infrastructure, thanks to the bet we made nine years ago, is now one of them.

This isn’t just about volume of in-distribution code. Most production infrastructure code lives in private repositories. In contrast, public Python and TypeScript include vast amounts of genuinely production-grade open source, demonstrating real patterns at scale. Public infrastructure DSL corpora skew heavily toward tutorial-grade content that doesn’t scale. By modeling infrastructure in real languages, Pulumi inherits at-scale in-distribution directly. Patterns in Python or TypeScript generalize from what the model has practiced, while DSL patterns are idiosyncratic by definition and don’t compound the same way. Code can express everything an engineer can do, which is exactly why models trained on it have become prolific engineers.

What does this look like in practice? For example, an agent can define reusable infrastructure:

import pulumi
import pulumi_coreweave as coreweave
import pulumi_nvidia_aicr as aicr

class TrainingCluster(pulumi.ComponentResource):
 """A reusable training cluster resource."""
 kubeconfig: pulumi.Output[str]
 def __init__(self, name: str, *, nodes: int, accelerator: str):
 super().__init__("training:Cluster", name)
 self.cluster = coreweave.KubernetesCluster(f"{name}-k8s",
 accelerator=accelerator, # gb200/b200/h100
 count=nodes)
 self.stack = aicr.ClusterStack(f"{name}-aicr",
 kubeconfig=self.cluster.kubeconfig,
 accelerator=accelerator,
 intent="training",
 platform="kubeflow")

And then flexibly consume it – all using languages, like Python, it is already fluent in:

import pulumi
from infra import TrainingCluster
from orchestration import RLFleet

# Spin up an RL stack with 1 learner and 8 rollout workers.
learner = TrainingCluster("learner",
 nodes=4, accelerator="gb200")
rollouts = [
 TrainingCluster(f"rollout-{i}",
 nodes=2, accelerator="b200")
 for i in range(8)
]

fleet = RLFleet("ppo",
 learner=learner, workers=rollouts)

pulumi.export("login", fleet.head_node)

Beyond just being in-distribution, infrastructure as code also gives us a critical piece: the ability to diff changes at the infrastructure layer. Just as we wouldn’t vibe code without git showing us the source changes, we shouldn’t vibe infrastructure without a tool that shows what it will do before it does it, and what it has already done in the past. It’s like git diff for your infrastructure.

The combination of languages, type systems, linting, testing, and infrastructure diffs gives agents enough of what they need to create a fully closed, verifiable, self-correcting loop. Verifiability is the thing that ultimately matters. Every action an agent takes can be previewed, policy-checked, reviewed, and audited. By humans, by other agents, by CI/CD automation. Guardrails guide the agent and verifiability proves the end result.

When I say “infrastructure” by the way, I mean something quite broad. It includes public cloud hyperscalers, of course, like AWS, Azure, Google Cloud, and CoreWeave. It includes cloud native technologies like Kubernetes and Helm. It also includes private clouds powered by VMware and other data center technologies. It includes broad cloud platforms like Cloudflare. But, subtly, also any hosted managed infrastructure service, such as Snowflake, MongoDB, Databricks, and more. And increasingly, the observability, security, and operational tooling that wraps everything else, like Datadog, Sentry, PagerDuty, and other systems that give agents the context to reason about what’s actually happening in production. We support thousands of providers with a consistent programming model and agents are increasingly writing those too.

What we’re shipping today

The foundation of expressing infrastructure as code, combined with verifiable changes, makes a 100% agentic infrastructure future even conceivable. But we still have work to realize this vision.

Meeting agents where they work (the CLI)

We know real code is the right substrate for agentic infrastructure – but we also know agents want to start with the smallest possible commitment and progressively level up. So we’ve designed the Pulumi experience as a progression: an agent should be able to sign up, run its first command, and grow into a full infrastructure as code workflow without ever hitting a wall or manual intervention. Here’s what we’re launching today to make that journey work end-to-end:

Agent accounts. Now agents can use free, ephemeral Pulumi Cloud accounts straight from Claude Code, Codex, OpenCode, Copilot, Cursor, and others. This lets an agent do anything a human could with the Pulumi product without a manual signup step, removing friction while letting agents benefit from robust infrastructure management. A human can claim that account at any time to make it permanent and to share with their team.

One-command execution. Today an agent needs to know how to find, download, and install Pulumi, and manage subsequent versioning and upgrades. Anything that adds friction is discouraging to an agent. We now have an npm package that enables npx pulumi <anything>-style commands so agents can run any Pulumi command anywhere without needing to worry about installation or version pinning.

Imperative infrastructure operations. The new pulumi do command enables direct create, read, update, delete, list, and API operations with a single command. For example, pulumi do create eks:Cluster spins up an AWS EKS cluster with built-in best practices, and pulumi do update cloudflare:r2:Bucket --tags '{ "Foo": "Bar" }' updates a bucket’s tags. All thousands of providers and hundreds of thousands of resource types in the Pulumi ecosystem are supported across clouds. As the complexity of your scenario outgrows singular commands, it is easy to eject out into a full-blown infrastructure-as-code project.

Pulumi Cloud in the CLI. Over the years, we’ve added tons of great capabilities to Pulumi Cloud – things like change history, time-to-live stacks, drift detection, resource discovery and search, private registries, IDP, audit logs, secrets management, team-wide policy enforcement – but didn’t add the respective ergonomic commands to the CLI. These are the sort of features that matter at scale. Now it’s all there in your terminal where agents can use them. Over 30 new commands, you can think of this as the equivalent of the gh CLI which agents really like.

Read the blog: Better CLI Interactions for Agents and Humans →

Neo, everywhere you work

Once an agent (or a team) has graduated through these capabilities, what comes next is asynchronous infrastructure work and, increasingly, autonomy. That’s where Neo comes in: Pulumi’s own infrastructure agent, now upgraded with the surfaces, integrations, and cadences teams actually need to run agentic infrastructure in production. We are shipping:

Neo in the CLI. The new pulumi neo command lets you run the same agent that is already in Pulumi Cloud. It even shares the same agentic loop and uses a sophisticated architecture where the agent workstation is your local computer, allowing it to more seamlessly access source context and tools. This allows you to do agentic infrastructure wherever you prefer: Neo in the cloud for asynchronous, autonomous tasks, or your workstation for more intensive deep-dive paired sessions.

Neo GitHub and Slack Apps. Now you can @-mention Neo from GitHub pull requests, and/or straight from Slack, to kick off agentic infrastructure workflows wherever it is most convenient, complete with whatever guardrails you’ve configured already.

Neo Integration Catalog. A new integration catalog lets you configure connectors to other systems that bring valuable infrastructure management context, including Atlassian, Datadog, Honeycomb, Linear, PagerDuty, and Supabase. This lets you tap into additional planning, specification, observability, and live site incident data, expanding what agents can do on Days 0, 1, and especially 2.

Scheduled Tasks and Read-Only Sessions. Now you can automate recurring infrastructure tasks, including confining Neo to read-only operations for extra safety. This opens up scenarios like reporting on infrastructure patterns weekly, automatically cleaning up waste in your dev accounts daily, or scheduled maintenance and upgrades.

Read the blog: 10 More Things You Can Do with Pulumi Neo →

Partnering with the frontier of AI infrastructure

We’re investing in deep partnerships with the companies building the frontier of AI infrastructure, and are shipping two new partner providers in close collaboration with the teams behind them:

CoreWeave provider. This new provider brings the full power of the CoreWeave platform, the leader in GPU infrastructure, to help teams provision AI workloads with ease. This includes support for all of the CoreWeave services including CoreWeave Kubernetes Service (CKS) and includes several examples and templates out of the box for training and inference architectures written in AI-native languages.

NVIDIA AI Cluster Runtime (AICR) provider. This new provider delivers fully functional NVIDIA software stacks atop the underlying cloud provider’s GPU infrastructure. This packages out-of-the-box components like NVIDIA GPU Operator, Kubeflow, NIM Operator, and dozens more otherwise tricky-to-configure cluster components. We’re excited to showcase the new AICR provider in tandem with our new CoreWeave provider: you can now spin up a CKS cluster and configure it with AICR in one program.

Educating and measuring agentic infrastructure intelligence

We’ve also invested in making Pulumi maximally legible to agents, because the best tools only matter if agents can find them, read them, and know which one to reach for and when:

Agent-friendly docs. We now serve our docs website in markdown to agents and did a pass over our documentation and CLI text to ensure it’s maximally useful to agents.

Agent-friendly CLI ergonomics. We have added --json and structured errors across the CLI to help agents parse and react to outputs appropriately.

New skills. We’ve done a pass over our skills and added a new uber-skill that describes how an agent should leverage the full suite of capabilities we now offer, from Level 0 (agent accounts), to Level 1 (pulumi do), to Level 2 (full IaC and pulumi up), to Level 3 (Pulumi Cloud governance and full autonomy with Neo), and beyond. It’s handy for humans too.

InfraBench. We have created a new benchmark to measure how well an agent performs on a wide array of representative infrastructure tasks. This is the infrastructure equivalent to SWE-bench and lets us measure stock agents, agents plus the new tools and skills, and Neo, and how they’re improving over time. Although we are still hard at work on building out the comprehensive suite, and will keep it internally for now, we will begin publishing our progress against InfraBench as we continue tackling new problems and improving agent performance.

What comes next

We’re primarily focused on two pillars as we go forward:

First, we are making agentic infrastructure a reality with increasingly autonomous workflows. The pace and scale of infrastructure in an AI era are beyond anything we’ve seen before, and we need to ensure infrastructure doesn’t become the bottleneck to velocity. We will be shipping steady improvements that help agents score better on InfraBench as a measure of their abilities. This will begin with new building blocks and in-context improvements, but we’re really excited that every improvement the frontier labs ship in general-purpose coding ability is automatically an improvement in agentic infrastructure on Pulumi, at zero cost to us or to our users. The result is that Pulumi-equipped agents will consistently and measurably outperform raw agents on real infrastructure work, and that gap will compound as the substrate and the models both improve.

Next, a world in which agents are provisioning, updating, monitoring, and managing all of our infrastructure changes the human/agent/infrastructure interface greatly. We need better change management, policy enforcement, and observability tools. Going from a single human doing a single infrastructure task at a time, to a single agent doing that task, to teams of agents doing lots of autonomous infrastructure tasks at once, will reveal new bottlenecks needed to fully govern your infrastructure. We have a lot of those facilities in Pulumi Cloud already but we will continue pushing here to improve them and ensure they scale up as fast as they need to. This is the layer that matters even as agents themselves get great at infrastructure. The smartest agent in the world still needs guardrails, audit trails, and policy enforcement to be trusted with production systems at scale, and that layer gets more valuable as agents get more capable, not less.

The combination of these two things will lead to a world where agents are able to manage more infrastructure, and to do so with increasing autonomy, while human operators retain full visibility, understanding, and control over what their teams of agents are doing at all times. This is the full engineering loop applied to infrastructure. Not just code generation, but design, review, deployment, and operation, with agents and humans collaborating across every step.

It’s a new era, and we’re just getting started

It was remarkable to see in practice and at scale that what’s good for humans is good for agents: ergonomic infrastructure as code. We’ve seen every point along the spectrum, ranging from Wiz managing 1 million resources and doing 100k daily deployments, to Compostable.ai already living the 100% agentic infrastructure dream, to a frontier lab who grew their infrastructure footprint by 982% in a year, all using infrastructure modeled in true code. All very different scales and teams, but with one thing in common: it was code all the way down.

Languages and verifiability already provide strong foundations, however, there are still clear areas we need to improve, beginning with making the full suite of infrastructure automation, security, and governance tools more accessible to agents. That’s what today is all about. To deep dive on details of the launches, check out the companion blog posts released today.

Agentic infrastructure is a super exciting one-way door for our industry. We’re pushing hard to take this beyond 20% and toward 100% in the years ahead. This is uniquely enabled by infrastructure as code in languages the models already speak combined with built-in verifiability that makes agentic work automatically safe. There’s more to be done, however, today’s launch will bend the curve even further upwards. We’re still only just getting started.

Get started with Pulumi free → Install the CLI and provision your first agentic-ready stack in minutes.

Happy clouding,

-Joe

The Dark Factory Pattern for Infrastructure: Running Pulumi Lights-Out

Engin Diri — Tue, 05 May 2026 00:00:00 +0000

The original dark factory was Fanuc’s robotics plant in Oshino, Japan, where the lights are off because nobody is on the floor. Robots build robots. Parts move through the line for weeks at a time without a person walking past them.

The same pattern is now showing up in software. Three engineers at StrongDM shipped roughly 32,000 lines of production code without writing or reviewing any of it. Stripe’s “Minions” agent system merges over a thousand pull requests every week. In January, Dan Shapiro of Glowforge published a five-level autonomy ladder that landed cleanly enough to become the shorthand most people now use, and BCG put out a piece calling it the dark software factory.

Almost every public writeup so far is about application code. The harder question is what this looks like for infrastructure.

What a dark factory actually is

Shapiro’s ladder is the cleanest framing I’ve seen. He borrows it from the SAE’s self-driving levels, and it fits surprisingly well:

Level	What it is	Driving analogy
0	Spicy autocomplete	Stick shift; you do everything.
1	Coding intern (boilerplate)	Cruise control.
2	Junior developer (interactive pair)	One hand on the wheel.
3	AI writes the majority; you review every PR	Eyes still on the road.
4	Spec-driven; agent runs unattended for hours; you review later	Sleeping at the wheel, you can still wake up.
5	Dark factory; no human review of code before production	No steering wheel at all.

Most teams are at level 2 or 3. A few of the more aggressive ones are at 4. Level 5 is the experiment. Most teams won’t get there safely, and probably shouldn’t try to. The interesting design question is what has to be true for level 5 to be safe at all, and that question gets sharper when the thing being shipped is infrastructure.

A dark factory is not a coding harness. A harness is the framework an agent runs inside; the dark factory is the surrounding system that makes a harness’s output mergeable without a human reading the diff. Copilot and Cursor sit at the other end: interactive, the human stays in the loop on every keystroke. The dark factory takes the human out of the per-change loop entirely and puts them at the top, writing the spec and the acceptance criteria.

The wall between generator and validator

Strip the dark factory down to its layers and there are four of them.

flowchart LR
A[Inputs<br/>Humans] --> B[Code Generation<br/>Autonomous]
B --> C[Validation<br/>Autonomous, isolated]
C -->|pass| D[Merge & Deploy<br/>Autonomous + existing CI/CD]
C -->|fail| B
A -.->|holdout scenarios<br/>generator never sees these| C

The single most important rule is that Code Generation and Validation must be completely isolated. The generator never sees the acceptance scenarios. A separate evaluator does, and it judges the generator’s output against scenarios the generator could not have memorized.

The reason is sycophancy. LLMs are too eager to agree with their own prior turns and too willing to declare victory on something they just produced. Without isolation, the same model that wrote the change is the one telling you it’s fine. The practical concern is direct: a test stored in the same codebase as the implementation will get lazily rewritten to match the code, not the other way around. It isn’t malice; it’s the agent doing exactly what it was asked, badly. The wall is what stops that.

StrongDM’s pattern for this is holdout scenarios: plain-English BDD acceptance tests stored where the generator cannot reach them. Each scenario runs three times against an ephemeral deployment, two of three must pass, and the overall pass rate has to clear 90% before the change moves forward. If the generator fails, it gets a one-line failure message (“SQL Injection Detection failed: endpoint returned 500”), not the scenario text. It cannot game the test.

Without that wall, you don’t have a quality gate. You have theater.

Why infrastructure is the harder version

Application code factories can lean on tests, linters, and type checkers. Infrastructure adds blast radius, drift, secrets, irreversible actions, and multi-region state. A code dark factory shipping a broken UI causes a bad user experience. An infrastructure dark factory shipping a broken IAM policy ends in a postmortem.

A few things make this manageable on Pulumi specifically.

The orchestrator does not need to be invented. The Pulumi Automation API is the engine as an SDK in Python, TypeScript, Go, .NET, Java, or YAML, which is the same surface a dark factory orchestrator runs on. Credentials don’t have to be long-lived: ESC and OIDC issue short-lived ones per run, so the agent never sees a static secret.

Policy doesn’t have to be probabilistic: CrossGuard enforces deterministic rules at preview time. Execution doesn’t have to happen on a laptop: Pulumi Cloud Deployments runs pulumi up inside a governed runner with audit logs and approval rules already wired. And the reasoning layer doesn’t have to start from scratch: Pulumi Neo is grounded in your state graph and ships with three modes (Auto, Balanced, Review) that line up cleanly with Shapiro’s levels 5, 4, and 3.

That doesn’t make Pulumi a dark factory by itself. It means the parts that an application-code factory has to build from scratch are pieces a Pulumi shop already has: a credential broker, a policy engine, a governed runner, a state-aware reasoning layer, an audit trail.

And one more piece nobody talks about: pulumi preview produces a clean, deterministic validation artifact, and CrossGuard evaluates that artifact without ever seeing the conversation that produced the program. That’s the same context-free judgment the holdout pattern depends on, applied at the policy layer instead of the acceptance-test layer. For infrastructure, half the wall is already built.

The interesting work is the part that nobody ships in a box.

The interesting work

What no platform ships for you is the wall: the holdout scenarios for infrastructure, the isolated evaluator that runs them, and the agreement on which stacks are even allowed to run lights-out.

The happy-path orchestrator is small. It pulls a spec, runs preview, hands the preview to an isolated evaluator (with its own credentials and its own access to the cloud, no access to the generator’s prompt or output), and branches on the verdict. Auto mode runs up immediately. Balanced mode submits a deployment that requires approval. Review mode opens a PR for a human. Every branch records a stack version traceable in the audit log. Retries, observability, secret rotation, and the rest of the production-grade plumbing add up to real code, but the shape is small.

The wall is the part that takes a week to get right. You write five plain-English scenarios for one stack (“after pulumi up, the bucket is private, has SSE-KMS, lives in eu-west-1, and is tagged owner=team-x”) and a janky evaluator that runs preview and up against an ephemeral copy, queries the cloud, and asks a separate model whether the resulting state satisfies the scenario. Triple-run, 90% pass gate. Then you watch it for a few weeks before you let anything auto-apply.

Ground your agent in real state

Pulumi Neo reasons over your actual state graph and runs in Review, Balanced, or Auto mode, so you can grant it more autonomy as your confidence grows.

Get started

A four-phase rollout

This is the same path the application-code factories walked, with the gates tightened.

Phase 1: better context, this afternoon

Write an AGENTS.md for your most active stack repo. Pulumi Neo reads it natively, as do most coding agents. While you’re there, look at your CrossGuard rules and rewrite the error messages as instructions. Not “S3 bucket has no encryption” but “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single change is the difference between an agent flailing and an agent fixing the policy violation on the first try. Wire pulumi preview as a build-before-push gate so PRs don’t show up just to fail CI.

Phase 2: spec-driven with holdouts, this week

Pick one stack with a small blast radius. A review-stack lifecycle is ideal. Write five plain-English holdout scenarios for it and the janky evaluator above. Humans still approve every PR. Don’t auto-merge yet. You’re earning the data, not declaring trust.

Phase 3: take the human out of the merge

Only after the three measurable gates hold over twenty PRs (scenario pass rate above 90%, false positive rate below 5%, human override rate below 10%) flip auto-apply on for that one stack. Add a weekly drift sweep that goes through the same scenario gate as everything else.

Phase 4: lights out

Expand the auto-apply flag to every stack with strong scenario numbers. Wire your issue tracker so tickets tagged infra:fix flow through the pipeline. Mock the cloud APIs that are slow or flaky enough to make scenario evaluation expensive. At this point the orchestrator is configuration, not architecture.

What could go wrong

None of these have clean fixes. The mitigations below reduce risk; they don’t eliminate it. Any team running level 5 should expect to eat one or two of these in the first year.

The validator approves a bad change. This is the obvious one. The standard mitigation is layered: triple-run each scenario with a 2-of-3 threshold, a 90% gate over the run set, a human audit of the first fifty auto-applied changes, and your existing policies still run after the validator says yes.

The agent gets a destroy permission it shouldn’t have. There’s a class of operations that should not sit in the autonomous loop yet: dropping a database, deleting a hosted zone, rotating a root key, anything that crosses a regulated data boundary. Scope what each agent identity can do at the credential layer, require human approval for anything destructive, and start every stack at Review mode. Tag changes, security-group adjustments, and instance resizes can run autonomously today. Release-branch cuts and config promotions can probably run by next quarter. The destructive class earns its way in over months.

You need all three of those layers. Approvals without policy means anything a human approves in a hurry ships. Policy without approvals means a sufficiently clever spec eventually finds the gap. Both without a human kill switch means an incident at 3 a.m. has nobody to escalate to.

Costs blow up. Cap retries at three per spec, alert on token spend per run, and remember that StrongDM reported roughly $1,000 per day per engineer-equivalent. That’s still cheaper than a salary, but only if you put the cap in place before you find out.

Where to start

Most of what a dark factory needs already exists in any reasonably mature platform. Whatever you have for state, policy, credentials, audit, and a deployment runner is the substrate. The interesting work is not building the factory. It’s the wall: the holdout scenarios that make the gap between “the model says it’s fine” and “the system is actually fine” mean something.

For most teams, Phase 1 alone is the win. Full Level 5 may stay out of reach indefinitely, and that’s fine. The path itself forces useful work: clearer specs, named bottlenecks, the deterministic gates humans had been running in their heads.

Write an AGENTS.md and five holdout scenarios for one stack this week. That’s enough to get a real signal on whether the pattern fits your team. The rest of the path is the same problem the application-code factories have already worked through, with the gates set tighter.

Neo Plan Mode: Iterate Before You Execute

Pulumi Neo Team — Wed, 01 Apr 2026 00:00:00 +0000

Infrastructure work ranges from simple updates to complex multi-stack operations. For straightforward tasks, jumping straight to execution is often fine. But complex tasks benefit from deliberate upfront thinking: understanding what exists, identifying dependencies, and agreeing on an approach before anything changes. Today we’re launching Plan Mode, a dedicated experience for collaborating with Neo on a detailed plan before execution begins.

Plan Mode

Without dedicated planning, Neo balances planning with progress toward execution. That works well for many tasks, but complex operations benefit from more thorough upfront discovery. Plan Mode now makes upfront deliberation a first-class workflow, where instead of focusing on getting to execution, Neo focuses entirely on discovery and synthesis until you explicitly approve the plan.

How it works

Enter Plan Mode by selecting the plan button when starting a task. Neo shifts its behavior:

Discovery: Neo investigates your environment — examining existing infrastructure, reading relevant code, checking dependencies, and researching patterns.
Synthesis: From that research, Neo produces a plan explaining what it will do and why. The plan references specific things Neo discovered, like a particular stack configuration or dependency.
Refinement: You refine the plan through normal conversation, challenging assumptions, asking for an alternative approach, or requesting more detail on a specific area.
Approval: Once you’re satisfied, you approve the plan and execution begins. Neo carries forward everything it learned during discovery, so the transition from planning to execution is seamless.

When to use it

Plan Mode is opt-in. You choose it when you want to work through an approach before committing:

Complex multi-stack operations where understanding dependencies matters
Unfamiliar infrastructure where discovery reduces churn
Autonomous execution where plan approval is your key control point before Neo runs without step-by-step oversight

Get started

Plan Mode is available now for all Pulumi Cloud organizations. It works with any task mode, so you can pair thorough upfront planning with whatever level of execution autonomy fits the situation.

To try it, open Neo in Pulumi Cloud. For more details, see the Plan Mode documentation.

Introducing Read-Only Mode for Pulumi Neo

Florian Stadler — Wed, 01 Apr 2026 00:00:00 +0000

A platform engineer with broad access might want Neo to analyze infrastructure and suggest changes, but include guarantees it won’t actually apply them. Read-only mode makes that possible: Neo does the heavy lifting and hands off a pull request for your existing deployment process to pick up.

Control what Neo can change

Neo runs with the permissions of the user who creates a task, but you often want a tighter boundary. Read-only mode solves this by letting you cap Neo’s permissions at task creation time. Neo can still read your infrastructure, run previews, and open pull requests, but it cannot deploy, update, or destroy resources.

How it works

When you create a Neo task, you now choose between two permission levels:

Option	What Neo can do	Availability
Use my permissions	Full access (current default behavior)	All tiers
Read-only	Read, preview, and create PRs. No infrastructure mutations.	All tiers

Read-only mode takes your existing permissions and removes the ability to make changes. Neo remains fully active, meaning it can still read your infrastructure state, run previews, write and refactor code, create branches, and open pull requests. If Neo encounters an operation it can’t perform in read-only mode, the operation fails and Neo reports what it would have done. The only difference is that Neo cannot trigger deployments or other write operations in Pulumi Cloud directly.

Read-only mode and auto-approve

Neo’s operating modes let you choose how much oversight you want: review mode for full approval at each step, balanced mode for approving only mutating operations, and auto mode for hands-off execution.

Read-only mode pairs well with auto-approve. Because Neo cannot perform write operations like deployments or destroys, you can let it run autonomously and trust that the output is a pull request, not a production change. Kick off a task, let Neo work in the background, and come back to a ready-to-review PR.

Getting started

Read-only mode is available today for all Pulumi Cloud users.

Sign in to Pulumi Cloud and select Read-only when creating your next Neo task
Read the Neo documentation for detailed guides on permission levels
Join the Community Slack to share your feedback

Pulumi Neo Now Supports AGENTS.md

Pulumi Neo Team — Fri, 06 Feb 2026 00:00:00 +0000

Neo now reads AGENTS.md files, the open standard for giving AI coding tools context about your project. If you’re already using AGENTS.md, Neo will pick up those same instructions automatically.

The problem AGENTS.md solves

Every codebase has conventions that aren’t captured in linters or formatters. Maybe your team uses a specific naming pattern for infrastructure resources. Maybe there’s a particular way you structure tests, or commands that need to run in a certain order. These are the things you’d explain to a new team member, and now you can explain them to AI tools too.

Without something like AGENTS.md, you end up repeating yourself. Every conversation starts with “remember to use TypeScript” or “make sure you add the environment tag.” It’s tedious, and things slip through.

AGENTS.md gives these instructions a home. You write them once, commit the file to your repo, and any tool that supports the format picks them up automatically.

What to put in yours

Think about what you’d tell someone on their first day working in the codebase. How do you run tests? Are there naming conventions? Any gotchas they should know about?

Here’s an example for a Pulumi project:

# Infrastructure conventions

Run tests with `make test`. This spins up LocalStack, so Docker must be running.

Stacks are named `{service}-{region}-{env}` (e.g., `payments-us-west-2-prod`).
Only the platform team deploys to prod stacks.

All resources need these tags: `cost-center`, `team`, `environment`.

Reusable components live in `components/`. Check there before writing
something new.

There’s no required structure, just markdown. Some teams write a few lines, others write detailed guides. Start small and add things as you notice yourself repeating instructions.

How Neo handles AGENTS.md

When you point Neo at a repository, it reads any AGENTS.md file it finds and applies those instructions to its work. You don’t need to mention the file or remind Neo about your conventions.

If you have a monorepo, you can put AGENTS.md files in subdirectories too. Neo uses the nearest one to wherever it’s working, so you can have general instructions at the root and more specific ones in subpackages.

Your instructions in conversation always take precedence, so you can override the file when you need to. If you’ve also set up Custom Instructions at the organization level, Neo applies those first, then AGENTS.md on top.

Works with the tools you’re already using

AGENTS.md is an open format supported by most AI coding tools: Cursor, Windsurf, GitHub Copilot, Zed, and now Neo. If your team uses different tools for different tasks, they’ll all follow the same project conventions without any extra configuration.

The format is managed by the Agentic AI Foundation under the Linux Foundation, and it’s already in use in over 60,000 open source projects. See agents.md for the full specification.

Get started

Add an AGENTS.md file to your repository and Neo will start using it on your next task. For more on configuring Neo, including organization-wide Custom Instructions and Slash Commands, see the Settings documentation.

Neo: Share Tasks for Collaborative AI Infrastructure Operations

Pulumi Neo Team — Wed, 04 Feb 2026 00:00:00 +0000

Neo shows its work, but until now that context was only viewable by the user that initiated the conversation. When you wanted a teammate’s input on a decision Neo made, you had to describe it in Slack or screenshot fragments of the conversation. Today we’re introducing task sharing: share a read-only view of any Neo task with anyone in your organization, full context preserved.

To share a Neo task, click the share button to generate a read-only link, then send it to a teammate. They see the complete picture: the original prompt, Neo’s reasoning process, the actions it took, and the outcome. Instead of writing up what happened and losing detail in the retelling, you share the task itself.

We built this with security as a core constraint. The original task system enforced strict RBAC, ensuring users could only see and act on resources they had permission to access. Task sharing preserves these guarantees. Viewers can see the conversation with Neo, but they cannot trigger any actions, and links within the shared task to stacks or resources still enforce the viewer’s existing permissions.

The feature is available now. The next time you want a second opinion or need to show a colleague how you solved something, share the task. You’re no longer working alone.

Neo: Zero-downtime migration from CDK, Terraform & Azure ARM

Pulumi Neo Team — Wed, 21 Jan 2026 00:00:00 +0000

The barrier to migrating to Pulumi has always been the infrastructure you already have. Your existing resources can’t be disrupted, and manually importing them into a new tool is risky and time-consuming. Today, we’re excited to share how Neo removes this barrier entirely with automated, zero-downtime migration to Pulumi from AWS CDK, AWS CloudFormation, Terraform, CDKTF, and Azure ARM templates.

Why IaC migrations are hard

The promise of Infrastructure as Code is that your code perfectly describes your running infrastructure. But switching IaC tools breaks this promise in dangerous ways.

When you rewrite your infrastructure code in a new tool, you have two choices, both problematic. You can destroy and recreate all your resources to match the new code, accepting downtime and risk. Or you can try to import existing resources, which requires perfect knowledge of how every resource maps between the old and new systems. Many teams get stuck here, wanting Pulumi’s modern platform but unable to safely make the switch.

Neo’s insight: State knowledge enables perfect migrations

The key to safe migration isn’t just converting code - it’s understanding the complete relationship between your existing IaC tool’s state and your actual cloud resources. Each IaC tool maintains this relationship differently: CDK through CloudFormation stacks, Terraform/CDKTF through state files, and ARM through Azure deployments. But they all have complete knowledge of what they manage.

Neo leverages this existing state knowledge to orchestrate perfect resource transitions. Instead of asking you to manually find resource IDs and construct migration commands, Neo reads your current tool’s state, discovers every resource’s physical identity, and brings them under Pulumi management. This isn’t just automation - it’s using the source tool’s own knowledge against the migration problem.

In practice, this means Neo can bridge the gap between how tools name resources and where they actually live. A Lambda function that CDK knows as OrderHandler9I0J1K2L actually exists in AWS as my-app-OrderHandler-9I0J1K2L, while a Terraform resource at address aws_instance.web[2] maps to EC2 instance i-0abc123def456. Neo understands these mappings and handles the complex cases like composite IDs (FunctionName|StatementId), resource references, and dependency chains that must be migrated in order.

Because Neo uses the source tool’s own state knowledge, your infrastructure doesn’t change at all during migration. Not a single resource is modified, recreated, or even touched. We’re simply transferring ownership from one IaC tool to another.

This approach delivers three critical guarantees:

Zero downtime: Resources are never deleted or recreated
Zero risk: Since nothing changes, you can abandon the migration at any point without consequence
Zero surprises: Preview confirms no infrastructure changes before you commit

Migration in action: Four tools, one approach

Neo adapts its migration strategy to each tool’s unique characteristics while maintaining the same zero-downtime guarantee. Let’s explore how Neo handles migrations from each major IaC tool.

AWS CDK to Pulumi

For teams using AWS CDK, Neo leverages the CloudFormation layer that underpins CDK deployments. CDK’s architecture actually makes migration straightforward: since CDK synthesizes to CloudFormation templates, Neo can read the deployed stacks directly to understand every resource and its configuration. For detailed migration steps, see our CDK migration guide.

The challenge with CDK migrations isn’t the CloudFormation layer - it’s the cryptic resource naming. CDK generates logical IDs like OrdersTableA7B2C3D4 that map to physical resources with completely different names. These mappings are buried in CloudFormation metadata, and getting them wrong means either orphaning resources or accidentally creating duplicates. Neo navigates this complexity by reading CloudFormation’s own stack outputs and resource metadata, discovering the exact physical ID for every logical resource.

CDK also introduces complexity through its construct hierarchy. A single high-level construct might expand into dozens of CloudFormation resources, each with dependencies and references to others. Neo preserves these relationships during migration, ensuring that IAM roles still reference the right Lambda functions, API Gateway deployments still point to the correct stages, and security groups maintain their exact rules. The migration completes with your infrastructure unchanged and Pulumi’s preview confirming zero modifications.

Start a Neo task Migrate your CDK application

AWS CloudFormation to Pulumi

For teams using CloudFormation directly (rather than through CDK), Neo provides a streamlined migration path. CloudFormation stacks contain complete resource metadata - every resource’s logical ID maps to a physical resource in AWS, and CloudFormation tracks these relationships in its stack state. Neo reads this state directly to build a complete picture of your infrastructure. For detailed migration steps, see our CloudFormation migration guide.

The main challenge with CloudFormation migrations is the template language itself. CloudFormation templates use intrinsic functions like !Ref, !GetAtt, and !Sub that create implicit dependencies between resources. A security group might reference a VPC using !Ref MyVpc, while a Lambda function’s role uses !GetAtt LambdaRole.Arn. Neo evaluates these expressions against the actual deployed stack to resolve every reference to its concrete value.

CloudFormation also supports features like conditionals, mappings, and nested stacks that add layers of indirection. Neo handles these by examining what actually got deployed rather than trying to interpret every possible template path. The result is Pulumi code that manages your exact infrastructure configuration - not a theoretical interpretation of your template. The migration completes with pulumi preview confirming zero changes to your running resources.

Start a Neo task Migrate your CloudFormation stack

Terraform to Pulumi

Terraform and CDKTF migrations require two transformations: converting state to establish Pulumi’s connection to your resources, and transforming HCL configuration into Pulumi code. The state conversion is direct - Neo reads your Terraform state and converts it into Pulumi state, preserving the mappings between resource names and cloud IDs. This ensures Pulumi knows that aws_instance.web[2] corresponds to EC2 instance i-0abc123def456.

The code transformation analyzes your HCL to generate equivalent Pulumi code. Neo handles Terraform patterns like count and for_each loops, module structures, and resource dependencies, recreating them idiomatically in Pulumi. The generated code manages your existing infrastructure without modifications - pulumi preview confirms zero changes. For complete migration instructions, see our Terraform migration guide.

Start a Neo task Migrate your Terraform application

Azure ARM to Pulumi

ARM templates present unique migration challenges. Unlike CDK and Terraform, which maintain clear separation between code and state, ARM templates blur this line. The template is both the definition and, through deployment history, part of the state tracking. ARM’s template expression language, with its concat functions and resource ID constructors, makes it difficult to determine what resources actually exist until deployment time. For step-by-step migration guidance, see our ARM migration guide.

Neo orchestrates ARM migrations through intelligent AI-driven conversion. When an ARM template uses functions like concat(parameters('appName'), '-plan'), the conversion process evaluates these expressions using the actual parameter values to generate the correct resource names. Azure resource IDs follow predictable patterns - subscription IDs, resource groups, providers, and resource names - and Neo ensures these are correctly brought under Pulumi management using inline resource specifications directly in the generated code.

The biggest challenge with ARM migrations is handling the implicit dependencies and resource provider quirks. An App Service might implicitly create a service plan, a SQL database requires a server that might be defined in a linked template, and child resources like application settings need separate migration steps. Neo understands these Azure-specific patterns and generates the appropriate Pulumi code to manage every resource. The migration completes with a zero-diff preview, confirming your exact Azure configuration is preserved while giving you a more maintainable, type-safe way to manage it going forward.

Start a Neo task Migrate your ARM template

The architecture powering it all

While each tool requires specific handling, Neo’s core architecture remains consistent:

Universal orchestration layer

Neo acts as the intelligent migration coordinator, regardless of source tool:

Credential verification: Ensures proper cloud credentials are configured in Pulumi ESC
Resource inventory: Builds a complete catalog of existing resources
Conversion orchestration: Manages the code transformation
State migration: Brings existing resources under Pulumi management
Audit trail generation: Creates comprehensive migration reports

Unified state management engine

The state management engine works consistently across all tools:

Maps source resource IDs to Pulumi’s state management
Handles complex and composite resource identifiers
Provides fallback strategies for edge cases
Ensures idempotent operations

Human oversight

While Neo automates the heavy lifting, we maintain human checkpoints:

Review generated code before migrating resources
Verify preview shows zero changes
Approve the resulting pull request

What this means for your team

Migration friction no longer locks you into your current IaC tool. If you want Pulumi’s programming model, policy engine, and multi-cloud support, Neo gets you there without disrupting your infrastructure.

Ready to migrate? Check out our migration guides for CDK, CloudFormation, Terraform, or Azure ARM. Join us in the Pulumi Community Slack or reach out to your account team for a guided migration session.

The Superintelligence Flywheel: Infrastructure for the AI Era

Joe Duffy — Thu, 11 Dec 2025 00:00:00 +0000

We’ve been in the infrastructure business for nearly a decade, and we’ve never been more excited about, or in awe of, the scale we are seeing as the industry pursues superintelligence. We are now hitting a tipping point that requires entirely different approaches to managing and scaling infrastructure in this new era.

What do we mean by superintelligence? Superintelligence means AI systems that operate with genuine autonomy—planning, reasoning, executing, adapting—at scale, on the path toward human-level and eventually superhuman intelligence. The infrastructure needed to accomplish this is greater than anything we’ve ever seen. Jensen Huang projects $600 billion in AI infrastructure spending this year, scaling to $3-4 trillion by decade’s end. Stargate committed $500 billion to AI infrastructure in the U.S. Microsoft, Meta, and Google are each spending $70-90 billion annually on datacenters. AWS just activated Project Rainier, a data center scaling to one million custom Trainium chips for Anthropic’s frontier models.

Superintelligence is driving the biggest, fastest infrastructure scaling period in the history of computing. This is exciting but comes with challenges: all of that infrastructure has to be managed, secured, scaled, made compliant, and cost effective. Legacy infrastructure tools weren’t built for this reality—they add friction that slows progress or breaks it altogether.

This reveals an important insight:

The infrastructure required to build superintelligence demands superintelligence for infrastructure.

The systems being built today for superintelligence are already straining human platform teams to their limits and yet we’re still only just getting started. To succeed, we will have no choice but to use AI itself to help us manage the infrastructure scaling ahead on the path to superintelligence.

Superintelligence demands more infrastructure, which demands superintelligent approaches to managing and scaling that infrastructure, which leads to faster progress towards superintelligence.

We call this the superintelligence flywheel.

The Flywheel Defined

The superintelligence flywheel describes a self-reinforcing cycle between two forces:

Superintelligence Infrastructure: The massively distributed compute, storage, networking, and orchestration systems required to train and serve frontier AI models.

Infrastructure Superintelligence: AI systems capable of managing infrastructure with increasing autonomy. These systems handle the full spectrum of infrastructure automation, from provisioning to securing to evolving and scaling entire environments.

These reinforce one another. As AI infrastructure grows more complex, human teams will increasingly use AI to manage it. This affects all of us: frontier labs, technology innovators, and enterprises modernizing their products and workforces with an AI-first mindset. Infrastructure agents are simply a requirement for all of us in this new world.

The flywheel accelerates.

The Technical Reality

Frontier labs have the most extreme requirements, but everybody else is somewhere on the curve. You don’t have to be training GPT-5 to feel this pressure. If you’re deploying fine-tuned models, running inference at scale, or just trying to keep up with AI-assisted developers shipping faster—you’re on the same curve, just earlier. To stay competitive and innovative in this new era, access to infrastructure needs to be democratized and inherently automation- and experimentation-friendly.

This can be seen most vividly with frontier lab-scale infrastructure challenges:

Training starts with data preparation. Petabytes of data turns into trillions of curated tokens across thousands of CPU cores. Pre-training runs massive GPU clusters hot for months, at a scale where hardware failures are statistical certainties. Checkpoint management, gradient synchronization, and fault-tolerant scheduling become first-order concerns. Fine-tuning and reinforcement learning add even more coordination complexity: synthetic data generation, AI judges, multiple model copies running simultaneously in tightly coupled loops, hundreds of experiment variants, infrastructure that scales elastically as experiments converge or diverge.

Inference means serving models to an ever-elastic sea of users across massive GPU fleets, many clouds, and distributed globally. ChatGPT, for instance, handles over 2.5 billion queries per day with sub-second time-to-first-token expectations. Traffic patterns shift by geography, time, and viral adoption, and the software must be ready to react. The difference between good and poor GPU utilization at this scale can make or break the user experience and the bank.

These examples share three properties that break traditional infrastructure approaches:

Massive scale: Thousands or millions of coordinated resources with complex architectures across multiple regions and cloud providers.
Extreme dynamism: Infrastructure that must spin up, reallocate, and tear down continuously based on job requirements, spot pricing, capacity availability, and failures.
Velocity beyond human capacity: Infrastructure changes that occur faster than human operators can review, approve, and execute manually, often initiated by AI agents.

Of course, even smaller scale examples share these challenges. Whether you’re using AWS SageMaker or Google Vertex AI to fine-tune models for your enterprise, building out your data engineering function to train custom models, or moving your first ML workloads to production—these infrastructure demands become relevant as you scale.

AI-assisted software development tools are making engineers dramatically more productive. Developers are shipping more code than ever before. But unlike software engineering, legacy infrastructure practices lack inherent guardrails to enable AI-assisted infrastructure engineering: linters, static analysis, testing frameworks, canaries, staged rollouts. The tooling that worked when humans were the limiting factor won’t work when AI agents are generating and deploying infrastructure code at machine speed.

Infrastructure Fungibility: The Holy Grail

Instead of treating each use case as a special snowflake, the holy grail is infrastructure fungibility across many clouds. In this world, infrastructure is dynamically allocated based on availability, demand, and data locality. Inference gets served based on current user demand. Experiments get capacity when it’s available. Long-horizon training runs on whatever’s left over.

This is extraordinarily difficult. But without it, the costs compound: researchers waiting for capacity, GPU-hours sitting idle between workloads, time delays that let competitors ship first. At frontier scale, even small inefficiencies translate to tens of millions of dollars.

This level of dynamism can’t be managed by humans watching dashboards and approving PRs. The infrastructure itself needs to become intelligent—capable of planning, executing, and adapting without waiting for human operators.

The frontier labs building this have learned through direct experience. They have historically had to work around legacy infrastructure tools and slow-moving DevOps teams, taking matters into their own hands. As one infrastructure lead put it: “There are thirty people in the world that know how to do this right now.” It is time for this knowledge to spread faster, in the hands of platform teams, because everyone building with AI is running into some version of the same problem.

Towards a Superintelligence Platform

There are two foundations that form a cohesive superintelligence platform:

Foundation #1: Pulumi as the Infrastructure Automation Substrate

We built Pulumi on three principles that are well-suited to the unique challenges of this era:

Infrastructure as code must be actual code. Domain-specific languages and static configuration formats create a ceiling. Instead, standing on the shoulders of giants with real programming languages provides type systems, conditionals, loops, abstractions, package management, testing frameworks, and more. These capabilities facilitate scale. Just as importantly, your team already knows Python, TypeScript, and Go—why force them to learn yet another proprietary DSL and context-switch constantly between application code and infrastructure configuration?

But there’s a deeper reason this matters now. LLMs have been trained on billions of lines of Python, TypeScript, and Go, and deeply understand how to code correctly. Infrastructure in real programming languages becomes infrastructure that AI systems can reason about, generate correctly, and modify safely. We call this an “LLM-sympathetic architecture”: by projecting cloud infrastructure into code space, LLMs can manipulate infrastructure through coding, something they are already superb at which ensures it can be done repeatably and correctly.

One substrate across all of the clouds. Every cloud, every SaaS provider. Frontier labs run training jobs wherever capacity exists: AWS, Azure, Google Cloud, Oracle Cloud, CoreWeave, Lambda Labs. GPU availability is the constraint; cloud provider preference is now secondary.

A single lab may prefer to train on CoreWeave, overflow to AWS when spot capacity becomes available, and tap Google Cloud when the reservations in other cloud providers are used up. Inference deployments span every region where users exist, across whichever providers offer the best latency and cost characteristics.

Infrastructure platforms that aren’t inherently multi-cloud simply can’t serve these requirements, forcing teams to adopt many fragmented tools and workflows. A platform for the superintelligence era simply must treat multi-cloud as a given with unified resource management, policy enforcement, and state tracking across all providers.

Agent-ready architecture. Human-in-the-loop infrastructure management doesn’t scale to the velocity of the new era. The path forward is progressive autonomy: AI agents that operate infrastructure with increasing independence, bounded by human-defined policies and guardrails.

This requires platforms designed for agent interaction from the ground up, with APIs agents can invoke, state they can reason about, policies that define boundaries, audit trails that maintain accountability. The infrastructure platform becomes the substrate on which agents operate. Infrastructure as code, it turns out, is already very good at this thanks to its declarative core.

Foundation #2: Neo as the Agentic Layer

If managing superintelligence scale infrastructure requires AI agents that can handle infrastructure automation, the critical question is: what should those agents look like?

Neo is our answer. Neo is an AI agent that operates infrastructure like a senior platform engineer, built on top of Pulumi’s foundation. Because Pulumi already provides the guardrails that software engineering takes for granted—previews, policy enforcement, state tracking—Neo can handle infrastructure tasks automatically while validating changes before they hit production.

Uniquely enabled by infrastructure as code. Neo operates on infrastructure code, not opaque configurations or cloud APIs directly. Even for resources not yet managed by Pulumi, Neo seamlessly imports them under code management before making changes. Every action flows through version control, policy checks, and state tracking. This ensures the underlying LLM’s coding smarts apply to infrastructure changes.

Built for progressive autonomy. Organizations configure Neo’s independence by environment and task type. Dev environments might permit fully autonomous operation—daily waste cleanup, weekly drift reconciliation—while production changes may require human approval. When Neo encounters unexpected state or errors, it can self-diagnose or loop in a human for assistance as needed. As confidence builds, the autonomy boundary expands, towards full autonomy.

Inherently understands and respects guardrails. The same velocity that creates opportunity creates risk. An agent that can provision 1,000 resources can also misconfigure 1,000 resources. Pulumi’s infrastructure as code foundation provides the safety mechanisms software engineering takes for granted: previews before deployment, policy as code enforcement, audit trails, human-in-the-loop approvals, and organizational best practices encoded in components. Just as you wouldn’t ship code without version control, you shouldn’t let AI manage infrastructure without these guardrails.

Agentically automate anything: Give Neo a prompt like “Provision a PyTorch training environment for LoRA fine-tuning on GKE with 50 A100s using Nvidia’s GPU Operator and Kueue—then run a smoke test.” Neo generates the project, previews changes, provisions everything, verifies it works. Days become minutes. It’s not just for new infrastructure: one customer used Neo to tackle 300,000+ policy violations—work they estimated would take years is now done in weeks.

Frontier models plus infrastructure smarts: Neo builds on a mixture of frontier models while incorporating nearly a decade of infrastructure expertise. Neo benefits from Pulumi’s nearly one billion deployments, hundreds of thousands of AI interactions and known-to-be-working code examples, and many petabytes of semantically-understood, anonymized infrastructure metadata. This foundation is something that no other company in the world has at their disposal.

Pulumi + Neo: The Superintelligence Platform

Pulumi without Neo is already a powerful infrastructure platform—but one that still requires human operators for every change. Neo without Pulumi would never be production-ready, as it would lack the cloud-to-code projection and guardrails that make Neo so good. Together, humans define intent and policy, and intelligent agents handle execution with autonomy.

This is the foundation for setting the superintelligence flywheel in motion.

Evidence at Scale

The flywheel isn’t theoretical. We’re facilitating it daily with thousands of customers:

Hyper-scale: Wiz manages over one million cloud resources across tens of thousands of Kubernetes clusters in hundreds of data centers across every cloud provider imaginable. They do hundreds of thousands of updates daily across thousands of Kubernetes clusters, leading to 5x faster customer onboarding and entering new markets in days rather than months. They treat infrastructure provisioning as just another service in their distributed system.

Infrastructure democratization: Supabase achieved the infrastructure velocity needed to keep up with the AI era’s demand for their own product, empowering 20x more teammates to scale infrastructure in TypeScript, the same language as their application code, rather than proprietary DSLs that nobody understood. New regions deploy in about a week, with 43,000 new databases daily and 100,000+ API calls per second. According to their platform team, now thanks to Pulumi, “the infrastructure team acts as groundkeepers, not gatekeepers.”

Frontier science: We manage infrastructure for organizations including NVIDIA and multiple frontier labs building the models that will define the next decade. The scale requirements for these workloads exceed any we’ve ever seen and are only getting bigger. Just as many customers democratize infrastructure for their developers, we’re seeing frontier labs use Pulumi to accelerate getting science into production with self-service infrastructure for AI researchers.

The Superintelligence Flywheel is in Motion

AI is driving the largest infrastructure buildout in history—whether you’re training frontier models or deploying your first ML workloads to production. That complexity demands intelligent agents. Organizations that embrace this—building infrastructure for AI while using AI for infrastructure—will define the next era of computing.

The superintelligence flywheel is spinning fast, and it’s only going to get faster from here.

Pulumi provides the infrastructure platform for the superintelligence era: infrastructure as code in general-purpose languages, unified multi-cloud management, and Neo for progressive infrastructure autonomy.

Pulumi Neo ・ Superintelligence Infrastructure ・ Case Studies ・ Contact

AI Predictions for 2026: A DevOps Engineer's Guide

Engin Diri — Thu, 11 Dec 2025 00:00:00 +0000

The IDE is dying, and so is tool calling. OpenAI is not going to win. And next year, you’re going to be shipping code that you’ve never reviewed before, even as an experienced engineer.

These are bold claims, but the way we use AI in 2026 for coding and agents is going to look completely different. In this post, I want to cover my predictions and why they matter right now for DevOps engineers. Some of these are definitely hot takes, but that’s what makes this conversation worth having.

IDEs are dead (at least as we know them)

Traditional IDEs where the code is the focus of the interface are simply going to become irrelevant. We’re moving toward agent manager interfaces where we can kick off agents in parallel to work on different features in a codebase or even work on different projects at the exact same time.

We’re already seeing this transition. Google Antigravity combines a familiar AI-powered coding experience with a new agent-first interface. You can deploy agents that autonomously plan, execute, and verify complex tasks across your editor, terminal, and browser. Cursor 2.0 lets you run up to eight agents in parallel on a single prompt, using git worktrees or remote machines to prevent file conflicts. Each agent operates in its own isolated copy of your codebase.

AWS validated this direction at re:Invent 2025 by announcing “frontier agents” including Kiro for autonomous coding, along with dedicated security and DevOps agents. These agents maintain state, log actions, operate with policy guardrails, and integrate directly with CI/CD pipelines.

For infrastructure specifically, Pulumi Neo represents this same shift. Instead of writing code or running CLI commands for every operation, you describe what you need in natural language and Neo handles the implementation. It works across your entire infrastructure, understanding dependencies and creating execution plans that go through pull requests for review.

For DevOps engineers, this means your pipelines need to accommodate AI-generated code at scale. Multiple agents working simultaneously need isolated, reproducible environments. More generated code means more artifacts to track, version, and deploy.

The different paths to AI dominance

A lot of people think that in the future, a single large language model will have a monopoly and be the best at absolutely everything. But what’s really going to happen is different providers will specialize and focus on being the best at different things.

Google is going down the generalist route with Gemini, aiming to be the jack-of-all-trades. Anthropic is focusing on being the best for coding. You can see this in the benchmarks: when Opus 4.5 came out, the first benchmark they highlighted was for software engineering, because that’s what Anthropic is focusing on.

Amazon is carving out its own niche with the Nova model family, announced at re:Invent 2025. The Nova 2 lineup includes specialized models: Pro for complex reasoning, Sonic for real-time voice conversations, and Omni for simultaneous text, audio, and video processing. With Nova Forge, organizations can build custom frontier models by combining their proprietary data with AWS open weight models. The re:Invent message was clear: leveraging your first-party data is now fundamental to going beyond generic AI. We’re talking about 30-40% increases in accuracy when you bring your own data into the equation.

But here’s the hot take: I don’t think OpenAI is going to come out on top with any kind of specialization. They’ve disappointed time and time again with GPT-5 and GPT-4.5. With 4.5, they seemed to try to be the creative specialist, but it just didn’t work. The GPT-5 launch in August 2025 was described as “barely better than last month’s flavor of the month” and on some metrics it’s actually worse than earlier models.

For DevOps teams, this specialization means you’ll need infrastructure that’s model-agnostic and supports multiple AI backends. Plan for secrets management across multiple LLM providers and design your systems to swap models based on the task at hand.

The local AI breakthrough

2026 will be the year of local AI. We didn’t see that much this year besides DeepSeek at the start of 2025, which was a big deal. We had a couple of new models like Qwen 3, but nothing that fundamentally changed the game. Now we’re starting to see new hardware that makes it obvious we’re going to be able to run very large models on smaller devices.

There’s new AI chips that can run upwards of 120 billion parameter large language models on the edge, which would be a complete game-changer. Right now, hardware requirements are one of the biggest challenges for scaling local AI. If we can solve the hardware problem, we get 100% data privacy and zero-millisecond latency for our agents.

AWS is addressing this with Trainium3 UltraServers, their 3nm AI chips delivering 4.4x more compute than the previous generation. More significantly, AWS AI Factories allow organizations to deploy racks of Trainium chips and NVIDIA GPUs directly into their own data centers, addressing data sovereignty concerns while keeping AI inference close to the data.

For DevOps, this opens the door to zero-latency inference in CI/CD pipelines, complete data privacy for sensitive codebases, and reduced cloud costs for AI-heavy workloads.

Engineers as system architects

We’re finally going to get to the point where we’re not the coders. We delegate that entirely to our coding agents, and we become the system architects. This mirrors the evolution of other engineering disciplines. Civil engineers don’t fabricate the steel beams; they design the structure and verify the integrity.

I think of this as a three-step process:

Define: Set your objectives and the system that your agents will operate under
Orchestrate: Delegate the coding to your agents
Validate: Ensure the quality of the outputs and the overall system

We’re still in the loop. We are the final say in whatever is created, but we’re delegating the grunt work to our coding agents.

This is exactly the model that Pulumi Neo implements for infrastructure. When you give Neo a complex request, it creates a task plan outlining the steps it will take to accomplish your goal. This plan provides transparency into Neo’s approach and gives you the opportunity to adjust the strategy before execution begins. Neo operates in different modes: Review mode where everything requires approval, Balanced mode where only deployments need sign-off, or Auto mode for full autonomy. You define the boundaries, Neo orchestrates the work, and you validate through pull requests and previews.

For DevOps engineers, this shift means building robust validation infrastructure becomes critical. When AI writes the code, you need automated testing pipelines, security scanning, and verification systems that can operate at the speed of AI-generated changes.

Code execution is replacing tool calling

Here’s a key insight that kept coming up at re:Invent: models are no longer the bottleneck. Context is. Our agents are going to change a lot next year because code execution is starting to replace tool calling. The problem with tool calling right now is that all the capabilities you give an agent take up context upfront. When you try to give a lot of different tools to an agent, you completely overwhelm it.

Anthropic’s research on code execution with MCP addresses exactly this problem. Code execution is a massive token reduction, faster, and more flexible. You’re giving the agent the ability to generate its own capabilities at runtime by writing code to interact with APIs. A workflow that previously consumed about 150,000 tokens when tools were passed directly through the model was reimplemented with code execution and used only about 2,000 tokens. That’s a 98.7% reduction.

AWS embraced this pattern with Amazon Bedrock AgentCore, which now includes code interpretation capabilities. AgentCore supports any agent framework (CrewAI, LangGraph, OpenAI SDK) and provides memory, browser tools, and observability features that make code execution practical at enterprise scale.

For DevOps, this means you need sandboxed, secure execution environments for AI-generated code. Running agent-generated code requires appropriate isolation, resource limits, and monitoring.

Progressive disclosure and composable skills

The best part about code execution flexibility is it unlocks progressive disclosure. All I mean by that is: you have a lot of capabilities for an agent, but you don’t actually give all of them upfront. Instead, you allow the agent to discover capabilities and then leverage them in a more flexible way.

For each capability, you just have a bit of metadata or description that loads upfront. When the agent decides to leverage that capability, then you load the full instructions. Now you can practically scale to infinity because all capabilities don’t have to be loaded at runtime.

Claude Skills is a good example of this pattern. Skills are organized folders of instructions, scripts, and resources that agents can discover and load dynamically. At session start, the agent scans available skills and populates the system prompt with just a brief name and description (around 100 tokens). The full skill prompt loads only after Claude selects it, preventing context bloat while maintaining discoverability.

Kiro Powers addresses the same problem. Connecting five MCP servers can consume over 50,000 tokens, roughly 40% of an AI model’s context window, before you even type your first request. Powers bundle MCP servers, steering files, and hooks into units that load dynamically based on conversation context. Mention “payment” and the Stripe power activates. Datadog, Figma, and others have powers available.

For DevOps, this translates to modular infrastructure definitions, on-demand capability loading, and efficient resource utilization. Think about how you can apply this pattern to your own automation.

Equip your agents with Pulumi skills

Give Claude Code, Cursor, or any coding agent working Pulumi patterns through Agent Skills and the Pulumi MCP server, so it generates infrastructure that deploys.

Get started

Agent-to-agent protocols are finally happening

Agent-to-agent protocols are where AI agents operate in a peer network, discover each other’s capabilities in real time, and interact autonomously. When Google released their A2A protocol earlier this year, there was a ton of buzz. A lot of people thought it was going to be the next big standard, like the next MCP. But then it kind of fell to the wayside.

The big reason is the chicken-and-egg problem. For A2A to be useful, you need many people to adopt it at the same time. Otherwise, if you build an A2A-compatible agent, it has no other agents to talk to. The whole value proposition is lost unless you already have a big network to attach to.

But that’s finally changing. The Linux Foundation launched the A2A project in June 2025, and adoption is accelerating. Adobe, Microsoft, SAP, ServiceNow, and S&P Global are all implementing A2A. In July 2025, Google released version 0.3 of the A2A protocol with a more stable interface critical to accelerating enterprise adoption.

Machines paying machines

My next big prediction is that machines paying machines is going to become a very big thing. Coinbase released the x402 protocol for exactly this: building AI agents that you expose over the internet but require payment whenever someone else interacts with them.

This goes really well with agent-to-agent protocols. You can create a peer network where you monetize your agents. They all leverage each other but make payments whenever they take advantage of another agent’s capabilities. Cryptocurrency is the perfect solution for this kind of machine-to-machine network because it enables micropayments to be made quickly and globally.

The x402 protocol has achieved 156,000 weekly transactions with 492% growth since launching in May 2025. It’s now integrated with Anthropic’s MCP Protocol, Google Gemini, OpenAI Codex, and other platforms. Stablecoins like USDC enable charging per request, per service, or per second of usage at near-zero transaction costs, enabling payments as low as $0.001 per request.

Artifact reviews instead of diff reviews

When we want to do a rigorous code review, traditionally, we look line by line at all the changes. But coding agents are getting to the point where they can prove their code works through artifacts. Instead of reviewing line by line, we can look at browser recordings, full working demos of a backend API, and other artifacts.

Google Antigravity is a perfect example. As part of its coding process, it can autonomously spin up your website, visit it, scroll through it, take screenshots, and record everything. Agents generate artifacts, including tangible deliverables like task lists, implementation plans, screenshots, and browser recordings. You can verify the agent’s logic at a glance.

Amazon Nova Act takes this further. It enables AI agents to automate browser-based tasks like form filling, QA testing, and workflow validation with over 90% reliability. The service includes built-in observability through live viewing, CloudTrail logging, and session replay, making it possible to review what an agent actually did rather than parsing through code changes.

Shipping code you’ve never read

For the last prediction, we’re tying everything together. We’ve talked about reviewing artifacts instead of diffs, creating systems instead of coding, and the new capabilities for agents with code execution.

We’re going to get to the point very quickly where we’re shipping code that we have never read before. And I’m not talking about people who vibe code. Even experienced engineers are going to trust their systems so much that they have the ability to review the code but they’re not going to. We’re just going to ship to production after reviewing the artifacts.

I presented on this exact topic at the Tel Aviv Pulumi User Group meetup at Qodo HQ back in October, where I demonstrated how Pulumi Neo’s autonomous decision-making capabilities can handle infrastructure tasks that we traditionally managed manually. Qodo is doing fascinating work in this space with their agentic development tools, building systems that let you trust the output without necessarily reviewing every line.

I’m not saying we’re taking the human completely out of the loop. I’m saying we’re going to have a lot of trust in our systems and a validation process that includes us, but that doesn’t necessarily have to be us actually looking at the code. Tools like Pulumi Neo create pull requests with clear documentation of changes, run previews to validate infrastructure modifications, and provide the transparency needed to ship with confidence.

The path forward

The predictions I’ve outlined point to a fundamental shift in how software gets built and deployed. For DevOps engineers, this isn’t a threat but an opportunity to become more strategic and less operational. We’re entering the battle of the agentic frameworks, where the winners will be those who can build faster, cheaper agentic applications through their platforms.

The immediate reality is that your CI/CD pipelines need to accommodate AI-generated code at scale, your secrets management needs to handle multiple LLM providers, and your execution environments need proper sandboxing for agent-generated code. These aren’t future concerns; they’re requirements for working effectively with the AI tools available today.

Looking further out, the engineers who thrive will be those who embrace the system architect role. Define clear objectives and constraints for your AI agents. Build validation frameworks that can verify outcomes without requiring line-by-line code review. Design infrastructure that’s modular enough to load capabilities on demand.

The technology to make this happen already exists. Agent orchestration platforms are shipping. Code execution is replacing tool calling. Progressive disclosure patterns are proven. The question isn’t whether these changes are coming; it’s whether you’ll be ready when they arrive.

Start building for the AI-driven future today

If you want to experience what this future looks like right now, Pulumi Neo is the place to start. Neo lets you make natural language requests for routine infrastructure tasks, analysis, and management. Instead of writing code for every operation, you describe what you need, and Neo handles the implementation, creating task plans, running previews, and opening pull requests for your review.

Whether you’re looking to update outdated resources across your infrastructure, analyze your cloud spend, or automate complex multi-step workflows, Neo provides the agent-first experience that’s defining the next generation of DevOps tooling.

Get started with Pulumi Neo and see how AI-powered infrastructure automation can transform your workflow.
Project: Build a production-ready AI agent by moving from local prototypes to deployed infrastructure with Amazon Bedrock AgentCore, the Strands SDK, and Pulumi.

Encode What You Know With Neo: Custom Instructions and Slash Commands

Pulumi Neo Team — Tue, 09 Dec 2025 00:00:00 +0000

Every organization builds up knowledge over time: naming standards, compliance requirements, patterns your team has settled on, and proven approaches to common tasks. Until now, bringing this knowledge into Neo meant repeating it manually each time - specifying preferences, describing how your team works, and recreating prompts that someone already perfected.

Two new features change this. Custom Instructions teach Neo your standards so it applies them automatically. Slash Commands capture proven prompts so anyone on your team can use them with a keystroke.

Custom Instructions: Standards Applied Automatically

Custom Instructions let you define what Neo should know about your organization and how it should behave. This includes naming conventions, required tags and compliance requirements, technology preferences, and cost guidelines - but also actions Neo should take automatically, like including a rough cost estimate whenever it proposes new infrastructure. You configure them once in your organization settings, and Neo applies them to every task from that point forward.

Consider the difference. Before Custom Instructions, a simple request required loading context:

“Neo, update our Lambda functions to Node 20. Remember, we use TypeScript exclusively, our naming convention is service-region-env, we always deploy to us-east-1 first for testing, and all resources need our standard compliance tags including CostCenter and DataClassification.”

With those details captured in Custom Instructions, the same request becomes:

“Neo, update our Lambda functions to Node 20.”

Neo already knows how your team works, so you can focus on what you’re trying to accomplish.

Slash Commands: Capture What Works

Over time, your team figures out the right way to ask Neo for certain tasks. Maybe someone wrote the perfect prompt for checking policy violations, or discovered an approach to drift detection that catches issues others miss. That knowledge tends to live in someone’s head or buried in a Slack thread.

Slash Commands turn these prompts into shortcuts anyone can use. When you type / in Neo, you’ll see available commands, select one, and Neo receives the full prompt behind it.

Neo ships with built-in commands for common tasks:

Command	What it does
`/get-started`	Learn what Neo can do and how to structure effective requests
`/policy-issues-report`	Lists your most severe policy violations
`/component-version-report`	Lists components that are outdated in your private registry
`/provider-version-report`	Lists providers that are outdated

You can also create your own. In Pulumi Cloud, you define the prompt - no coding required. Once saved, your team can start using it immediately. If a command needs more information than what’s provided, Neo will ask follow-up questions to fill in the gaps.

Get Started

Custom Instructions and Slash Commands are available now. You can configure Custom Instructions in Neo Settings. Slash Commands come with several built-in options, and you can create custom ones tailored to your workflow.

Beyond YAML in Kubernetes: The 2026 Automation Era

Sara Huddleston — Wed, 12 Nov 2025 07:09:46 +0000

Kubernetes continues to evolve, powering not only applications but entire AI and ML systems across clouds, edges, and enterprises. By 2026, DevOps engineers, SREs, cloud engineers, and platform teams face growing pressure to deliver faster, smarter, and more secure infrastructure at scale.

Kubernetes automation is entering a new era where infrastructure as code, policy enforcement, and AI-driven orchestration work together to manage cloud environments intelligently.

Pulumi’s 2025 advancements, including Pulumi Kubernetes Operator 2.0 GA, new Kubernetes best practices playbooks, Pulumi Neo for AI assisted infrastructure management, and Policy Automation, set the foundation for a new era of Kubernetes automation that extends across every role involved in managing modern infrastructure.

In this Kubernetes article:

Why Kubernetes Needs to Go Beyond YAML

The article Kubernetes Best Practices I Wish I Had Known Before highlights a key challenge: relying solely on YAML as the source of truth for Kubernetes is no longer sustainable. Clusters are dynamic, environments multiply, and static YAML files cannot keep up with the complexity of modern infrastructure.

Teams across disciplines face similar challenges:

Multi-cluster and hybrid-cloud sprawl
Inefficient manual configuration and drift
Lack of policy enforcement and governance at scale
Secrets scattered across systems

Pulumi addresses these challenges by introducing general-purpose programming languages such as TypeScript, Python, Go, C#, and Java into Kubernetes management. This approach enables teams to define, test, and share reusable infrastructure code, bridging the gap between declarative manifests and modern software engineering practices.

Learn more: Pulumi Kubernetes documentation

The 2026 Convergence of AI, Platforms, and Policy in Kubernetes

The CNCF State of Cloud Native Development Q3 2025 report shows that more than half of DevOps professionals and nearly a third of all developers now identify as cloud native. Adoption of hybrid and multi-cloud architectures continues to grow, while AI and ML workloads are becoming first-class citizens in Kubernetes environments. The report notes that 41% of professional ML and AI developers are cloud native, confirming that Kubernetes has become a foundational technology for building intelligent, scalable systems.

This trend highlights how the next generation of Kubernetes operations is evolving. Teams need unified platforms that simplify AI-driven workloads, automatically enforce governance, and reduce operational complexity across environments. Pulumi already delivers this through an integrated platform that brings automation, security, and developer productivity together in one place.

Pulumi’s platform provides a complete foundation for intelligent infrastructure management that extends from development to production.

Pulumi Neo adds AI-assisted infrastructure management that turns natural language into production-ready Kubernetes and cloud code.
Pulumi IDP enables engineering and platform teams to build self-service environments that abstract complexity for developers while maintaining consistency and control.
Pulumi Policies brings continuous compliance and policy enforcement directly into the delivery workflow.
Pulumi ESC secures credentials, API keys, and sensitive configurations across Kubernetes and cloud environments.

Together, these capabilities form a unified automation and governance layer for Kubernetes and cloud native systems.

The result is a model where infrastructure, policy, and developer experience work together to power secure, scalable, and AI-ready platforms that meet the needs of engineering teams of every size and discipline, from application development to security and cloud operations.

The 2026 Shift: AI-Assisted Kubernetes Operations

The next phase of Kubernetes management will be AI-driven, context-aware, and self-healing. Infrastructure will not only follow instructions but also understand intent. This is the vision behind Pulumi Neo, an AI Infrastructure Agent designed to help teams automate complex systems.

Pulumi Neo can interpret natural-language requests such as “deploy a GPU-backed EKS cluster with three node groups,” generate infrastructure code that adheres to organizational policies, and continuously refine that code as environments change.

AI-powered observability and decision-making. According to the CNCF Annual Survey, 93% of organizations already use or plan to adopt AI-driven monitoring and predictive analysis for Kubernetes environments. The goal is to identify performance and reliability issues before they affect users. Pulumi Policies assists to get clean and stay clean, while Neo extends this capability by acting on those insights, transforming detected issues into actionable infrastructure updates that teams can validate or deploy.
ML and GPU workloads on Kubernetes. As organizations expand AI and ML pipelines across clusters, automation and cost efficiency become critical (FinOps Foundation). Pulumi Insights is an intelligent infrastructure management service that helps you discover, understand, manage, and improve your infrastructure. Insights improves security, compliance, and efficiency through AI-powered asset and compliance management.
Unifying DevOps, SRE, and MLOps workflows. The convergence of software and model delivery continues to accelerate (TechRadar). Pulumi’s code-based approach, combined with Neo’s agentic reasoning, creates a unified workflow for infrastructure, applications, and AI systems.

Additional insights and demonstrations:

Kubernetes and Pulumi Neo together represent a future of autonomous infrastructure management, where AI assists teams in deploying, maintaining, and improving their environments intelligently and securely.

Operator-First: Kubernetes Deploys Your Cloud

The Pulumi Kubernetes Operator 2.0 GA introduced a Kubernetes-native approach to infrastructure management. Each Pulumi stack becomes a Kubernetes Custom Resource, allowing Kubernetes itself to execute Pulumi programs written in any supported language. This enables:

Management of AWS, Azure, and GCP infrastructure from within the cluster
Integration with GitOps systems such as Argo CD and Flux
Continuous reconciliation and drift detection through Pulumi’s state and policy engine

With the new Pulumi Kubernetes Operator 2.3, the operator gets even more production-ready features:

Faster and more resilient stack updates through improved workspace lifecycle management
Support for multi-namespace and multi-tenant deployments
Better visibility with enhanced events, status reporting, and error surfacing
Performance improvements for large-scale environments and parallel stack operations

Documentation: Using the Pulumi Kubernetes Operator

Kubernetes beyond YAML

Define clusters, workloads, and policies in TypeScript, Python, or Go, and manage EKS, AKS, and GKE from a single code-first workflow.

Get started

Intelligent Infrastructure Across Every Cloud

Kubernetes has become the control plane for everything from application deployments to AI and ML workloads across clouds and environments. Engineering teams are running clusters on Amazon EKS, Microsoft AKS, and Google GKE while also managing edge, hybrid, and on-premises environments. Pulumi extends Kubernetes automation across all of them, unifying clusters, workloads, and cloud resources under a consistent model of infrastructure as code.

With Pulumi, teams can use familiar programming languages to define Kubernetes resources, cloud infrastructure, and policies together. This approach provides a single workflow for managing compute, networking, storage, and identity across multiple clouds without relying on brittle YAML templates. It enables consistent provisioning, policy enforcement, and automation across every cluster and environment.

By treating Kubernetes as the universal control plane for cloud infrastructure, Pulumi gives teams a scalable foundation that adapts to any workload and environment. The result is an intelligent, multi-cloud Kubernetes infrastructure that combines the flexibility of cloud providers with the reliability of modern automation.

Bring Your YAML and Helm, Then Evolve

Teams do not need to start from scratch. Pulumi supports importing existing YAML manifests and Helm charts to help organizations adopt a code-first approach incrementally. Many teams begin by wrapping existing manifests in Pulumi code, then refactor them into reusable components that enforce best practices and compliance policies.

This hybrid approach enables modernization without disrupting existing CI/CD pipelines or team workflows.

Begin Your Kubernetes Automation Journey

For teams preparing for the next phase of Kubernetes management in 2026:

Get Started with Kubernetes to create your first Pulumi program.
Add the Pulumi Kubernetes Operator to enable infrastructure deployments from within your clusters.
Integrate GitOps workflows with Argo CD, Flux, or Jenkins X.
Apply policy guardrails to enforce security and compliance automatically.
Refactor infrastructure into reusable components for consistent, scalable operations.

Agentic Workflows for Production-ready Kubernetes

Experience Kubernetes automation in practice. See how agentic workflows power production-ready Kubernetes by automating GitOps operations, managing environments, and reducing manual effort in this on-demand workshop.

Watch Agentic Workflows for Production-ready Kubernetes to learn how to:

Provision and manage clusters across clouds using general-purpose programming languages
Multi-cloud Kubernetes infrastructure management
Fleet management with GitOps (Argo CD)
Reduce YAML complexity while maintaining reliability and speed

Watch On Demand.

Final Thoughts

Kubernetes in 2026 and beyond is not just for platform engineers. It is for DevOps professionals, SREs, and cloud teams, big and small, responsible for maintaining infrastructure security, reliability, and performance. Pulumi unifies infrastructure as code, secrets management, policy governance, and AI automation into a single platform, enabling every team to adopt an intelligent, code-driven approach to Kubernetes that scales across workloads, clouds, and the AI-driven future.

Try Pulumi for Free

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Craig Symonds — Wed, 05 Nov 2025 00:05:00 +0000

The era of AI-accelerated development has created a paradox: the faster developers move, the bigger the governance challenge becomes. For years, security and platform teams have worked to “shift left,” but the tools available have been incomplete. Most focus on detection, which is necessary but not sufficient. They identify thousands of policy violations across an organization’s infrastructure but leave teams with an overwhelming backlog and no scalable way to remediate it. This creates a persistent gap between finding a problem and fixing it. The result is an impossible choice between development velocity and organizational control, forcing leadership to slow down innovation to manage risk.

Today, we end that compromise.

We are thrilled to announce the next generation of Pulumi Policies, a comprehensive governance solution that moves beyond detection to deliver AI-powered remediation at scale. We’re introducing a new lifecycle to secure your cloud: first, Get Clean by using AI to fix your existing policy violations. Second, Stay Clean by using policy as a universal guardrail that makes AI-driven development not just fast, but fundamentally safe. These are not strictly sequential steps; you can begin enforcing “Stay Clean” policies for all new infrastructure while you simultaneously work on the “Get Clean” process for your existing footprint.

Watch our Launch Video:

Part 1: Get Clean - From Thousands of Issues to a Compliant State

The first step to a secure cloud is tackling the mountain of existing misconfigurations spread across your environments.

First, Gain Complete Visibility with the New Policy Findings Hub

To fix your issues, you first need to see them clearly. We have introduced a powerful Policy Findings Hub designed to give every stakeholder the exact view they need.

The Overview Tab: A high-level dashboard with compliance scores for leadership to track trends and measure your organization’s posture.
The Compliance Tab: A control-centric view for auditors and infosec teams, grouping findings by policy (e.g., CIS, NIST) to simplify evidence gathering and prove compliance.
The Issues Tab: A collaborative workspace for platform and development teams to triage, assign, prioritize, and track the remediation of every policy issue.

This hub is powered by our flexible audit capabilities. With Audit Scans for IaC Stacks, you can get an instant compliance baseline on all your existing Pulumi-managed infrastructure without blocking developers or re-deploying thousands of stacks. This is combined with discovery scans of your cloud accounts to give you a single, unified view of every resource, whether managed by Pulumi or not.

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Visibility creates a new problem: an overwhelming backlog. Manually fixing thousands of issues is an impossible task.

This is where Pulumi Neo provides a powerful solution.

Pulumi Neo, our AI platform engineer, is now integrated directly into the Policy Findings hub to automate the most difficult part of the process: the fix itself. From the Issues tab, your teams can now select a group of policy issues, assign them to Neo, and trigger a remediation flow.

Neo is smart. It will:

Analyze the non-compliant resources and the policies they are violating.
Understand the required configuration to make them compliant.
Generate a pull request with the exact code changes needed to fix the issues.

Most powerfully, for an unmanaged resource discovered via a cloud scan, Neo will generate the code to import the resource into a Pulumi stack and apply the fix. This “Import and Fix” workflow transforms unmanaged infrastructure into governed, compliant code, turning a task that could take a developer hours into a simple review-and-merge process. Your teams can finally burn down their issue backlog and achieve a state of continuous compliance.

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

Once you begin cleaning your environment, the next challenge is to stay clean. As AI accelerates infrastructure creation, you need robust guardrails to ensure it doesn’t also accelerate the creation of security risks.

The answer is Policy as Real Code. Pulumi Policies uses general-purpose languages like TypeScript and Python to create sophisticated guardrails that govern every change. To help you establish these controls immediately, we are launching a new suite of pre-built compliance packs authored and maintained by Pulumi experts.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

These policies act as a universal guardrail for your entire organization by blocking non-compliant changes during pulumi up, before they are ever created. Learn more about our compliance packs.

And now, you can even use Neo to author new policies. You can ask Neo in plain English to “create a policy that prevents overly permissive IAM roles,” and it will generate the code for you. This creates a powerful, dynamic governance system where AI can help you build the very rules that then govern its own actions. If you then ask Neo to create an admin role, the deployment will be blocked by the policy it just helped write. This is how we make AI safe to go fast.

A New Era of Collaboration

This “Get Clean, Stay Clean” lifecycle transforms how teams work together:

Platform Teams lead prevention by building real-code guardrails, proving their value with measurable compliance scores.
Security Teams drive the “Get Clean” process with continuous, non-blocking audit scans and use the Findings hub to manage compliance without slowing development.

Governance That Accelerates You

The age of AI-driven development demands AI-powered governance. With this new generation of Pulumi Policies, we are providing the essential infrastructure for platform engineering teams to not just survive, but thrive. You can finally build preventative guardrails that developers love, secure your cloud at scale, and transform governance from a blocker into a business accelerator. Learn more about Pulumi Insights & Governance capabilities.

This powerful new experience is available today. Navigate to the Policies and Policy Findings tab in Pulumi Cloud to explore your new governance capabilities and meet the future of platform engineering.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to set up and apply a policy group to stacks and clouds.
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Policy Findings Hub: Move From Alert Fatigue to Action

Alejandro Cotroneo — Wed, 05 Nov 2025 00:03:00 +0000

For platform and security teams, enabling robust cloud scanning often creates a new problem: an unmanageable firehose of policy alerts. Identifying a violation is only the first step. Without a system to manage the lifecycle of these findings, teams are quickly overwhelmed, leading to prioritization paralysis and a perpetually growing backlog.

The Policy Findings hub in Pulumi Cloud is the solution to this alert fatigue. It’s a purpose-built, collaborative workspace that turns a noisy list of violations into organized, actionable tasks. The hub brings clarity and structure to the compliance process, guiding teams from initial discovery to a verified fix.

From Raw Data to Actionable Insights

The Policy Findings hub is designed with distinct views for every stakeholder involved in the governance lifecycle.

1. The Overview Tab: A Dashboard for Leaders

For a platform lead or security manager, the goal is to understand the big picture. The Overview tab provides a high-level dashboard of your organization’s compliance health, answering key questions at a glance:

What is our overall resource compliance score?
Are we trending in the right direction?
Which parts of our cloud infrastructure (stacks, accounts, etc.) carry the most risk?

This view helps leadership track progress and make data-driven decisions about where to focus engineering efforts.

2. The Compliance Tab: The Auditor and Infosec Workspace

For the infosec members and auditors, context is everything. Simply listing thousands of violations is not helpful. The Compliance tab provides a policy-centric view, grouping all findings by the specific control they violated (e.g., a specific rule within CIS or NIST).

This is crucial when preparing for an audit or assessing adherence to a specific security framework, as it allows you to see exactly where you are compliant and where you have gaps, control by control.

3. The Issues Tab: The Team’s Daily Workspace

This is the space where insight is turned into action. The Issues tab is a collaborative triage board designed for the day-to-day workflow of platform and development teams. It provides the full toolset needed to manage the lifecycle of an issue from start to finish:

Triage and Prioritize: Filter issues by severity, resource type, or policy to focus on what matters most. Set a priority level from P0 (critical) to P4 (low).
Assign Ownership: Assign issues to specific team members to ensure clear ownership and accountability.
Manage Lifecycle: Mark an issue as “Ignored” with a justification. This is a critical workflow for acknowledging intentional exceptions, which cleans up your dashboard and allows the team to focus on legitimate issues.

And for the most critical part of the workflow — the fix itself — we’ve integrated our AI agent, Pulumi Neo, directly into this view.

After selecting one or more issues, your team can assign the task to Neo. It will analyze the violations and automatically generate a pull request with the necessary code changes. For unmanaged resources, Neo will even generate the code to import them into Pulumi and apply the fix. This turns a complex manual task into a simple review-and-merge process, allowing your team to finally burn down the backlog.

Turning Alerts into Action

Effective governance goes beyond identifying violations. It requires a structured system that turns every finding into a clear and trackable path to resolution. The new Policy Findings hub provides that end-to-end workflow, from visibility to accountability to automated remediation.

By organizing policy data into meaningful views and integrating Pulumi Neo directly into the issue management process, teams can move past alert fatigue and focus on what matters most: fixing problems quickly and maintaining continuous compliance.

This new experience is now available. Navigate to the Policies > Findings tab in the Pulumi Cloud to explore your new compliance dashboard and start turning alerts into action.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to manage compliance across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Grounded AI: Why Neo Knows Your Infrastructure

Engin Diri — Fri, 24 Oct 2025 00:00:00 +0000

Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice. Ask Pulumi Neo the same question, and you’ll get a fix plan grounded in your actual infrastructure state.

The difference isn’t about better prompts or newer models. It’s about what the AI actually knows. Generic LLMs have been trained on the internet. Neo has been trained on your infrastructure.

This distinction matters more than you’d think.

The grounding problem

Most AI tools treat infrastructure like a text generation problem. You describe what you want, the model produces code, and you hope it works.

This approach fails more often than it succeeds because the AI has no connection to your actual infrastructure. It doesn’t know what resources you’ve already deployed, what dependencies exist, or what policies you need to follow. It’s generating code from patterns it learned on the internet, not from understanding your environment.

Pulumi Neo takes a different approach. It’s trained on your infrastructure context: your programs, your state, your resource relationships. When you ask Neo about drift, it doesn’t guess. It queries your actual deployment history. When it suggests a fix, it reasons from your program graph, not generic examples.

Neo doesn’t just autocomplete code. It understands state, resources, dependencies, and cloud behavior. When something fails, Neo explains why, not just what.

This is what makes it grounded AI: it’s anchored to the reality of your infrastructure, not floating in a sea of internet-trained probabilities.

What makes Neo different

The foundation matters more than you’d think.

Traditional AI tools fail in DevOps because they operate in a vacuum. Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice that ignores your specific infrastructure, your state, your constraints.

The difference with systems like Pulumi Neo comes down to what powers them: not just data, but context.

Think of it this way: a data lake is a massive repository of information sitting inert, waiting to be queried. A context lake is something else entirely. It’s a structured repository that aggregates knowledge about your domain and feeds it to AI systems.

A context lake contains things that matter:

Your infrastructure programs, resource definitions, API schemas, service dependencies. In Pulumi’s case, this includes your program graph, component models, stack configurations.

Real-time metrics, deployment history, drift detection, policy violations. The live pulse of your infrastructure as it actually runs in production.

Ownership information, compliance policies, access controls, quality signals. The organizational context that determines what changes are safe, who can make them, and why they matter.

Pulumi’s approach builds on this principle. Your infrastructure programs, state files, resource metadata, policy definitions. All of this becomes queryable context. Neo doesn’t hallucinate solutions because it’s grounded in your actual infrastructure. It knows what you’ve deployed, how resources relate to each other, what dependencies exist, what’s drifted.

This is the architectural shift that makes AI-powered DevOps actually work. AI agents are only as effective as the context they can access and the guardrails you have in place to keep them in check. You’re not just automating actions anymore. You’re automating understanding.

Grounded reasoning in practice

Early DevOps automated actions. Modern AI agents automate decisions. But grounded AI does something different: it automates understanding.

When you combine observability data, infrastructure-as-code programs, and deployment history into a context lake, the AI doesn’t just predict what might happen. It reasons about what is happening based on your actual infrastructure state.

Neo can watch infrastructure drift, identify whether it stems from a manual change or a misconfigured resource, and generate a fix plan that maps back to your Pulumi program. That feedback isn’t guesswork. It’s grounded in the same infrastructure metadata developers already use. The context lake ensures Neo isn’t making probabilistic predictions. It’s reasoning from your specific infrastructure truth.

This is what separates grounded AI from generic LLMs. Neo doesn’t just automate deployment. It understands the intent behind it.

The human layer stays critical

Grounded AI doesn’t replace engineering judgment. Every engineer who’s tried to prompt a generic LLM to “write a Pulumi program for me” knows how quickly hallucinations creep in. You still need human context: the judgment to choose the right platform, the discipline to model dependencies, the awareness of compliance and cost.

That’s where grounded AI like Neo fits best. It’s not a chatbot for infrastructure. It’s an extension of your own reasoning.

Neo learns from the same program graph and state data you already manage, drawing from a continuously updated context lake of your infrastructure reality. Its recommendations stay grounded in your environment, not floating in a generic prompt window trained on the public internet.

The opportunity isn’t about replacing engineers. It’s about creating smarter feedback loops between human expertise and AI that actually understands your infrastructure.

What grounded AI enables

The first generation of DevOps automated deployment. Grounded AI automates understanding.

Infrastructure becomes queryable. AI-powered observability correlates incidents before they cascade. CI/CD becomes continuous reasoning rather than continuous execution. Platform teams spend less time fighting YAML and more time guiding systems that reason alongside them.

The context lake architecture makes this possible. Instead of static documentation and scattered tribal knowledge, your infrastructure context becomes something AI agents can actually query and reason over.

Grounded AI won’t replace engineers. But it will change what engineering means: less time translating intent into YAML, more time reasoning about systems at a higher level.

Try it yourself

Want to see what infrastructure cognition looks like in practice? Get started with Neo and ask it about your infrastructure. Watch it reason through drift detection, generate fix plans, or explain complex resource relationships in plain English. For a wider survey of the category, see our guide to the best AI infrastructure tools.

Neo is available today for teams using Pulumi Cloud. The cognitive layer isn’t coming. It’s already here.

Neo Gets Smarter: New Modes, CLI Access & Sonnet 4.5

Pulumi Neo Team — Mon, 20 Oct 2025 00:00:00 +0000

Neo just got significantly more capable. We’ve shipped three major updates: Operating Modes for flexible control, full ecosystem tool access, and Claude Sonnet 4.5 for better performance on complex infrastructure tasks.

You decide how much control you keep

The same action has different risks in different contexts. Building a new dev environment is low risk. Opening a PR that changes shared infrastructure requires more scrutiny.

Operating Modes let you adjust autonomy based on context:

Review Mode: You approve the task plan, preview, and PR. You see everything before it happens.
Balanced Mode: Neo handles planning and previews. You approve mutating operations, such as updates or destroys. Less friction, control where it matters.
Auto Mode: Neo runs without stopping. For when you need speed and trust the outcome.

You can use Review Mode when Neo is updating production infrastructure. Use Balanced Mode when deploying application updates where you want to verify destructive changes but trust routine operations. Switch to Auto Mode when spinning up temporary dev environments for testing. You pick the mode that matches your situation. The same agent, flexible levels of autonomy.

Neo can do more

Neo now has access to more tools and information. This means it can handle more complex scenarios and work with the broader ecosystem your infrastructure depends on.

Full Pulumi CLI access: Neo can now run all Pulumi CLI operations, including stack imports, state management, and plugin operations that previously required manual intervention.
Ecosystem tooling built in: Neo now includes kubectl, Helm, AWS CLI, GCP, and Oracle Cloud CLI. This means Neo can verify Kubernetes deployments, install Helm charts, and run cloud-specific operations without leaving your workflow.
Private registry search: Your team builds reusable components to accelerate development and codify standards. Neo can now search your organization’s private registry, including READMEs, to find and use them. You get the benefit of your team’s existing work.

Sonnet 4.5

Neo now runs on Anthropic’s Sonnet 4.5 by default. Sonnet 4.5 delivers better performance on complex, multi-step infrastructure tasks that require sustained reasoning across multiple files and services.

Try Neo

Ready to try these features?

Sign in to Pulumi Cloud and start a Neo task
Read the Neo documentation for detailed guides
Join the Community Slack to share feedback on the new features

10 Things You Can Do With Our Infrastructure Agent, Neo

Meagan Cojocar — Mon, 06 Oct 2025 00:00:00 +0000

Since launching Pulumi Neo two weeks ago, we’ve seen platform teams discover creative ways to put their newest AI teammate to work. We have also been using Neo internally for a handful of use cases. Neo shifts the conversation from “what could AI do for infrastructure?” to “what can I actually accomplish with Neo today?”

The answer is quite a bit. Here are 10 concrete workflows that platform teams can use Neo for right now, each one designed to save hours of manual work while keeping humans in the driver seat.

1. Explain infrastructure in plain English or diagrams

Neo answers questions about your infrastructure instantly, turning complex resource relationships into conversational insights (and diagrams!).

No more digging through AWS consoles or parsing state files to understand what you have deployed. Neo speaks your language about your infrastructure. Ask questions like “What databases do we have?”, “Which S3 buckets aren’t encrypted?”, “Show me all resources in us-east-1” or “draw an architecture diagram of our service” and get immediate, accurate answers.

2. Generate infrastructure code from natural language

Neo turns plain English descriptions into production-ready Pulumi code, eliminating the blank-page problem that slows down new projects.

Instead of starting from scratch or hunting through documentation, describe what you need and Neo generates the complete infrastructure. Ask Neo: “Create a serverless API with PostgreSQL database and Redis cache on AWS” and it produces fully configured resources with proper networking, security groups, and IAM policies.

3. Assist with Terraform to Pulumi migration

Neo analyzes existing Terraform code (and/or state files) and generates equivalent Pulumi programs, accelerating migration without starting from scratch.

Migrating from Terraform to Pulumi traditionally means rewriting everything. Neo understands both languages and can convert HCL to TypeScript, Python, or Go while preserving your infrastructure patterns. You can also use the Terraform state file. Ask Neo: “Analyze the provided terraform state. Based on it, generate a python pulumi program that imports the resources without requiring updates.” and it generates equivalent code with proper typing and best practices.

Using this prompt with a Terraform state file containing EC2 instances and supporting resources, Neo generated a complete Pulumi program that imported everything without requiring updates:

4. Automate CI/CD pipeline generation

Neo creates complete GitHub Actions workflows configured specifically for Pulumi deployments, with proper preview stages.

Setting up CI/CD for infrastructure projects usually involves copying workflows from other repos and adapting them. Neo generates purpose-built pipelines that understand your stack structure and deployment patterns. Ask Neo: “Create a GitHub Actions pipeline for this Pulumi project with preview and production stages” and it produces workflows with proper secrets management, approval gates, and deployment strategies.

Here is what Neo gives us using that prompt on a very basic Pulumi project:

name: Simple Pulumi Deploy

on:
 push:
 branches: [main]
 workflow_dispatch:

env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Install Pulumi
 uses: pulumi/actions@v4
 with:
 pulumi-version: latest

 - name: Configure AWS credentials
 uses: aws-actions/configure-aws-credentials@v4
 with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: us-west-2

 - name: Deploy infrastructure
 run: |
 pulumi stack select production
 pulumi up --yes
 working-directory: ./infrastructure

5. Identify inefficient infrastructure patterns

Neo analyzes your infrastructure and spots patterns that create unnecessary management overhead, helping you consolidate and optimize.

When you have 10 identical EC2 instances that should be an auto-scaling group, or multiple Lambda functions doing the same job, Neo spots these patterns. Ask Neo: “Analyze our infrastructure for inefficient patterns” and it can identify consolidation opportunities.

Example analysis:

Neo identified these optimization opportunities:

1. Duplicate EC2 Instances (High Priority)
 • Found 8 identical t3.medium instances running the same application
 • Recommendation: Consolidate into an Auto Scaling Group
 • Benefits: Simplified management, automatic scaling, reduced configuration drift

2. Scattered Lambda Functions (Medium Priority)
 • Found 12 Lambda functions with identical runtime and dependencies
 • Recommendation: Combine into a single function with routing logic
 • Benefits: Reduced cold starts, simplified monitoring, easier updates

3. Redundant Security Groups (Low Priority)
 • Found 15 security groups with identical rules
 • Recommendation: Create shared security groups for common patterns
 • Benefits: Easier rule management, reduced complexity

6. Upgrade EKS/Kubernetes clusters

Neo manages Kubernetes version upgrades across multiple clusters, planning upgrade paths and validating compatibility.

Kubernetes upgrades are complex, especially across multiple clusters with different workloads. Neo analyzes your cluster configurations, identifies upgrade blockers, and creates systematic upgrade plans. Ask Neo: “Plan an upgrade path for our EKS clusters from 1.27 to 1.28” and it maps dependencies, checks add-on compatibility, and sequences the upgrades.

7. Respond to security vulnerabilities

When CVEs are announced, Neo can help security teams move at machine speed addressing them.

Security vulnerabilities require immediate response across your entire infrastructure. Neo understands your resource inventory and can quickly identify what’s affected by new CVEs. When you ask Neo: “Identify all resources affected by CVE-2025-XXXXX and create remediation PRs”, it scans your infrastructure, maps vulnerable components, and generates targeted fixes.

8. Remediate policy violations

Neo detects non-compliant resources and generates pull requests to fix them, turning compliance headaches into automated workflows.

When your policy violations detect unencrypted EBS volumes, overly permissive security groups, or missing resource tags, Neo identifies the issues and proposes specific fixes. Ask Neo: “Fix all policy violations in our production account” and it analyzes your compliance dashboard, identifies the problematic resources, and creates PRs with the exact changes needed.

9. Update Lambda runtimes across multiple accounts

Neo identifies outdated Lambda runtimes, stages updates, and manages the rollout across your entire AWS organization.

When AWS announces runtime deprecations, Neo scans all your accounts, identifies functions running outdated versions, and creates a systematic upgrade plan. Ask Neo: “Upgrade all Lambda functions to Python 3.11” and it maps your functions, checks compatibility, and generates account-by-account PRs.

Before (outdated runtime):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d8, // ❌ Deprecated
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

After (Neo’s upgrade):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d11, // ✅ Upgraded
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

10. Enforce multi-account policy compliance

Neo applies organizational policies across your entire AWS Organizations structure, ensuring governance at scale without creating bottlenecks.

Large organizations struggle to maintain consistent policies across dozens of AWS accounts. Neo understands your organizational structure and can enforce tagging standards, encryption requirements, and security policies uniformly. Ask Neo: “Ensure all accounts follow our tagging and encryption policies” and it audits compliance across your organization.

Your newest platform engineer

These workflows represent just the beginning of what’s possible when an AI agent deeply understands infrastructure context.

The outcome is simple: spend less time on operational toil and more time on the architecture and policies that make your organizations successful.

Get started with Neo and discover what becomes possible when AI truly understands infrastructure.

The future of platform engineering isn’t about choosing between speed and safety. It’s about having tools that help you with both simultaneously.

Policy Comes to Team and Enterprise, with New Out-of-the-box Policies and Management Experience

Luke Ward — Wed, 17 Sep 2025 00:00:00 +0000

Pulumi’s Infrastructure as Code has included a powerful policy engine from day one. Over the past year, we’ve been enhancing it significantly to provide stronger governance for modern cloud platforms. Until now, these capabilities were limited to our Business Critical tier. Today, we’re excited to announce that policy guardrails are now available to all Team and Enterprise customers. Alongside this, we’re launching a redesigned policy management experience and introducing out-of-the-box policy packs that make it easier than ever to secure, govern, and optimize your cloud environments—even when powered by AI agents like Pulumi Neo.

Policy as Guardrails for AI Infrastructure

As developer velocity accelerates, AI agents like Neo are helping teams create and manage infrastructure at unprecedented speed. That speed creates a governance challenge: how do you ensure security, compliance, and cost-effectiveness without slowing developers down?

Policy guardrails provide the answer. Pulumi’s Policy as Code (PaC) framework applies DevOps best practices to governance, letting you codify rules, test them through pull requests, and version them alongside your infrastructure. With policies in place, you can ensure that every change stays within your organization’s standards, whether it is a human developer or Neo making a change.

What Makes Pulumi Policy Different

Unlike many other policy solutions, Pulumi Policy uses general-purpose programming languages such as TypeScript and Python rather than restrictive DSLs or YAML. This unlocks richer and more flexible capabilities, including:

Conditional logic to codify your organization’s nuanced rules.
Reusable functions and abstractions to create a shared library of policies.
Unit tests to validate policy behavior before rollout.

With today’s updates, this foundation is easier to adopt and scale across your teams than ever before.

New Simplified Experience

While Pulumi Policy has always allowed you to enforce compliance using TypeScript and Python, the existing workflow could be cumbersome—discovering policies required switching between the console and CLI, and applying them involved multiple steps.

We’ve removed that friction to provide the seamless guardrails needed for this high-velocity, AI-driven world. The new experience is built around a streamlined, in-console workflow for discovering, applying, and managing your policies.

In-Console Discoverability

We are making it easier to find and understand policy packs. You can now browse a rich set of pre-built policy packs directly within the Pulumi Cloud console—no CLI or context switching required.

You’ll find:

A rich browsing experience: See all available policy packs in one place.
Detailed information: Each pack comes with a clear description of the policies included.
Organization-approved packs: Org admins can curate a list of approved policy packs, ensuring your teams—and AI agents like Neo—are using a vetted set of policies.

New Pre-Built Policy Packs

To help you establish guardrails immediately, we have authored several pre-built policy packs. We are excited to highlight two that are available today:

Pulumi Best Practices: A foundational set of recommended governance and security controls that serves as a strong starting point for any organization.
HITRUST CSF v11.5: Provides predefined controls that help align cloud resources with HITRUST CSF requirements.

Streamlined Policy Management and Application

The new policy management experience dramatically simplifies policy application:

Intuitive Interface: Browse, select, and apply policies through a streamlined workflow using Policy Groups to bundle related policies and apply them to your stacks or cloud accounts.
Expanded Scale: We’ve eliminated the 4,000 stack UI limit on policy groups, allowing you to scale policies across your entire infrastructure.
Granular Enforcement: Configure the enforcement level (advisory or mandatory) for policies to either warn developers or block non-compliant deployments entirely.

Preventative and Audit Approaches

Pulumi Policy supports two complementary approaches to governance.

Preventative policies: Block non-compliant deployments during pulumi up, providing real-time guardrails for developers and AI agents.
Audit policies: Continuously scan existing resources for ongoing compliance monitoring, giving you a complete picture of your cloud security posture.

This dual approach ensures new deployments meet standards while maintaining visibility across your entire infrastructure. Learn more in our Preventative vs. Audit Policies guide.

How to Get Started

Getting started with the new policy management experience is straightforward:

Browse Policy Packs: Navigate to the Policies tab in your Pulumi Cloud console to discover pre-built policy packs like Pulumi Best Practices and HITRUST CSF. Learn more about Policy as Code configuration and setup.
Choose Your Approach: Decide whether you need preventative policies (to block non-compliant deployments during pulumi up) or audit policies (for continuous compliance monitoring across all cloud resources).
Create Policy Groups: Set up policy groups to bundle related policies and apply them to your stacks or cloud accounts.
Configure Enforcement: Set enforcement levels (advisory, mandatory, or remediate) for each policy based on your requirements.

Now Available To Team and Enterprise Customers

To ensure every organization can build with confidence, these policy management enhancements and the pulumi-best-practices policy packs are now available to Team and Enterprise customers. Checkout our pricing page for more information.

Conclusion

Governance doesn’t need to be a roadblock—it can be a foundation that accelerates innovation. With enhanced policy management and ready-to-use guardrails, Pulumi helps your teams and AI agents like Neo move fast while staying secure, compliant, and cost effective.

Try the new experience in Pulumi Cloud today, and let us know what you think in the Pulumi Community Slack.

Meet Neo, Your Newest Platform Engineer

Pulumi Neo Team — Tue, 16 Sep 2025 07:00:00 -0600

AI coding assistants have transformed the speed at which developers can write and deploy code. Pull request velocity has increased significantly. Feature delivery has accelerated beyond what we thought possible just two years ago. This should be a victory for everyone in the software organization.

Instead, it’s created significant challenges for infrastructure and platform teams.

Every line of code that ships faster creates new platform needs: monitoring, secrets management, deployment pipelines, and compliance checks. The rapid pace also increases the risk of insecure or non-compliant code reaching production. Developer velocity has increased dramatically, but platform teams haven’t scaled to match.

Platform teams are struggling because they lack the proper tools for their unique challenges. They’re caught in a velocity trap where generic AI accelerates developers while leaving platform teams behind. We’re optimizing software development speed while creating global infrastructure debt.

The very success of developer AI has become a challenge for the platform team.

Introducing Pulumi Neo

Neo is a purpose-built infrastructure automation agent that amplifies your platform engineering capabilities. Built on Pulumi’s platform, Neo has a deep understanding of cloud context, IaC, secrets and configuration, internal developer platforms, and more. It automatically respects your security and policy guardrails and works in tandem with human-in-the-loop approvals and controls.

For years, we’ve worked closely with platform and infrastructure teams. We’ve observed how the demands on these teams have intensified as development velocity has increased. We understand the challenges they face in keeping pace with rapidly evolving infrastructure needs.

The pattern became clear. Generic AI tools excel at generating code but lack the context to understand the unique challenges of infrastructure, including state management, tracking dependencies across services, scaling across tens to hundreds of repositories, and anticipating the effects of changes across an organization.

We’ve heard countless stories from platform engineers about spending hours tracking down dependencies, credential locations, and configuration relationships across their systems. When they try to use generic AI tools for these tasks, the tools often suggest changes without understanding the broader organizational context and dependencies.

That’s when we realized: Platform engineers don’t need faster AI tools. They need their own dedicated AI tool, one that understands infrastructure context, speaks their language, and works within their constraints.

These insights led us to develop Neo, an AI agent specifically designed for platform and infrastructure engineering teams. Unlike generic coding assistants, Neo understands the full context of infrastructure: it knows that changes span multiple repositories, that every modification has downstream effects, and that compliance and security policies matter as much as the code itself.

Built for Enterprise Trust

Neo represents a fundamentally different approach to AI in infrastructure. We view the Pulumi platform’s existing features, like IaC, ESC, and policies, as the foundation for trustworthy AI automation. These aren’t additional guardrails we’ve added; they’re the very platform capabilities you’re already using. Understanding the impact scope through your infrastructure graph gives you confidence to move faster. Knowing compliance implications through your existing policies before making changes is what actually accelerates platform teams.

While other solutions retrofit generic AI models with infrastructure plugins, Neo is built from the ground up on proven enterprise foundations. It operates within your existing Pulumi governance frameworks, respects your policies, and maintains the audit trails and compliance controls your organization requires. Your investment in Pulumi’s platform features—the same ones that govern your infrastructure today—becomes Neo’s operational guardrails.

This isn’t experimental AI, it’s enterprise-ready automation that amplifies your expertise while working within the same platform controls that keep your infrastructure secure and compliant. The Pulumi features you rely on for governance become the accelerants that enable confident, rapid automation.

The Reinforcement Cycle

Neo becomes more capable the more you invest in infrastructure as code. Every Pulumi component you write, every policy you define, every environment configuration you establish becomes Neo’s operational context that guides its decisions.

This is the key shift. We’re talking about AI amplifying platform expertise. The engineers who understand the why behind infrastructure decisions become even more valuable when they have tools that can execute the how at scale.

The teams that lean into this cycle will find themselves accelerating while others are still struggling. They’ll be writing policies while others are responding to issues. They’ll be designing systems while others are updating versions.

The Platform Engineering Evolution

The bigger picture extends far beyond task automation. Platform engineering evolves from reactive to proactive. Teams shift from ticket takers to strategic enablers. Infrastructure becomes self-healing and self-documenting. The profession transforms from responding to urgent issues to crafting foundations.

Imagine infrastructure that evolves as fast as the code it supports. Imagine platform teams that can actually think about next quarter instead of just surviving next sprint. Imagine organizations that can sustain AI-driven development velocity because their infrastructure keeps pace automatically.

For the industry, this means the end of the “platform team bottleneck” narrative. No longer will infrastructure be the reason features don’t ship. No longer will platform engineers be seen as blockers in the velocity story. Instead, they’ll be the enablers who made sustainable speed possible.

This is the rise of strategic platform engineering. These are professionals who shape how organizations build and operate software, who establish the foundations that make everything else possible, and who finally have tools that match the complexity and importance of their work.

The Choice Before Us

What we’re launching is more than an AI agent. We’re introducing your newest platform engineer, who gets smarter as your infrastructure evolves. We’re launching a new era for platform engineering, one where the teams that enable everyone else finally have tools built specifically for their reality.

Neo represents our belief that platform engineers shouldn’t have to choose between speed and safety, between automation and control, between serving developers and driving strategy. These are false choices created by tools that lack an understanding of infrastructure.

The age of generic AI taught us what’s possible. The era of specialized AI shows us what’s practical. Platform teams have been overloaded by everyone else’s velocity long enough.

It’s time for platform engineering to keep pace instead of falling behind.

Neo is available today in public preview. Ready to meet your newest platform engineer? Join thousands of teams already transforming their infrastructure workflows with the Pulumi platform.

The future of platform engineering starts now, and it starts with Neo.