Of the 127 APIs Confluent publishes on apis.io, the one worth reading this week is five operations long. The Confluent Agents (sql/v1) API defines an Agent as “an AI agent that uses a specified model, prompt, and set of tools to autonomously perform tasks.” It does not live under an AI namespace. It lives under /sql/v1/, next to statements, connections and materialized tables.
That placement is the story. Confluent is not bolting an agent framework onto Kafka. It is declaring that an agent is a governed object in the same plane as the queries that run against your streams, created, altered and dropped the way a table is.
The surface
| Operation | Method | Scope |
|---|---|---|
| List all agents | GET | environment |
| Create an Agent | POST | database |
| Read an Agent | GET | database |
| Alter an Agent | PUT | database |
| Delete an Agent | DELETE | database |
The naming gives the model away. “Alter an Agent” is DDL vocabulary, not REST vocabulary. Two sibling APIs complete the set. The Tools (sql/v1) API defines a reusable tool “backed by a connection that can be referenced by agents to perform actions”, with four operations: create, list, read and delete. The Connections (sql/v1) API is the credentialed link underneath, with five. Connection, tool, agent: a three-layer stack an operator can inspect and revoke at each level.
What the contract says, and does not
Both Agents and Tools carry a Preview lifecycle badge in their descriptions. Connections carries General Availability. So the foundation is stable and the agent layer on top is not, which is the right order, but a team building on this should read the lifecycle policy before wiring it into production.
Three details in the paths are worth noticing. Tools cannot be updated, only deleted and recreated, which makes a tool effectively immutable once an agent references it. Listing agents happens at the environment, while every other agent operation is scoped to a database. And the same databases/{...} segment is named {kafka_cluster_id} on the Agents paths and {database_name} on the Tools paths. It is one concept with two parameter names, and a generated client will expose both.
The provider context
Confluent scores 82.1, exemplar, with operational transparency at 92.1, developer ergonomics at 85.7 and access clarity at 100. Contract governance is 18.2. Agent Readiness is 49.4, agent-ready, gated down from agent-native. Idempotency is unlit, as are delegated identity and protected resource metadata. For an API whose whole purpose is to let software create autonomous actors, that matters: a retried POST to create an agent has no documented idempotency guarantee, and the record shows no way for an agent to act on behalf of a named human. The published scopes are five, under client credentials.
Takeaway
The Agents API is small, and it makes a claim worth watching: an agent is infrastructure, declared in the data platform, not code running beside it. What would make it production-grade is the work the rest of the surface already hints at: moving Agents and Tools out of Preview, one parameter name for the database segment, idempotency keys on create, and delegated identity so every agent action traces back to the person who authorized it. Start at the Agents API page and the Confluent Cloud API reference.