Stop asking DAM vendors if they have AI. Start making them prove it.

Many enterprise digital asset management (DAM) vendors now market AI and on a questionnaire, they all say they deliver AI capabilities. This post is about how to actually tell if it’s going to help your business.

Put six DAM vendors on a shortlist, ask each one whether their platform has AI and you’ll get six confident “yes” answers. They’ll demo AI tagging, natural-language search, generative variants and agents that enrich and publish. One will claim it has an agentic DAM, while another makes noise about its new MCP server. By the time you’ve reached your third meeting, the demos have all run together and you can’t remember who showed you what.

We flagged the same blind spot in the first post in this series, when we covered DAM comparison charts. An evaluation built on yes/no questions makes every vendor look the same. Does your DAM have AI? Yes. Does it govern content? Yes. Does it fit our stack? Yes. In the end, you have a column of check marks and a three-year platform decision resting on a thirty-minute demo.

The vendors aren’t lying. They’re just not all talking about the same thing when they say AI. For some, AI is primarily about finding assets faster through better tagging, richer metadata and natural-language search. For others, the bigger opportunity is activation: using AI to turn an asset into content that is governed, personalised, approved and ready to use across channels. Those are very different jobs hiding behind the same check mark. What separates one platform from another isn’t whether the AI is there. It’s what the AI actually helps you to do and whether it holds up when you put your real content and workflows through it. You won’t see that in a feature grid. You’ll see it once you stop asking questions and start running tests.

What “AI-ready” really comes down to.

Think about how often your team needs an asset somewhere other than the DAM. A designer needs one in a creative tool. A marketer needs one in a campaign platform. A web team needs one for a customer. How the asset gets there matters. In one platform, another application can access the DAM and work with the governed asset. In another, the process still comes down to downloading a file, working on a copy and uploading it again. Both vendors can check the integration box. The underlying behaviour is very different.

Now add AI. The agent inherits the same constraints. Give it an MCP connection and it may be able to reach into the DAM, but can it actually find the right asset? That depends on the metadata and context available to it. A creative team may search by campaign, concept or visual characteristics. A downstream team may care about product, market, rights, channel or approval status. An agent may need to understand both. Access to the DAM is not much use if the AI cannot tell which asset is actually right for the job.

Then there is what happens when the agent acts on what it finds. Does it work from a governed source and maintain that connection as content moves through the workflow? Can downstream tools and channels get the approved asset without creating another copy? Or does every handoff produce another file that has to be tracked, updated and governed?

And can the DAM keep up? A person might search for an asset, open it, make a change and move on. An agent can make many requests in the time it takes that person to make one. Put multiple agents, applications and people to work at once and those requests add up quickly.

That puts pressure on an infrastructure decision the DAM vendor made long before you connected an agent. Was the platform designed with the capacity to support that volume of machine-driven activity or was it built around the pace of people working in applications? If the DAM or its APIs cannot handle the volume because of capacity or rate limits, requests get throttled or blocked. Workflows wait. Requests time out or fail. What worked perfectly in a controlled demo can grind to a halt when AI starts doing real work at scale.

This is where the differences between platforms start to compound. Connecting AI to a DAM is one thing. Giving it the context, access, performance and governed path it needs to do useful work is another. The more work you expect AI to take on, the more the architecture underneath it matters.

So don’t take anyone’s word for it — ours included. Make them show you. Below is a set of questions you can climb, starting with one that anyone in the room can ask and ending with the one that actually sorts the field.

Five questions: each harder to answer than the last.

Question 1: Can your DAM connect to the tools your team already works in?

Everyone will say yes. Now find out what their yes actually means. Does the platform simply expose APIs that let another application search for and retrieve an asset? Does it provide supported, prebuilt integrations for common workflows? Can those APIs be extended to support the workflows unique to your business? And when another system uses an asset, is it operating against the governed source or creating another copy that has to be synchronised and managed?

Then add an agent. Does that connection operate under the same identity, permissions, rights and governance as the people using the DAM or has the AI been given a separate path into the content? An agent can make far more decisions and requests than a person, so a connection that bypasses those controls amplifies the risk along with the speed.

Every vendor can call this connected. The architecture and governance behind that connection can be very different.

Question 2: What kind of reach does your DAM have?

Once it’s connected, what can that connection actually see and retrieve? Everyone can say their DAM makes assets available. Now find out what available means. Can another application or agent reach only the file or can it reach the information that makes that file usable: descriptive metadata, product and campaign context, usage rights, approval status, relationships to other assets and provenance?

Then look beyond the original binary. If the DAM can generate different renditions of an asset, can the connection discover and request the right size, crop, format or other representation without creating and managing another copy? Can it distinguish the original from an approved rendition or a generated variant? And when it retrieves any of them, does the governance and context travel with the request?

Being able to retrieve an asset is one kind of reach. Being able to reach the asset, its business context, its governance and the right representation for the job is another. Make the vendor show you how far their connection actually reaches.

Question 3: Does your DAM support workflow chaining?

Real content work rarely happens in one system. An asset may need to be found, adapted, reviewed, approved, assembled and ultimately put into place before a customer ever sees it. Everyone can say they support that workflow. Now count the jumps. How many other tools, integrations, exports and handoffs does the asset have to pass through before it is usable and live?

Then look at what happens at each jump. Does the asset remain connected to its identity, metadata, rights, approval state and source or does another system create a copy and start managing its own version? Does the next step happen as part of a connected content supply chain or does a person or another system have to pick up the output and push it forward?

Ask the vendor to take one real asset from source to placement and show you every system it touches along the way. A workflow with six connected tools may technically be integrated. It’s still six places for content, context and governance to break.

Question 4: Can your AI enrich assets with context?

Everyone can say their AI enriches assets. Now find out what enrichment actually means. Does the platform generate a few descriptive tags at ingestion or does the asset accumulate context that makes it more useful throughout its lifecycle? Can it understand what the content is, connect it to business and brand context, carry rights and governance, preserve provenance and learn from how and where that content is used?

Then ask who can use that intelligence. Does it become part of the governed asset context that creative teams, downstream applications and AI agents can all access or is it trapped inside a search feature or a separate AI experience? And as the asset is activated and performs, can those signals come back to make its context richer for the next decision?

Generating metadata is enrichment at its simplest. Building trusted context that helps people and AI discover, understand, use and ultimately improve content is a much higher bar.

Question 5: Does your DAM support governed delivery?

Content only counts once it reaches the people who see it. Everyone can say their DAM delivers content to websites, apps and campaigns. Now find out what delivery actually means. Is the channel receiving another copy of the asset or is it requesting content through a delivery layer connected to the governed source? If the asset changes, is reapproved, expires or loses its usage rights, what happens to what is already in market? Does the change flow through, or does someone have to find and replace copies across channels?

Take the test outside the DAM. Have the vendor request an asset the way a live channel would. Then change the governed version and request it again. What reaches the customer should reflect the current approved state without someone manually chasing down copies. Storing governed content and delivering governed content are not the same thing.

Now put all five together. Everyone can say yes to connection, reach, workflows, enrichment and delivery. The question is what those yeses actually mean. Can people, applications and agents work through governed connections? Can they reach the asset, its context and the right representation? Can content move through the supply chain without accumulating copies and losing context at every hop? Does its context get richer and more useful over time? And can the approved content ultimately reach the customer without breaking its connection to the governed source?

That is the foundation AI has to work with. An agent does not fix what is underneath it. It inherits it and then operates on it faster and at greater scale. That is why an agent working inside a connected, contextual, governed content supply chain is very different from one bolted onto the side of a DAM. It is also where the next post picks up.

Run the test on Adobe.

We’re comfortable being tested, so here is how Adobe Experience Manager Assets answers each question, scoped to what Adobe documents publicly and stands behind.

Connection. Your team can access assets from the tools they already work in through supported connections: Creative Cloud through Adobe Asset Link, Adobe Workfront, the rest of Experience Cloud and open APIs you can extend to your own workflows. With Dynamic Media . Bring an agent and the same rule holds. The unified Adobe Experience Manager’s MCP Server operates inside Adobe Experience Manager’s existing permission model, so the agent acts under the authenticated user’s identity and that user’s permissions, not on a separate path around them. For changes and deletions, Adobe steers agents to the AI Assistant interface, whose Adobe Experience Manager agents include built-in safeguards.

Reach. Through that connection, an application or agent reaches more than the file. It can reach the metadata and business context that make the file usable: the customised fields your teams actually search on, such as product, market, campaign, channel, rights and approval status, along with the asset’s relationships and its provenance. Adobe Experience Manager’s content discovery works from natural language against those fields, so an agent can look for the asset that is right for the job rather than any asset that matches a filename. And when it needs a specific size, crop or format, Dynamic Media with OpenAPI can generate and serve that rendition by reference, without spawning another copy to track and with only approved assets exposed.

Chaining. Real work crosses systems and every hop is a chance to lose the thread. Where applications and channels consume through the governed delivery path, the asset can stay a reference to the approved source rather than a copy that each tool has to manage on its own. A change made once to the governed asset shows up wherever that reference is used, so the link to identity, rights and approval state travels with the asset instead of being rebuilt at each step. The fewer copies a workflow spawns, the fewer places content, context and governance can break.

Enrichment. Enrichment starts at ingestion: Smart Tags for supported image, video and text assets, AI-generated title, description and keywords on compatible releases and the customised metadata schemas that carry your business and brand context. That context becomes part of the governed asset, available to creative teams, downstream applications and agents through search and discovery, rather than trapped inside a single search box. From there, usage and delivery signals can feed reporting and optimisation workflows and Adobe is extending Adobe Experience Manager Assets with agentic capabilities that use metadata and usage signals to support discovery, governance and content recommendations. Generating a few tags is the floor. Building governed context that people and AI can actually use is the bar.

Delivery. Content only counts once it reaches the customer and this is where governance either holds or quietly breaks. With Dynamic Media with OpenAPI, consuming applications and channels can receive a delivery URL that references the approved asset rather than a copy of the source binary and only approved assets and the latest approved version are exposed. When the governed asset changes, is reapproved, expires or loses its rights, the change can flow through that delivery path rather than leaving someone to hunt down stale copies across channels and with the documented, cache the update typically becomes visible in under ten minutes. Storing governed content and delivering governed content are not the same thing.

And it has to hold up at machine speed. An agent makes many requests, whereas a person makes one, so the architecture underneath matters. Adobe Experience Manager Assets is cloud-native and scales to workload and Dynamic Media with OpenAPI delivers through a managed content delivery network (CDN) and edge caching built for scalable, application- and machine-facing consumption, with transformations handled at the edge to reduce load on the origin. How it performs depends on your request mix, transformations, caching and configuration, which is why the right way to prove it is a representative validation on your own assets and workflows, not a one-off spike in a demo.

Put all five together and you have the foundation an agent actually needs: governed connections, real reach into context, a supply chain that resists multiplying copies at every hop, context that keeps getting more useful and approved content that reaches the customer without losing its link to the source. An agent does not fix what sits underneath it. It inherits it and works on it faster and at a greater scale. That is the difference between an agent operating inside a connected, governed content supply chain and one bolted onto the side of a DAM.

You don’t have to take our word for it. Adobe was named a Leader in the 2025 Gartner® Magic Quadrant™ for Digital Asset Management Platforms and in The Forrester Wave™: Digital Asset Management Systems, Q1 2026.

How to run this in your next vendor call

Bring these questions to every shortlist meeting, ours included. Don’t ask whether they can do it. Ask them to do it, live, on a real asset instead of a rehearsed sandbox. Connect it to a tool your team actually uses and see whether the application works against the governed asset or just grabs a copy. Ask what the connection can reach beyond the file. Take one asset from the source to the placement and count the hops. Ingest something and see what the platform makes of it. Then request it the way a live channel would, change the approved version and confirm what reaches the customer updates without anyone chasing copies. Put a realistic, representative workload through it, the kind of concurrent human and agent activity you actually expect, rather than settling for demo volume.

Pay attention to where each vendor reaches for a slide, a roadmap or an explanation. That reach is your answer. It’s the moment a promise stops turning into proof. The vendor whose evidence holds up across all five is the one still likely to be running your AI workflows in year three, long after the demo is a memory.

Because every DAM says yes. Very few can show you.

Frequently asked questions