Crossplane & AI: The Case for API-First Infrastructure
AI-assisted development has changed the way engineers create and commit code. But writing code is no longer the bottleneck. The bottleneck is everything that happens after git push.
From infrastructure provisioning, policy enforcement, day-two operations, drift, compliance, to cross-team coordination. That still requires multiple steps, and no new tool will fix it. This is an architecture problem. AI needs APIs, not UIs, and most platforms still aren't built that way.
Current Platforms
Talk to almost any organization, and you'll hear that the desired state lives in Git, while the actual state lives in cloud providers. Policies are buried in pipeline configs. Organizational knowledge exists in wikis no one reads and in engineers who eventually leave.
This has worked up to now because humans worked with humans to navigate the context switching and informal coordination required to get the job done. People fill in the gaps, ask the questions, and translate intent across systems.
But in a world where AI agents are embedded into our organizations, this workflow breaks down. The agent hits a wall, not because it lacks capability, but because the platform wasn't built for programmatic access. It was built for humans who can compensate for inconsistency.
Agents require a unified, structured, machine-readable interface. They need explicit governance rules, readable historical patterns, and discoverable dependencies. Without that structure, autonomy stalls.
Platforms Built on Declarative Control
Kubernetes introduced a simple but powerful control pattern that changes this entirely. Every resource follows a consistent schema:
apiVersion: example.crossplane.io/v1
kind: Database
metadata:
name: user-db
spec:
engine: postgres
storage: 100GiDesired state lives in spec, actual state is reflected in status, and controllers observe the difference and reconcile continuously. That reconciliation is consistent and automatic; no human is required to coordinate convergence.
Crossplane extends this model beyond containers to all infrastructure and applications: cloud databases, object storage, networking, SaaS systems, clusters, and custom platform APIs. The result isn't just infrastructure-as-code. It's your entire platform, infrastructure, and applications as a single API. That difference matters.
The three core elements that make this work in practice:
- Desired State: the declarative specification of what we think the world should be. (Example: The frontend service should have 3 replicas with 2 GB of memory each.)
- Actual State: the operational reality of what exists in the infrastructure. (Example: The frontend service has 2 healthy replicas, 1 pending.)
- Policy: the rules and governance that constrain operations. (Example: Production changes require approval between 9 AM and 5 PM PST.)
Controllers continuously reconcile desired state with actual state, and policy is enforced at execution rather than left to manual review. Context becomes part of the system, not something external to it.
Why This Model Works for Agents
An AI agent interacting with a Crossplane-managed platform doesn't need to orchestrate workflows across multiple systems. It interacts with a single API surface.
It can discover resource types via the Kubernetes API, inspect status fields for real-time operational state, watch resources for change events, and submit declarative intent. Since reconciliation handles mechanical execution, agents don't need to coordinate step-by-step logic; they just declare intent and let controllers handle convergence.
This separation of concerns is critical. Controllers handle mechanics, while agents focus on higher-level reasoning. Without a control plane, agents become fragile orchestrators. With one, they become declarative participants.
When the entire platform is accessible through a single, consistent API, the agent has everything it needs. No Slack messages and no tribal knowledge required.
Policy at the Point of Execution
In fragmented platforms, governance follows lots of procedures: reviews, tickets, Slack threads. In a Kubernetes-native control plane, governance is architectural.
RBAC controls who can act. Admission controllers validate changes before they're persisted. Policy engines such as OPA and Kyverno enforce constraints at runtime. Crossplane compositions encode organizational patterns directly into APIs. Every change flows through the same enforcement path, no hidden approval steps, no undocumented exception paths.
This removes ambiguity for agents entirely. The system defines what is allowed. Agents operate within clearly defined boundaries, and the platform enforces them automatically.
Crossplane 2.0: Full-Stack Control
With Crossplane 2.0, compositions can include any Kubernetes resource, not just managed infrastructure. That means a single composite API can provision infrastructure, deploy applications, configure networking, set up observability, and define operational workflows, all in one place.
apiVersion: platform.acme.io/v1
kind: Microservice
metadata:
namespace: team-api
name: user-service
spec:
image: acme/user-service:v1.2.3
database:
engine: postgres
size: medium
ingress:
subdomain: usersBehind that abstraction may live RDS instances, security groups, deployments, services, ingress rules, and monitoring resources. To a human developer or an AI agent, it's a single API. That consistency is what enables automation to scale safely.
Day-two operations follow the same pattern. Crossplane's Operation types bring declarative control to scheduled upgrades, backups, maintenance, and event-driven automation:
apiVersion: ops.crossplane.io/v1alpha1
kind: CronOperation
metadata:
name: weekly-db-maintenance
spec:
schedule: "0 2 * * 0"
operationTemplate:
spec:
pipeline:
- step: upgrade
functionRef:
name: function-database-upgradeOperational workflows are now first-class API objects. Agents can inspect them, trigger them, observe their status, and propose modifications. No need for hidden runbooks.
Where to Start
This doesn't require a start-from-scratch migration. Bring core infrastructure under declarative control first. Your existing resources don't need to be replaced; they just need to be unified behind a consistent API.
For teams using AI-assisted development, engineers express intent and iterate quickly as tools accelerate implementation. As deployment decouples from release, with changes shipping behind feature flags and systems reconciling toward the desired state, the platform must be deterministic and self-correcting, not reliant on someone catching drift or running the right command at the right time.
That is what a declarative control plane provides. Crossplane ensures that intent has somewhere safe, structured, and deterministic to land. Without it, AI will always be bolted onto human-centric workflows. With it, agents become first-class participants in infrastructure operations.
And that starts with a consistent API. Get started by checking out the Crossplane Docs, attending a community meeting, or listening to the upcoming Cloud Native Live Crossplane 2.0 - AI-Driven Control Loops for Platform Engineering (or catch the recording).