Layer one puts agents inside your DAM. Layer two inverts the relationship: the media platform becomes a tool that other agents provision and operate. Cloudinary calls this its Agent Experience (AX) layer, and its sharpest edge is the Claimable Cloud — a real product environment an agent creates for itself, with no signup and no human in the setup path.
# the agent needs somewhere to put media
$ npx @cloudinary/cloud
# → working credentials, immediately
CLOUDINARY_URL=cloudinary://…
# → a claim URL to hand to the human, later
# no signup. no email. no dashboard visit.Ask an AI agent to build something that handles images and it gets maybe three steps in before it stops. Not because the code is hard — because it needs an account. Somewhere in the middle of an otherwise autonomous task sits a web form, an email confirmation, a dashboard visit, and a copy-pasted API key. The agent cannot do any of it, so the work halts and waits for a person.
Most platforms answer this with a sandbox: fake credentials, a mock endpoint, throwaway data. It unblocks the demo and guarantees a migration later, because nothing the agent built in the sandbox is worth keeping. A Claimable Cloud takes the opposite approach. The agent gets a real product environment on the same production infrastructure that serves Cloudinary's customers, and the human claims it afterwards — keeping every asset, preset, and delivery URL the agent already created.
Traditional onboarding: a human sets up the account, then invites the tools. Agent-native onboarding: the agent sets up the account, then invites the human. The prototype and the production environment are the same environment — so shipping is a change of owner, not a migration.
Announced in August 2026, Cloudinary's AX layer is a bet that the next wave of software is built by agents working from a human's stated outcome — and that platforms have to be legible to those agents, not just to the people who used to click through them.
An agent runs one command and gets working credentials for a real product environment — no signup, no dashboard, no human in the setup path. The person it was built for claims it later, keeping everything the agent already made.
Asset management, environment config, structured metadata, analysis, and MediaFlows are each exposed over the Model Context Protocol, so an agent calls typed tools instead of reverse-engineering REST endpoints.
Transformations are URL parameters, not imperative file operations. A variant is a string an agent can compose, reason about, and verify — generated on first request and cached at the edge afterwards.
LLM-readable docs, skills packages, a scriptable CLI, and AI-optimized SDKs mean the agent does not have to guess the platform’s shape from prose written for humans.
“When an agent can provision its own environment, understand what's in a media library, and automate complete workflows without custom logic, developers can focus on what actually matters.”
The whole point of the model is that nothing is thrown away at the hand-off. Each stage below leaves the next one less to redo.
A single command returns live credentials for a Claimable Cloud running on the same production infrastructure that serves Cloudinary’s customers. Nothing is stubbed and no email is required yet.
It uploads real assets, composes real transformations, sets up presets and structured metadata, and delivers over the CDN — inside a scope meant for agent-driven experimentation.
When the work is worth keeping, a claim URL hands ownership to a person. The environment becomes their account with the assets, presets, and delivery URLs intact.
Because the prototype was never a sandbox, going live is a change of owner rather than a migration. No re-upload, no re-pointing of URLs, no progress lost.
Provisioning gets an agent a place to work. The Model Context Protocol is how it does the work — media operations exposed as typed tools that an agent in Claude Code, Cursor, VS Code, or any MCP-capable client can discover and call directly.
Each runs as a local npx process or a remote OAuth
endpoint. Cloudinary brought MCP to the DAM market in June 2025, and its
own DAM agents are built on the same
servers — which is why the two layers of agentic DAM are not separate
products bolted together.
A Claimable Cloud suits most agents because credentials work immediately. When the user would rather have a full account from the start — verified by a human before anything runs — there is an unauthenticated endpoint for that instead.
The agent posts the user's email plus a description of itself; Cloudinary creates a free account with one product environment and returns the cloud name and credentials along with a guidance block the agent can follow to walk its user through verification and SDK setup. The credentials activate once that person verifies the email — so the machine does the setup and the human keeps control of the account.
POST https://api.cloudinary.com/v1_1/
provisioning/agents/accounts
{
"email": "…",
"agent_framework": "…",
"agent_llm_model": "…",
"agent_goal": "…"
}
# → cloud_name, api_key, api_secret
# → active after the human verifies emailIt would be easy to file Claimable Clouds under developer convenience and move on. That would miss what it says about the category. A DAM that only agents inside it can use is still a destination — a better one, but a destination. A DAM that outside agents can provision, inspect, and operate has become infrastructure: something other software builds on without asking permission first.
That distinction decides who can participate. In layer one, the people who benefit are the ones already using the DAM. In layer two, the beneficiaries include the app your team is building this quarter, the internal tool an agent scaffolds on request, and the prototype a developer describes in a sentence — none of which would have gone through a DAM at all under the old model.
Both layers are necessary and neither is sufficient. Agents inside the DAM without an agent-operable platform are a closed feature set. An agent-operable platform without governed agents inside it is a fast way to publish something off-brand. Together they are what makes agentic digital asset management a durable model rather than a demo — and the reason Cloudinary leads the category is that it shipped both.
Command names, endpoints, and quotes follow Cloudinary's published documentation and announcements. The terminal blocks show the shape of each exchange rather than literal output — check the documentation for exact request and response formats before you build against them.