Dora NodaWriting code is no longer the bottleneck. The bottleneck is everything that happens after git push — provisioning, policy checks, day-two operations, drift, compliance. No new code assistant will fix it, because it is an architecture problem: AI agents need APIs, not user interfaces, and most platforms still are not built that way.
That is the case CNCF Ambassador Ana Margarita Medina made in “Crossplane and AI: The Case for API-First Infrastructure” in March 2026, and the diagnosis is exactly right. The prescription deserves a second look.
The verdict up front: agents really do need declarative, machine-readable infrastructure — idempotent desired-state writes, observable status, typed errors, discoverable schemas, policy enforced at execution. But the Crossplane-shaped substrate the post prescribes is the wrong way to deliver those properties to an agent operating a PaaS. What an agent can actually hold in context is a small purpose-built API, with the declarative machinery hidden underneath it. Score the two approaches against the five properties agents need and the gap is clear:
| What an agent needs | Crossplane CRD surface | Small PaaS REST/GraphQL API |
|---|---|---|
| Idempotent desired-state writes | Yes — spec/status reconciliation is the whole model | Yes — if the API is designed desired-state-first (deploy this revision, scale to N) |
| Machine-readable status | Yes — status subresources, watch events | Yes — deployment objects with phase, health, events |
| Typed, actionable errors | Partial — provider errors leak cloud-API internals the agent never asked about | Yes — a handful of documented error codes per endpoint |
| Discoverable schema | In theory — in practice hundreds of generated CRDs per provider to wade through | Yes — a dozen endpoints an agent can read in one pass |
| Policy at execution | Yes — RBAC, admission, policy engines, compositions | Yes — enforced server-side on every call, no exception paths |
Everything below is the evidence for that table: what CNCF argued, where the argument holds, where Crossplane itself breaks down as agent substrate, and what the right shape looks like.
What CNCF actually argued
Medina's post starts from an observation anyone running a platform will recognize: in most organizations the desired state lives in Git while the actual state lives in cloud providers, policies are buried in pipeline configs, and organizational knowledge exists in wikis nobody reads and in engineers who eventually leave. That arrangement survived because humans compensated for it — people filled gaps, asked questions, translated intent across systems.
Agents cannot do any of that. An agent hits a wall built of ClickOps consoles, tribal knowledge, and inconsistent state, “not because it lacks capability, but because the platform wasn't built for programmatic access.” The post's central demand is that agents get a unified, structured, machine-readable interface with explicit governance rules, readable history, and discoverable dependencies.
The proposed model is the Kubernetes control pattern extended to everything: desired state in spec, actual state in status, controllers reconciling the difference continuously, policy enforced at execution rather than in ticket queues. Crossplane stretches that pattern past containers to databases, networking, SaaS systems, and whole platform APIs.
Crossplane 2.0 goes further: a single composition can provision infrastructure, deploy the app, configure networking and observability, and define operational workflows in one object. Day-two operations become first-class API objects too — a CronOperation for weekly database maintenance is something an agent can inspect, trigger, observe, and propose modifications to, with no hidden runbook.
The payoff line is worth quoting directly: “Without a control plane, agents become fragile orchestrators. With one, they become declarative participants.” Controllers handle mechanics; agents focus on higher-level reasoning. That framing has only gained momentum since March — in June, Upbound launched Modelplane, an open-source control plane for AI inference fleets built on Crossplane, betting that the same desired-state machinery should run model serving too.
Where the argument holds: the agent wall is real
Every part of the diagnosis survives contact with real agent deployments. Three failure modes show up again and again wherever agents meet human-shaped platforms.
First, ClickOps has no agent equivalent. A dashboard that requires five clicks across three pages to rotate a credential is a minor annoyance for a human and a hard blocker for an agent, which cannot reliably drive a GUI and should never have to. Second, tribal knowledge is invisible to machines. “Ask Priya which cluster the staging database is on” works in a ten-person team and fails completely when the operator is a process with no Slack access. Third, drift defeats planning. An agent that reasons from Git about what should exist, while the cloud quietly contains something else, will generate confident plans against a world that is not there.
The industry is already voting with its feet for the API-first answer. AWS shipped a Cloud Control API MCP server so agents can create, read, update, delete, and list infrastructure through natural language grounded in a real API. Render ships an MCP server exposing tools like listing services, metrics, and logs, plus an open-source bundle of agent skills for operating Render services.
Across the ecosystem, MCP went from a November 2024 release to more than 50 official servers and 150 community implementations by March 2026, and curated DevOps-AI indexes now track hundreds of agent tools and frameworks. The direction is unmistakable: agents operate platforms through structured tool calls, and every platform without a machine-shaped interface is drifting toward unmaintainability by its future operators.
Where Crossplane is the wrong substrate
Here is where the prescription breaks down. Grant every word of the diagnosis — agents need declarative APIs — and Crossplane still fails as the thing the agent touches, for three concrete reasons: provider sprawl, authoring cost, and context economics.
Provider sprawl is operational surface the agent inherits. Crossplane's universality comes from providers: one per infrastructure system, each generating hundreds of CRDs, each needing installation, upgrades, credentials, and debugging. Practitioners consistently report that provider-level errors are the hardest part to troubleshoot — a failed database does not surface as “storage quota exceeded” but as a raw cloud-API error three layers down. An agent operating through that surface must understand not just the platform's intent but the failure modes of every provider in the chain. Graduated status does not erase this: Crossplane graduated from the CNCF in October 2025 with over 3,000 contributors from more than 450 organizations, which proves maturity, not simplicity.
Authoring cost lands on the platform team per abstraction. To offer an agent “deploy my app,” the Crossplane route requires a CompositeResourceDefinition, a Composition wiring infrastructure and app resources together, functions or patches for the dynamic parts, and the providers underneath — each layer its own YAML, its own versioning, its own debugging story. Market analyses note that configuring compositions, providers, and XRDs demands specialized Kubernetes-native expertise most enterprises lack in-house. Compare the alternative: a POST /services endpoint whose handler runs the same provisioning logic in ordinary code, tested like any other code. Both are “API-first.” Only one of them asks the platform team to become Crossplane specialists before an agent can ship a web service.
Context economics decide what agents can use. An agent reasons over what fits in its working context. A Crossplane-backed surface confronts it with provider CRD schemas running to hundreds of fields each, composition logic, and XRD documentation — schema surface that dwarfs the actual task of deploying an app. A purpose-built PaaS API presents a dozen endpoints with typed inputs, typed errors, and one status model. This is not an argument against declarative machinery; it is an argument about where the agent boundary sits. The reconciliation loops can be as sophisticated as you like, as long as the agent never has to read them.
None of this diminishes Crossplane where it fits: large enterprises composing bespoke internal developer platforms across many clouds, where a dedicated platform team amortizes the complexity. Apple, Nike, JPMC, SAP, and the other production users named at Modelplane's launch have exactly that shape. A PaaS an agent operates is a different product with a different reader: one agent, one task, one small contract.
The right shape: declarative underneath, minimal on top
The synthesis keeps CNCF's core and discards the substrate. Run declarative control loops underneath — Kubernetes and Cluster API reconciling machines and workloads toward desired state, GitOps flowing intent down, drift corrected by controllers rather than tickets. But face the agent with a minimal contract it can hold in context in a single pass:
POST /servicesandPOST /deploys— declare what should run, idempotently.GET /deploys/:idandGET /services/:id— one status model: phase, health, events.POST /services/:id/rollbackandPATCH /services/:id/scale— the two day-two verbs agents actually need first.GET /logsandGET /metrics— observable reality, structured, no scraping.- Typed errors on every endpoint — a small documented set, never a leaked cloud stack trace.
This shape already has existence proofs. Render-compatible APIs show that a PaaS surface this small can run real production workloads, and MCP servers like Render's and AWS's show that agents thrive when the tool catalog is a short list of typed operations rather than a schema ocean. MCP is best understood as the adapter layer: it translates the agent's tool calls onto whatever API the platform exposes, which means the platform's job is to keep that API small, typed, and honest about state. Policy still enforces at execution — RBAC and admission on every call, no exception paths — exactly as the CNCF post demands. The agent gets everything Medina asks for: structured, diffable, observable, governed. It just gets it in a dozen endpoints instead of an ocean of generated schema.
Declarative cores, minimal contracts
The arc of 2026 points one way. Crossplane graduated, MCP became the default agent-tool protocol, every major cloud and PaaS started shipping agent-shaped interfaces, and Upbound bet that even inference fleets want a control plane. Medina's line stands: AI needs APIs, not UIs, and autonomy stalls without structure.
The refinement is about which API the agent sees. Declarative reconciliation is the right machinery; a universal CRD surface is the wrong window into it for an operator with a finite context window and no patience for provider internals. The platforms agents will run best are the ones with declarative cores and minimal contracts — desired state all the way down, twelve endpoints all the way up.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API surface agents can operate today. Star the repo on GitHub or deploy your first app today.
