Ten CMS Vendors Changed Their Pitch Around AI
Five of the ten moved their category label. We checked what their documentation says about running AI agents.
Between October 2023 and October 2026, five of these ten CMS vendors changed the category they put on their homepage, all of them towards AI or agents. We read each vendor's public documentation to see what its AI agents are documented to do inside a content workflow: who the agent is, who checks its work, what stops it, and what the log records. We used each vendor's own documentation and four evidence grades. No vendor briefings, no sales decks, no trials.
Why we looked, and who is on this page
Over the last eighteen months, CMS vendors have started to describe themselves differently. Acquia now leads with “The Agentic Content Platform”, Contentstack’s page title became “Agentic Experience Platform”, and Contentful’s headline reads “Built for humans. Ready for Agents”. We wanted to know two things. Is this a real shift in how the market positions itself, or a few loud rebrands? And when a vendor changes its pitch, does its documentation describe AI agents that work inside a content workflow?
The ten vendors graded in this report are the same ten as in our CMS structural report: Contentstack, Optimizely, Sitecore, Adobe, Kontent.ai, Storyblok, Hygraph, Acquia, Contentful and RWS Tridion. To tell whether the shift is a trend, we added 18 more: every other vendor in Gartner’s January 2025 Magic Quadrant for DXP or in Forrester’s 2025 Waves for CMS and DXP, plus the two vendors Gartner dropped from its quadrant that year. We looked at how those 18 describe themselves. We did not grade their documentation.
| What we did | Vendors | |
|---|---|---|
| Step 1: how they describe themselves | Captured each vendor’s own homepage or product page at seven dates six months apart, October 2023 to October 2026, from the Wayback Machine. Read the page title, description and headline, and coded the category word the vendor used for itself: DXP, CMS or content platform, AI- or agent-led wording, agentic platform, or none. Every quote is verbatim. | All 28 |
| Step 2: what the documentation shows | Graded each vendor’s public documentation, and nothing else, on 19 capabilities for running AI agents inside a content workflow, using four evidence grades. | The ten |
The timeline below is step 1. Of the 28 vendors, 12 changed their category word between October 2023 and October 2026, 13 kept the same word throughout, and three changed it and later went back. Ten carry an “In the report” tag; the other 18 give the wider picture. It shows positioning, not capability. The matrix further down is step 2.
Ten of the 28 vendors below are graded on this page and carry an "In the report" tag. Five of those ten changed their category word between October 2023 and October 2026; five kept it.
Source: each vendor's own pages via the Wayback Machine, October 2023 to October 2026. Logos are the vendors' own and appear for identification.
About this research
This report is part of the Content Value Chain capability map — an ongoing, evidence-graded research project checking what marketing and content platforms actually document, not what their marketing pages promise. Each category we publish breaks one part of the content operating stack into specific, testable capabilities, then checks every vendor's own public documentation against each one, using four evidence grades, from Verified to Unknown. We don't rank vendors or declare a winner — the matrix shows what's documented, capability by capability, so you can weigh it against what actually matters for your team.
What you're reading here answers one question: what these platforms could do, based on what's publicly documented — the Licensed ceiling. It doesn't answer whether any of it is actually switched on in a specific organization's instance, or whether teams use it day to day — those are separate questions (Enabled, Practised), and they can only be measured inside a real stack, not from public documentation. That's the deeper version of this same assessment: the Content Value Chain diagnostic runs the identical evidence discipline and the same four grades against your own tools instead of the open market.
It's the same framework behind the Content Value Chain book; this is the field research underneath it, published as we do it.
Where this fits in the whole system
The Content Value Chain is a dependency structure, not a menu of options — each layer is built on the one before it, from diagnosing what's broken (Diagnosis) through to sensing and reacting to the market (Market Environment). Seven layers, sixteen named components between them — each component is one specific, book-chapter-sized piece of a content operation, like "Brand LLM / AI Brand Governance" or "Universal Taxonomy."
Every report we publish picks one component and breaks it into a handful of specific, testable capabilities — concrete claims like "does this platform enforce brand rules while content is being generated, or only after" — then checks every vendor's own documentation against each one. A highlighted component below has at least one published report; the rest are components we haven't researched yet, not components that don't matter. Altogether, the framework breaks down into 103 specific, testable capabilities spread across 13 of its components — the ones where "does this product do X" is a fair, checkable question. Two more categories work differently: Failure Modes Map and Market Environment are diagnostic and market-context lenses rather than product capabilities, so they're part of the framework but never vendor-graded the same way. Any single report only ever covers one component's worth of that — a handful of capabilities, checked against a handful of vendors — which is what this map is actually tracking: how much of the 103 is covered so far, and how much is still ahead.
Diagnosis
Surface variance, drift, and automation theatre before they compound under AI scale.
System Model
Shift from production pipeline to value creation system.
Structural Infrastructure
Make content reusable by design — a shared vocabulary, atomic units, and reusable patterns.
Execution Infrastructure
Connect workflow, routing, telemetry, DAM, and memory so the system can operate as one.
Control Systems
Govern AI execution and human judgment at scale through clear ownership and decision boundaries.
Activation Layer
Track every variant in production, measure outcomes, and feed signal back into the system.
Market Environment
The external context the system operates in — competitors, analyst coverage, and market signals outside your own stack.
What we checked
Each of these components breaks down into specific, testable capabilities — the part of a content operation responsible for what happens when AI agents work inside it.
Digital Backbone
The workflow and lifecycle an agent works inside.
| Capability | What it means for a CMS vendor's agent layer |
|---|---|
| DB-1 — Workflow orchestration | Content moves through production and approval steps that your team can configure. |
| DB-2 — Task routing | Work is assigned by role, and some of it can go to an AI agent, for example when content reaches a stage. |
| DB-3 — Lifecycle states | Items carry more states than draft and live, such as in review or approved. |
| DB-4 — Telemetry per stage | The workflow measures how long each step takes and where work piles up. A review queue alone does not count. |
| DB-5 — Traceability | A change history per item: who changed what, when and, ideally, why. |
| DB-6 — Deprecated and retired states | Old content is retired as a state that keeps the item, rather than being deleted. |
Decision Domain Map
What an agent may decide alone, and what stops it.
| Capability | What it means for a CMS vendor's agent layer |
|---|---|
| DD-1 — Human gates per action type | Approval can be required for specific actions, such as publish or delete, and not only for everything or nothing. |
| DD-2 — Autonomy per decision class | Different kinds of decisions can be given different levels of autonomy. |
| DD-3 — Escalation at a threshold | When risk or uncertainty passes a set level, the case goes to a person. |
| DD-4 — Risk as an input to routing | The risk of an action decides where the work goes. |
| DD-5 — Automated versus approved record | Afterwards you can tell what the AI decided alone from what a person approved. |
| DD-6 — Reversibility | The system knows which actions it can undo and can undo them, with a record. |
| DD-7 — Automation per operation | Each frequent operation, such as tagging or routing, can be automated separately. |
| DD-8 — Uncertainty exposed | The system shows how sure it is of each decision, not only pass or fail. |
| DD-9 — Decision authority as configuration | Limits on what the AI may do are settings with a recorded change history, not code. |
| DD-10 — Reliability per decision class | Error, override and failure rates are reported by kind of decision, as evidence for giving the AI more or less authority. |
AI Agent Org Chart
Who the agent is, who checks it, and how it shows in the record.
| Capability | What it means for a CMS vendor's agent layer |
|---|---|
| AO-1 — Named, scoped agents | Each agent has a name, a scope and permissions of its own, not only those of the person who started it. |
| AO-2 — Supervision | Someone or something other than the agent reviews its output. |
| AO-3 — Agents in the audit trail | The log shows which actions the AI took, as distinct from a person's. |
How we chose these capabilities, and what they're not
Why these three components. The question this report asks is whether a vendor's documentation describes AI agents that can be trusted to work inside a content operation. The framework has sixteen components, and three of them answer that question directly. The Digital Backbone is the workflow an agent works inside: how content moves through production and approval, who or what receives the work, and what the record shows. The Decision Domain Map sets what an agent may decide alone, what needs a person, and what stops it when it gets something wrong. The AI Agent Org Chart covers who the agent is: whether it has a name, a scope and permissions of its own, who reviews its output, and whether the log shows its actions apart from a person's. The other components answer different questions, such as how content is structured (our CMS structural report) or how brand rules are applied while content is written (our Brand Governance report). We did not grade them here.
These nineteen capabilities are not a checklist assembled from vendor marketing pages or analyst reports. They come from the book itself. Chapter 11 describes the Digital Backbone, the workflow layer that content moves through. Chapter 14 describes the Decision Domain Map, which sets what AI may decide alone, what needs a person, and how that authority changes as reliability is shown. Chapter 7 describes the AI Agent Org Chart, which treats agents as accountable actors with roles, supervision and their own audit trail. We restated what each chapter requires as something a product either verifiably does or does not do, then checked each vendor's documentation against it. A taxonomy built from what vendors already sell would describe the market back to itself. This one comes from the framework's own architecture, so a vendor either matches it or it does not.
That also means this is not exhaustive. These nineteen are the specific claims the book makes about the workflow an agent works inside, what it may decide alone, and how it is identified and supervised. They are not a complete inventory of what a CMS or its AI features can do. A vendor can have real strengths, such as the editing experience, delivery speed, integrations or the quality of its AI output, that do not appear here, because they are not what these three components are about. A vendor with gaps here can still be the right choice for a team whose priorities sit elsewhere. This report answers one narrow question: what is documented about running AI agents inside a content workflow. It does not say which CMS to buy, and it does not test whether any agent works well.
A feature comparison starts from a vendor's own list of what it sells and checks a box when the feature exists. This starts from what the book argues has to be true for agents to work safely inside a content operation, whatever a vendor calls it. That is why every capability is named by function ("task routing", "uncertainty exposed") and never by a vendor's product name. A capability gets a Verified grade only when the vendor's own documentation, not its marketing copy, describes the mechanism for that specific claim. In the full report, every grade links to that page and quotes the sentence it rests on, so you are not taking our word for it either.
Which vendors and what we graded. Contentstack, Optimizely, Sitecore, Adobe, Kontent.ai, Storyblok, Hygraph, Acquia, Contentful and RWS Tridion, all on public documentation only. For each vendor we graded its CMS plus its own agent layer: Adobe is AEM Sites and Assets with Coworker, Acquia is Source CMS with Acquia AI and its bundled digital asset management, and RWS Tridion is Tridion Sites. Contentful's Personalization product is not included. RWS's documentation site blocks automated reading, so the Tridion pages in this edition were read by hand and most of its cells are Unknown; Unknown never means the product lacks it.
How to read the grades
Evidence grade
- Verified — the vendor's own product, help or developer documentation describes the specific mechanism.
- Vendor-claimed — stated on a marketing or product page, without a described mechanism.
- Inferred — reasoned from adjacent evidence, not directly stated.
- Unknown — not found in what we checked. That is not the same as confirmed absent.
A small ◦ marker next to Unknown means a near-miss: the vendor documents something close, but it doesn't meet the capability as defined. The full findings explain what.
How it arrives (shown under Verified grades)
- •Native — the product does it out of the box; you supply only your content, such as a word list.
- •Configured — an administrator fills in named fields or settings the product provides, such as a tone field or a per-channel rule.
- •Assembled — your team would have to build it from generic parts, such as a free-text prompt or custom fields. We never grade Assembled above Inferred, because a capability you have to design yourself is not one the product delivers.
Plan level (where the documentation says so)
- •Higher tier — the product does it, but not on every plan.
- •Add-on — available as a separate purchase.
- •Third-party — needs another product alongside it.
No plan label means it is in the base product, or the documentation didn't say which plans include it.
Where this grading stops
Everything in this report is graded from the outside, from documentation any buyer can read. That sets a limit, and we hold to it. The highest grade here, Verified, means the vendor's own documentation describes the mechanism. It does not mean we have tested it, that it works as described, or that you have it.
We grade three levels in a full assessment. Licensed: what the product can do on the plan you buy. Enabled: what is actually switched on and configured in your instance. Practised: whether your team's day-to-day work goes through it or around it. Public documentation can only answer the first, so that is where the grading in these reports stops. Where a vendor keeps its user guides behind a customer login, the grade stops earlier still, at what its public pages and developer documentation show, and we say so in the findings.
The other two levels can only be measured inside your own stack. That is what the Content Value Chain diagnostic does, with the same capabilities and the same evidence rules.
A cell can also say beta, early access or lab, where the vendor describes the feature that way. ◦ documented absent means the vendor's own documentation says the capability is not supported, as of the month shown. It is a marker on Unknown, not a fifth grade.
The matrix
We grade each vendor on three components: the workflow an agent works inside, what it may decide alone, and who the agent is and how it shows in the record.
Digital Backbone
The workflow and lifecycle an agent works inside.
| Capability | Contentstack | Optimizely | Sitecore | Adobe | Kontent.ai | Storyblok | Hygraph | Acquia | Contentful | RWS Tridion |
|---|---|---|---|---|---|---|---|---|---|---|
| DB-1 Workflow orchestration across production and approval | Verified Configured · higher tier | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Verified Configured · higher tier | Verified Configured |
| DB-2 Task routing by role and to AI agents | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Verified Configured | Verified Configured · lab | Unknown◦ near-miss | Verified Configured · higher tier | Unknown◦ near-miss | Inferred Assembled · higher tier | Unknown◦ near-miss |
| DB-3 Explicit lifecycle state beyond draft and published | Verified Configured · higher tier | Verified Native | Verified Configured | Verified Native | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Verified Configured | Unknown◦ near-miss |
| DB-4 Telemetry per stage | Verified Native | Unknown | Unknown◦ near-miss | Unknown◦ near-miss | Verified Native | Unknown | Unknown◦ near-miss | Unknown | Unknown◦ near-miss | Unknown |
| DB-5 Traceability: who changed what, when and why | Verified Native | Verified Native | Verified Native | Verified Native | Verified Native | Verified Native | Verified Native · higher tier | Verified Native | Verified Native · higher tier | Unknown |
| DB-6 Deprecated and retired as real states | Unknown | Verified Native | Unknown◦ near-miss | Verified Configured | Verified Native | Unknown◦ near-miss | Unknown◦ near-miss | Verified Configured | Verified Native | Unknown◦ near-miss |
Decision Domain Map
What an agent may decide alone, and what stops it.
| Capability | Contentstack | Optimizely | Sitecore | Adobe | Kontent.ai | Storyblok | Hygraph | Acquia | Contentful | RWS Tridion |
|---|---|---|---|---|---|---|---|---|---|---|
| DD-1 Human-in-the-loop gates per action type | Unknown◦ near-miss | Verified Configured | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Verified Configured · beta | Unknown◦ near-miss |
| DD-2 Autonomy level per decision class | Unknown◦ near-miss | Verified Configured | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Unknown | Unknown | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss |
| DD-3 Escalation when a threshold is breached | Unknown◦ near-miss | Verified Configured | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown |
| DD-4 Risk level as an input to routing | Unknown | Verified Native | Unknown◦ near-miss | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown |
| DD-5 Record of automated versus human-approved decisions | Unknown | Unknown◦ near-miss | Unknown | Unknown | Verified Native · lab | Unknown | Unknown◦ near-miss | Unknown◦ documented absent | Unknown◦ near-miss | Unknown |
| DD-6 Reversibility as a property of an action | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Unknown◦ near-miss | Verified Native | Unknown◦ near-miss | Verified Native · higher tier | Unknown◦ near-miss◦ documented absent | Unknown◦ near-miss | Unknown◦ near-miss |
| DD-7 Automation scoped per operation | Verified Configured · early access | Verified Configured | Verified Configured | Verified Configured | Verified Configured · lab | Unknown◦ near-miss | Verified Configured | Unknown◦ near-miss | Verified Configured · higher tier | Unknown |
| DD-8 Uncertainty exposed by the system | Unknown | Verified Native | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown |
| DD-9 Decision authority as versioned configuration | Unknown | Verified Configured | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown◦ near-miss | Unknown |
| DD-10 Reliability reportable per decision class | Unknown◦ near-miss | Verified Native | Unknown | Unknown◦ near-miss | Unknown◦ near-miss | Unknown | Unknown◦ near-miss | Unknown | Unknown | Unknown |
AI Agent Org Chart
Who the agent is, who checks it, and how it shows in the record.
| Capability | Contentstack | Optimizely | Sitecore | Adobe | Kontent.ai | Storyblok | Hygraph | Acquia | Contentful | RWS Tridion |
|---|---|---|---|---|---|---|---|---|---|---|
| AO-1 Agents as named, scoped actors with permissions | Inferred | Verified Configured | Inferred | Inferred | Verified Configured · lab | Inferred | Inferred | Verified Native | Inferred | Unknown |
| AO-2 Supervision: agent output reviewable by another actor | Verified Configured · early access | Verified Native | Verified Native | Verified Configured | Verified Native · lab | Verified Native · beta | Verified Native · higher tier | Verified Native | Verified Native · beta | Unknown◦ near-miss |
| AO-3 Agent actions attributed in the audit trail | Unknown◦ near-miss | Verified Native | Unknown◦ near-miss | Unknown◦ near-miss | Verified Native · lab | Unknown | Unknown◦ near-miss | Unknown◦ near-miss◦ documented absent | Unknown◦ near-miss | Unknown |
Graded October 2026 from each vendor's product, help and developer documentation. Small text under a grade shows how a capability arrives and where it is limited to a higher tier, beta, early access or a lab. Acquia is Source CMS with Acquia AI and its bundled digital asset management, not its self-managed hosting product. Contentful's Content Operations Agent entered public beta on 20 October 2026. RWS Tridion is Tridion Sites; its documentation could not be read by our tools, so most of its cells are Unknown. We do not total grades per vendor.
What the documentation actually shows
Nine of ten vendors document a person approving an agent's work, and in six of them the agent works with the permissions of whoever started it. Hygraph says “no agent output reaches your published content without an editor sign-off”; Acquia requires “a second, separate approval” before anything is published; Storyblok says “any action that writes content or changes configuration requires manual approval”. Three vendors give the agent an identity of its own. Optimizely: “Each Virtual Teammate has its own Opti ID account”. Kontent.ai gives its expert agents “a dedicated permissions model instead of Management API keys”. Acquia's agent “never inherits permissions from the requesting user”. The other six (Contentstack, Sitecore, Adobe, Storyblok, Hygraph and Contentful) run the agent as the person: Contentstack's agent “acts as the person who ran it”, and Storyblok's agents “depend on the role and permissions of the user who prompts it”. In those six, the person who asks for the work is also the person whose name is on it. RWS Tridion is Unknown on both.
Only Optimizely documents the decision layer, and it does so for its specialized agents. It is the one vendor that describes autonomy granted per action (“allow specific actions to run automatically within the boundaries you set”), escalation when a run strays from its learned baseline, a review of sensitive tools such as publish and delete before they run (“Optimizely maintains the list of sensitive tools. Agent builders cannot add or remove tools”), and a quality score on each run. Every other vendor is Unknown or a near-miss on at least seven of the ten decision-layer capabilities. The pages we read for Optimizely's Virtual Teammates describe the controls without showing the settings screen, which is the first thing to ask to see.
Acquia has the clearest separation between an agent and a person, and says what it lacks. Acquia AI works through its own Agents Team role that “never inherits permissions from the requesting user”, with a plan approval followed by a separate publication approval. The same documentation lists, among its limits, “No customer-visible record of agent activity is provided” and “No automatic reversal”. A buyer who reads Acquia's own limits page learns more than one who reads most vendors' feature pages.
Contentful has the fullest trail for AI Action runs, and its agent is days old. Each AI Action run in the audit log records the person who started it, the entry and field, the model and the AI Action's version, and bulk runs list every affected entry. The Content Operations Agent entered public beta on 20 October 2026 and “never publishes, archives, or changes a content type without your explicit approval”; the documentation does not yet say whether the agent's own actions are labelled in the audit log. Contentful's changelog says AI Actions can be added to workflow steps, but its API reference lists only email, task and Slack as step actions, so workflow routing is graded on the route that is confirmed, Automations (Pro plans and above), which the customer assembles.
Three vendors document an agent starting from a workflow stage or step, and the rest leave it beside the workflow. In Hygraph an agent is a workflow step: “the agent automatically starts processing as soon as an entry moves into that step”, then hands over to a read-only review with field-by-field revert. Kontent.ai's expert agents start “when content reaches a workflow step”. Adobe documents it for translation only. Contentful can get there through Automations, but an administrator builds that flow from generic nodes, which we grade as Assembled and cap at Inferred; its changelog also says AI Actions can sit in workflow steps, which its API reference does not confirm. For the other five, an agent starts from a person's request, a schedule or an event, and no page ties it to a stage. Hygraph and Kontent.ai pair that with unchanged "CMS" labels on their homepages.
The audit trail is where an agent most often disappears into a person's name. Only Optimizely and Kontent.ai are Verified for labelling agent actions as the agent's. Storyblok says “any change it makes is attributed to you”. Contentstack's documentation is clear that “agent writes are not labelled as agent in the content audit log”. Acquia's own documentation goes further and lists “No customer-visible record of agent activity is provided” among its limits, which we mark as documented absent. Hygraph's audit log has five actor types and none is an agent. A buyer who needs to answer "did a person or an agent publish this" should ask for the log, not the feature page.
The documented agents are young, and several are not generally available. Contentful's Content Operations Agent is a public beta from 20 October 2026. Storyblok's agents sit in Storyblok Labs and are “still in beta”, dated 10 September 2026. Kontent.ai's Aiko and expert agents sit in an Innovation Lab, released on 11 February and 12 March 2026. Acquia's MCP server is marked experimental. Hygraph's agents are Enterprise-only. Contentstack's changelog dates Agent OS to 1 June 2026 while several of its pages still say Early Access. Optimizely's governance layer is two to five months old. Grades describe the documentation on 22 October 2026.
Changing the homepage label does not predict documented governance. Sitecore, Acquia, Optimizely, Contentstack and Contentful changed their category word between October 2023 and October 2026; Adobe, Hygraph, Kontent.ai, Storyblok and RWS Tridion kept theirs. The vendor with the most documented agent governance, Optimizely, changed its label; the next, Kontent.ai, did not, and calls itself “the world's first Agentic CMS” in its llms.txt. The two with the fewest Verified agent cells, Storyblok and RWS Tridion, both kept their label.
RWS Tridion is mostly Unknown because its documentation could not be read by our tools. What the pages we did read show is a classic workflow with review steps, and an optional Semantic AI package whose Smart Tagging either suggests tags for review or classifies a selected group automatically (“changing the tags later is still possible”). The one agent-like feature in the material is a copilot from a partner, ai12z, announced in February 2024, with no governance detail. Tridion's versioning, audit and workflow-assignment pages are the first to read before drawing a conclusion.
Some capabilities in a comparison like this turn out to be floors or ceilings rather than real differentiators. A floor is a capability every vendor claims — useful to know, but it tells you what's table stakes for the category, not which vendor is actually stronger. A ceiling is the opposite: a capability no vendor in the set can document at all, which says something about the whole category rather than about any one product's weakness. The useful signal sits in between, where vendors genuinely differ.
Workflow is the floor, there is no ceiling, and the decision layer is the closest thing to one. All ten vendors are Verified for workflow orchestration. Lifecycle states, change history and human review of agent output are Verified for nine of ten, with RWS Tridion as the exception on each. No capability is Unknown for every vendor. The closest is uncertainty exposed by the system: Unknown for nine vendors and Verified for one, Optimizely. Escalation at a threshold, risk as an input to routing and decision authority as versioned configuration are Unknown for eight. The capabilities that separate the ten are the three about the agent as an actor: whose permissions it uses (three own identities, six borrowed), whether it starts from a workflow stage (three), and whether the log names it (two).
Evidence & sources
Each grade below links to the vendor's own documentation. Where a quote is shown, it is the vendor's wording. A short line after the grade says how the capability arrives (Native, Configured or Assembled) and any tier, beta, early access or lab limit. Unknown means we did not find it in public documentation, not that the product lacks it; ◦ documented absent means the vendor's own documentation says it is not supported.
Contentstack
Contentstack documentation (about 250 pages across workflows, roles, audit, analytics, Agent OS and Polaris), the Content Management API audit-log and workflow references, the product changelog (April to October 2026) and the MCP server documentation. Contentstack Academy was not read. Agent OS is dated 1 June 2026 in the changelog, while several Agent OS pages still carry an "Early Access" notice.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured · higher tier | Workflows define stages, user and role assignment and publish-approval rules; stage moves arrive as Tasks. "Workflows are available only if included in your plan" (About Workflows) |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | Role routing is documented ("Assign specific users or roles to workflow stages"). Automations have a Workflow Trigger ("Triggered when a workflow stage changes") and an action can Set Entry Workflow (Contentstack trigger, entries actions); agents are said to start on "a content or system event", but no agent page names the workflow trigger and the agent examples use an HTTP trigger. Compound rule: partial. Rule used for DB-2 across vendors: V needs an agent started by a workflow-step or approval event, or an AI service performing a workflow task (Kontent.ai, Adobe). |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured · higher tier | Named custom stages (First Draft, Review, Copyedit, Complete, Approved) set per entry (About Workflow Stages) |
| DB-4 — Telemetry per stage | Verified Native | "Stalled Entries by Workflow Stage": top 10 stages by entries not moved in 7+ days, bucketed 7-14, 15-29, 30-89, 90+ days, with Days in Stage per entry (Analytics for CMS). Queue depth and age by stage; not cycle time or rework Scope: Analytics dashboard. |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Stack audit log (date, user filter, action, module, title, entry version and language) plus named, compared entry versions; each stage transition is logged (Audit Log, Compare entry versions). No free-text reason field found; the audit-log API returns 30 days only, but Log Targets export audit, published and webhook logs hourly to the customer's own AWS, Azure or Google storage (changelog) |
| DB-6 — Deprecated and retired as real states | Unknown | No archived, deprecated or retired entry state found in the workflow, entry-status or release pages. Unpublish and delete exist |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Polaris/on-demand agents have a Confirmation mode: "Manually Approve holds each operation for your approval, and Auto runs operations without asking"; data-changing operations (create, update, publish, delete, post) can be held, read-only never (Run an agent on demand). One switch per run, not configurable per action type |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Same Confirmation mode, chosen per run ("You can switch mode mid-run"). Not per decision class |
| DD-3 — Escalation when a threshold is breached | Unknown◦ near-miss | "It asks rather than guesses. If your request can be read in more than one way... the agent asks you before it plans" (same source as the row above). Ambiguity prompt, not a threshold |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found |
| DD-5 — Record of automated versus human-approved decisions | Unknown | Execution log records who ran the agent, trigger, every step with input, output and tool; no field distinguishing approved from auto-run operations found (Execution log) |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | A Release Rollback reverts a deployed release (entries, references, assets) to the last known good state (changelog, 15 Jun 2026). It covers publish deployments, not agent actions, and nothing marks actions as reversible or not; stopping a run leaves it: "anything the agent has already changed stays changed" |
| DD-7 — Automation scoped per operation | Verified Configured · early access | "An agent does not have unlimited access to the platform. It can only act through the tools you explicitly give it"; entries, assets, taxonomy, releases and others are separate action sets (Components of an agent). Scoping is by tool selection per agent |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Agents have published versions and the Agent OS audit log records create, delete, enable, disable; no threshold configuration to version |
| DD-10 — Reliability reportable per decision class | Unknown◦ near-miss | Agents Analytics: successful and failed executions, tokens, model use, per agent; Polaris Analytics: tool execution summary, error distribution (Analytics for Agents). By agent, not by decision type; no override or validator-failure rate |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | Agents are named and tool-scoped, but a run "acts as the person who ran it... your permissions apply"; a tool can be bound to a fixed account ("Runs on the agent's account"). Permissions inherited from the user stay Inferred under our rule that one agent must have a name, a scope and its own permissions |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Configured · early access | Manually Approve holds each data-changing operation for the user's approval (same source as the row above). Reviewer is the person running the agent; triggered agents have no documented review step Scope: on-demand Polaris runs. |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss | "The audit trail names you" for on-demand runs. A separate execution log lists the agent, trigger and steps, and the Agent OS audit log records agent configuration events, but agent writes are not labelled as agent in the content audit log. FAQ: automation actions show as performed by "the account selected during automation configuration"; a service account is the customer-built workaround (Agent OS FAQs), which caps at I under the Assembled rule |
Optimizely
The whole Optimizely documentation index (454 pages read from Agent Platform, CMS (SaaS) and Collaboration) and the 2026 release notes for Agent Platform and CMS (SaaS). Optimizely Academy was not read. Output Evaluation, Execution Guardrails and Execution Advisor were released on 1 June 2026, input guardrails and agent version history on 29 July, and Virtual Teammates on 25 August.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Content approvals: items go to Ready for Review and appointed reviewers in a multi-step approval sequence approve before publish; statuses carry work from draft to approval (Approval sequences, Control the publishing process). Designer-built production workflows sit in the sibling CMP [delegated] |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | Role routing: reviewers are users and groups per approval step, work arrives under Tasks. A webhook can start an Agent Platform workflow agent when content is created, moved, deleted, published or scheduled (the event types listed contain no approval or stage event; "the agent picks the change up and runs the work that follows") (Send content events to Agent Platform); no page assigns an approval step or task to an agent. Same shape as Contentstack |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Native | Draft, Ready for Review, In Review, Ready to Publish, Rejected, Scheduled, Published, Expired (Control the publishing process, Publish versions of content) |
| DB-4 — Telemetry per stage | Unknown | No per-stage cycle time, queue depth or rework report found. A report lists Expired Pages; Tasks lists items by status without measuring them |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Change Log filters by date, category, action and changed-by user; the approval category records Approved sequence, Rejected step, Initial comment; versions can be compared (View the change log) |
| DB-6 — Deprecated and retired as real states | Verified Native | Expired is a status that keeps all versions (stop-publish date); deleted content goes to a restorable trash, not straight to deletion (Delete and restore content). DAM assets carry Active, Archived, Expired statuses [delegated: DAM] Scope: DAM for Archived. |
| DD-1 — Human-in-the-loop gates per action type | Verified Configured | "By default, a Virtual Teammate drafts and proposes, and you approve or redirect its work over Team Messages before it acts"; "allow specific actions to run automatically within the boundaries you set" (Virtual Teammates overview). The pages read describe the capability but not the settings screen Scope: Virtual Teammates. |
| DD-2 — Autonomy level per decision class | Verified Configured | Same page: autonomy is granted per specific action and adjustable "at any time", not as one global switch. Same caveat on the settings screen Scope: Virtual Teammates. |
| DD-3 — Escalation when a threshold is breached | Verified Configured | Execution Guardrails: runs deviating 50 to 70 percent from the learned baseline are flagged as Warning, over 70 percent as Failed, and extreme deviations are Terminated in Enforcing mode with an alert; Output Evaluation marks runs below a 75 to 95 percent baseline score as Failed (Configure Execution Guardrails, Configure Output Evaluation) Scope: Specialized agents. |
| DD-4 — Risk level as an input to routing | Verified Native | Execution Advisor reviews calls to sensitive tools (send email, publish, delete) before they run, with an inline Approved or Blocked verdict; "Optimizely maintains the list of sensitive tools. Agent builders cannot add or remove tools" (Execution Advisor). The reviewer is automated and the risk list is the vendor's Scope: Specialized agents; not configurable. |
| DD-5 — Record of automated versus human-approved decisions | Unknown◦ near-miss | The execution trace shows inline Approved or Blocked verdicts from Execution Advisor and the Logs list who triggered each run, but no page shows a record separating human approvals (Team Messages) from automated ones |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | Restore a deleted item from trash, restore a previous agent or guardrail version (creates a new version), pause a Virtual Teammate reversibly (Manage your Virtual Teammate). Nothing marks actions as reversible or not, or rolls back an agent's writes |
| DD-7 — Automation scoped per operation | Verified Configured | Jobs per Virtual Teammate can be turned on or off individually; tools per agent are selected; workflow agents are built per task (Manage your Virtual Teammate) |
| DD-8 — Uncertainty exposed by the system | Verified Native | Each run gets an Evaluation Score of 0 to 100 percent (LLM-as-judge) and a guardrail deviation figure; both show in the run row and execution panel (Agent activity logs). A quality and deviation score per run, not a per-decision confidence Scope: Specialized agents. |
| DD-9 — Decision authority as versioned configuration | Verified Configured | Baseline score is set from a list (75 to 95 percent); input guardrail sensitivity is High, Medium or Low; every guardrail change creates a version that can be restored; agent history records previous versions, "their modification dates and times, and the individuals responsible" (Specialized agent versions, Input guardrails overview). Per agent or guardrail, not per decision type |
| DD-10 — Reliability reportable per decision class | Verified Native | Per agent: Output Evaluation average score with Passed and Failed counts; Execution Guardrails summary of Passed, Warning, Failed, Terminated, Rescued and Unapproved runs. By agent (a task), not by decision type; no override rate Scope: Specialized agents. |
| AO-1 — Agents as named, scoped actors with permissions | Verified Configured | "Each Virtual Teammate has its own Opti ID account... and is flagged as a virtual user"; "It uses only the access you grant it, and nothing more"; access is a role per product instance plus per-item Read, Create, Change, Delete, Publish or Administer rights in CMS (Virtual Teammates overview) Scope: Virtual Teammates. |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native | Managers "direct, review, and approve the teammate's work"; the default is propose, then approve (Manage your Virtual Teammate). Execution Advisor adds an automated reviewer for sensitive tool calls Scope: Virtual Teammates. |
| AO-3 — Agent actions attributed in the audit trail | Verified Native | "In Optimizely products, it acts as itself, under its own Opti ID account"; "It keeps its own usage separate from human usage, so you can see what it does on its own". Caveat: the CMS Change Log page filters by changed-by user and does not itself mention virtual users, so the distinct label is by account and is not stated for that log Scope: Virtual Teammates. |
Sitecore
SitecoreAI user and developer documentation and Stream documentation (about 390 pages) and the Sitecore changelog feed. The changelog feed carries only the ten most recent entries, so no grade rests on release-note dating. Sitecore Learning was not read. Classic Sitecore XP documentation is a separate product and was not graded.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Workflows with states, commands and actions; items move through states in the Workbox, and a command can run actions or call a webhook (Workflow and security features, Workflows and the Workbox) |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | Role routing: three workflow access rights (Workflow State Delete, Workflow State Write, Workflow Command Execute) decide who sees and runs each state and command. A workflow can call a webhook, but no page assigns a workflow task or approval step to an agent; Agentic Studio workflow agents start from a manual trigger or a schedule (the Jobs page has a Scheduled Runs tab) |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Custom workflow states (for example Approved, Final); editing an item in a final state creates a new version and returns it to the initial state (Workflow and security features) |
| DB-4 — Telemetry per stage | Unknown◦ near-miss | The Workbox shows "the editing history of items in the workflow, each item's workflow state, and the number of items in each workflow state". A review queue with counts, not stage timing or ageing (a near-miss: a review queue is not stage timing) |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Versions can be compared; every Submit prompts for a comment "sent as a notification to the next reviewer"; the Workbox shows editing history (Compare two versions, The Workbox commands) |
| DB-6 — Deprecated and retired as real states | Unknown◦ near-miss | Publishing restrictions mark a version Not available on a schedule, removing it from Experience Edge while keeping the version (Schedule publishing availability). A publish flag, not a deprecated or retired lifecycle state. Stream tasks can be archived, which is not content |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Gates exist but are fixed by Sitecore: the Marketer MCP `move_component_on_page` "requires explicit user confirmation", `remove_component_on_page` checks affected A/B/n tests "and asks for confirmation" (tool reference); an agent with Read and write file access needs approval for file changes (Create a standard agent). Not configurable per action type |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Per agent, file access is Off, Read-only or Read and write; admins turn tools on or off for all chats and agents (Tools available to chats and agents). Scope by agent and tool, not by decision class |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. Confirmation prompts are tool-defined, not threshold-triggered |
| DD-4 — Risk level as an input to routing | Unknown◦ near-miss | `remove_component_on_page` checks for affected A/B/n tests before asking for confirmation, so an impact check shapes the prompt; the check is built into one tool and is not a risk setting |
| DD-5 — Record of automated versus human-approved decisions | Unknown | The Marketer MCP page lists "Audit logging for every operation and data access"; no page says whether it separates agent from human or approved from auto-run actions |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | The agent tool list includes "Jobs: View job details and revert operations"; no page describes what can be reverted or how. Components can be reverted to a previously staged or published snapshot |
| DD-7 — Automation scoped per operation | Verified Configured | Tools are switched on or off individually (Assets, Brand Kits, Briefs, Components, Content, Jobs, Pages, Personalization, Sites) and agents get only the tools and skills selected (Tools available to chats and agents) |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Agents are configured per tab; no threshold configuration or agent configuration history found |
| DD-10 — Reliability reportable per decision class | Unknown | The Jobs page lists runs with status, trigger and duration, and lets you delete run records; no reliability or override figures (Monitor processing jobs) |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | Agents are named and tool-scoped, but the MCP server works under "role-based access that follows existing Sitecore permissions", i.e. the connected user's. Agentic Studio roles (User, Editor, plus a Builder license) govern which people may run, configure or create agents (Manage users) |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native | "All actions follow Sitecore security, permissions, and approval workflows"; an agent update to an item in a Final or Approved state creates a new version rather than overwriting (Marketer MCP and Agent API overview, tool reference). Agent changes enter the existing human approval workflow |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss | Audit logging of every operation is stated, but no page says agent actions are labelled as agent rather than the acting user |
Adobe
Adobe's Experience League documentation for AEM Sites and Assets, CX Enterprise Coworker and Coworker Chat, read from Adobe's public documentation source repositories, plus AEM release and maintenance notes from 2023 to October 2026. The release notes carry little on agents, which ship under Coworker, so dating of agent features is thin. Adobe Learning was not read, and the Experience Platform Agent Orchestrator documentation was only skimmed.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | AEM Workflows run a series of steps on pages and assets: an editor reviews, then an administrator activates, each receiving a work item (Working with workflows); asset approval is a separate flow in Assets |
| DB-2 — Task routing by role and to AI agents | Verified Configured | Role routing: work items go to named participants and groups in the Workflow Inbox. Routing to an AI service: translation projects use the same workflows with an LLM as a "third-party translation service", set as the default translation method ("Agentic Translation Configuration") (AI translation integration). The agent route is documented for translation only Scope: translation only. |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Native | Assets carry a status of Approved, Rejected or No Status, which "governs and controls the downstream consumption" of the asset (Manage asset status); pages have versions and publish states |
| DB-4 — Telemetry per stage | Unknown◦ near-miss | Administration lists workflow instances as Running, Archive (completed) and Failures, each with an Open History view (Administering workflows). Instance history, not stage timing or queue depth |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Workflow history per instance; page versions with restore; asset versions and annotations (Page versions) |
| DB-6 — Deprecated and retired as real states | Verified Configured | Any asset can be given an expiration date, "a built-in way to manage the lifecycle of digital assets and flag content that should no longer be used"; an Expired status overrides Approved or Rejected and can be filtered on, so the asset stays in the repository (Manage asset status) Scope: Assets view. |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Coworker Chat Plan mode: "proposes a plan and waits for your approval before it carries it out", recommended "for complex tasks or tasks that change data" (Review a plan before Coworker Chat acts); the AEM Onboarding capability lists "Review and confirm changes before write operations are performed". A per-conversation switch, not per action type |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Plan mode on or off ("When Plan mode is off, Coworker Chat starts the work right away"); no per-class setting |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. The "checks that run before an action executes" in the governance summary are not described as threshold-based |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found. A customer can build an Activation Quality Gate skill with their own pass/fail rules (Build and run a quality gate skill); that is Assembled and capped at I |
| DD-5 — Record of automated versus human-approved decisions | Unknown | A "full audit trail" is claimed in the Coworker overview; no page describes whether it separates human approvals from automated steps |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | Version restore exists for pages, assets and Coworker-for-teams emails; nothing marks agent actions as reversible or rolls them back |
| DD-7 — Automation scoped per operation | Verified Configured | Agentic capabilities are separate skills per task (Content Create, Content Update, Onboarding, Discovery, Optimization, Brand Governance); administrators install approved plugins and "govern access to skills and connected tools", and decide whether users may install or remove plugins (Managing plugins and user access) |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Skills are iterated against a baseline; no threshold configuration or recorded change history found |
| DD-10 — Reliability reportable per decision class | Unknown◦ near-miss | The Agentic AI Monitoring dashboard shows usage, users, feedback ("signals on response quality and user satisfaction") and AI credits for governance stakeholders (Agentic AI Monitoring). Adoption and sentiment, not reliability by decision type |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | "Permissions inherited from your Adobe organization"; the Marketing Agent "inherits" the user's permissions. Skills and plugins are named and admin-governed, but an agent has no identity of its own |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Configured | "You delegate the outcome and stay in control through review and approval" and Plan mode approval (Coworker Chat overview); the AEM Governance Agent validates content against brand rules and is read-only on permissions ("it diagnoses permissions and recommends changes, but it does not modify access control lists") Scope: Coworker. |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss | "A full audit trail" is claimed; the one concrete audit description (data-lake retention policy changes) records "who made each change, when it occurred, and what was modified". Nothing says agent actions are labelled as agent |
Kontent.ai
Kontent.ai Learn (299 pages of documentation, lessons and product updates) and its dated product updates feed (403 entries, 2019 to 12 October 2026). Aiko and expert agents are documented under Innovation Lab, released on 11 February and 12 March 2026. The Management API reference was not read in full.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Workflows have steps, transitions and per-step role permissions, scoped by content type and collection ("marketing and legal content can have different workflow steps, transitions, and role permissions") (Workflows) |
| DB-2 — Task routing by role and to AI agents | Verified Configured · lab | Role routing: a workflow step can be limited to specific roles, and tasks and contributors are assigned per item. Agent routing: an expert agent starts "when content reaches a workflow step" and can be permitted to move items through workflow steps (Expert agents). The only vendor so far whose own docs tie an agent trigger to a workflow step Scope: expert agents in Innovation Lab. |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Custom workflow steps alongside predefined steps that "are always present and cannot be removed"; the page names Archived among the steps, and the lifecycle lesson describes archiving as the automatic result of unpublishing (Workflows) |
| DB-4 — Telemetry per stage | Verified Native | Content progress by workflow category (items edited in the last 90 days), tasks done on time, items published on time, and a late-tasks list (Mission Control). Per-state counts and on-time rates; not stage cycle times Scope: Mission Control. |
| DB-5 — Traceability: who changed what, when and why | Verified Native | "Kontent.ai keeps a version history for every content item, so you can see what changed, who changed it, and when"; versions can be compared and restored; the audit log keeps 90 days (Versioning, Audit log). Each expert agent run also has a summary of "what the agent did and why". No free-text reason field |
| DB-6 — Deprecated and retired as real states | Verified Native | Archived is a workflow step (named on the Workflows page); a published item is archived automatically on unpublish, and scheduled unpublish gives content expiration (End of the lifecycle) |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Aiko "asks for confirmation before publishing"; the show me first pattern and "Ask Aiko what it would do. Review the proposed changes before they happen" are advised practice (Aiko, The safety layer). The publish confirmation is built in; expert agents run without confirmation ("expert agents can't ask follow-up questions") |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Each expert agent is given only the permissions ticked for it: read, edit (including workflow moves and publish or unpublish), create, delete content; read and edit assets. That scopes what it can do by action class; it is not an approve-or-auto level |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. The only limit is a capacity safeguard ("if many complex agentic runs occur simultaneously") |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found. The safety page lists high-risk operations (bulk changes, publishing, deleting, workflow moves, content-model changes) as guidance, not as a system setting |
| DD-5 — Record of automated versus human-approved decisions | Verified Native · lab | Every audit entry carries an actor type: User, Aiko agent (shown as the person's name "via Aiko"), Expert agent ("made the change automatically, according to its instructions"), Integration, System (Audit log). Separates automatic from user-directed changes; it does not record an approval as such Scope: Audit log. |
| DD-6 — Reversibility as a property of an action | Verified Native | Version history lets you "always restore any previous version" and "changes made by agents are recorded in the content item's version history the same way as changes made by users"; the safety page says "Removing content is irreversible. Deleted items may not be recoverable" (Versioning, The safety layer). Reversibility is stated, in guidance, rather than marked on each action |
| DD-7 — Automation scoped per operation | Verified Configured · lab | Each expert agent is limited to a content type, language and collection, and given its own permission set; one agent per task ("Translates blog posts to French", "Fill in SEO and GEO metadata") (Expert agents) |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Agent instructions and permissions are editable; no version history or threshold configuration for agents found. The 28 May 2026 note says existing agents were migrated to the new permissions model with a confirmation callout |
| DD-10 — Reliability reportable per decision class | Unknown◦ near-miss | Each expert agent has a run list (item, status, time) with a per-run summary; AI credit usage can be exported. No reliability rates by agent or decision type |
| AO-1 — Agents as named, scoped actors with permissions | Verified Configured · lab | Expert agents have a name that "appears in content item version history and in the audit log", a scope (content type, language, collection) and "a dedicated permissions model instead of Management API keys" with granular permissions on content items and assets (Expert agents, product update 28 May 2026). Aiko, by contrast, works "respecting your project's structure and permissions" and access to it is a role permission |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native · lab | "If your process requires Draft → Review → Approved steps before publishing, Aiko doesn't bypass those gates either"; an expert agent can be set to run "before content moves to marketing review", so its output enters the normal review step (The safety layer, Expert agents) |
| AO-3 — Agent actions attributed in the audit trail | Verified Native · lab | "Every change in the audit log is attributed to an actor type that shows who or what made the change"; the log can be filtered by actor type and by agent; agent changes appear as separate versions labelled with the agent's name (Audit log) |
Storyblok
The whole Storyblok documentation site (596 pages, including the Management API reference) and the product changelog (January 2025 to 15 October 2026). Agents are part of Storyblok Labs and described as still in beta, dated 10 September 2026. Storyblok Academy was not read.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Stages with per-stage behaviour: "who can edit and publish stories in this stage, automatic progress to the next stage"; in the Default workflow only Ready to Publish stories can be published (Workflows) |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | Role routing: each stage move can "Assign a person or role" with a due date and email notice. "Workflow stage changes can trigger a webhook" into FlowMotion, which "turns every content event (create, update, publish, approve, translate, etc.)" into automation (FlowMotion); scheduled custom agents run on a clock, not on a stage. No page ties a Storyblok agent to a workflow step |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Default stages None, Drafting, Reviewing, Ready to Publish, editable and extendable on some plans (Workflows) |
| DB-4 — Telemetry per stage | Unknown | The Workflow changes tab is a chronological list of who moved a story and when; no stage counts, ageing or cycle times found |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Stage comments, a chronological workflow-change list, story version history with compare and restore, and the Activities app (Workflows, Activities); the Approval app lets a reviewer "review the changelog of a content item before approving it" |
| DB-6 — Deprecated and retired as real states | Unknown◦ near-miss | Stories can be unpublished and deleted content restored from the Activities app, but no archived or retired state; the scheduling object only has a `publish_at` date (no scheduled unpublish) (Story scheduling object) |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | "Read actions run without confirmation, but any action that writes content or changes configuration requires manual approval" (Agents). Two fixed classes, read and write; not configurable, and the page does not say how scheduled agents handle the write prompt |
| DD-2 — Autonomy level per decision class | Unknown | No autonomy setting found. Access is a role permission (Use agents, Manage agents) |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found beyond the read versus write split above |
| DD-5 — Record of automated versus human-approved decisions | Unknown | Nothing found; changes made by an agent are attributed to the user (see AO-3) |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | Story versions can be compared and restored and deleted content restored, but nothing marks agent actions reversible or not. The MCP page notes the CLI "offers dry runs" and is better for bulk work |
| DD-7 — Automation scoped per operation | Unknown◦ near-miss | An agent has 23 tools (12 read, 11 write) for every user with the role permission; a custom agent saves instructions, not a narrower tool set |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found. The MCP page warns results are "non-deterministic and unsuited for repeatable, high-volume work" |
| DD-9 — Decision authority as versioned configuration | Unknown | No thresholds or agent configuration history found |
| DD-10 — Reliability reportable per decision class | Unknown | AI credit usage is shown; no reliability reporting. Each scheduled task shows "its frequency, activation status, and latest run" |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | Custom agents are named and can be shared, but "agents work within a single space and depend on the role and permissions of the user who prompts it". Permissions inherited from the user stay Inferred |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native · beta | The writing actions listed (create, update, publish, unpublish, move, duplicate, tag, delete, create folder, translate) need manual approval inline; the reviewer is the person prompting (Agents). Stage-based review applies to anything an agent writes into a story |
| AO-3 — Agent actions attributed in the audit trail | Unknown | Documented the other way: "any change it makes is attributed to you and appears in the space's Activity feed" (Agents) |
Hygraph
The whole Hygraph documentation site (355 pages, including content workflows, audit logs, permissions, versioning, scheduling, AI Agents, AI Guidelines and the MCP server). AI Agents are available on the Enterprise plan only. No dated release-note archive was found in the documentation.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Admin-built workflows with steps, per-step role access, edit permission, a "Return to" step and "Publish to" stages; publishing happens only by moving an entry into a step that has a Publish to stage (Content workflows) |
| DB-2 — Task routing by role and to AI agents | Verified Configured · higher tier | Role routing: each step lists the roles that may move it. Agent routing: "If a workflow step is assigned to an AI agent, the agent automatically starts processing as soon as an entry moves into that step"; an agent configured for workflows is attached to a step (Content workflows, Set up AI Agents). Routing is by step and role, not named assignees |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Custom workflow steps with their own permissions, plus system stages DRAFT and PUBLISHED and plan-dependent custom content stages (Content stages) |
| DB-4 — Telemetry per stage | Unknown◦ near-miss | Editors can filter and track content by workflow stage, and the content table shows agent status (Pending, Ready for review, Failure). No counts by stage, age in stage or cycle times found |
| DB-5 — Traceability: who changed what, when and why | Verified Native · higher tier | The audit log records create, update, delete, publish and unpublish with timestamp, entity, environment and "TriggeredBy" (member email or token); versions of published content can be compared and restored (Audit logs, Versioning). Caveats: "We won't include the payload for content changes"; DRAFT content is not versioned; there is no reason field, only workflow comments Scope: Audit Logs Enterprise. |
| DB-6 — Deprecated and retired as real states | Unknown◦ near-miss | Entries can be scheduled for unpublish, singly or in a release; "the Unpublish action moves content to the DRAFT stage" (Scheduled publishing). No archived or retired state found; a custom stage or workflow step could be built to hold one |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Fixed, not configurable: agents "cannot delete entries, unpublish content, or modify your project structure", and every agent run ends in a read-only review state (AI Agents). Over MCP, delete and unpublish are unsupported, but a Content or General MCP token can publish with no Hygraph-side gate (the Claude connector asks per tool call; that is the client's prompt) |
| DD-2 — Autonomy level per decision class | Unknown | No setting found. Every agent proposes and a person reviews; the only choice is manual run versus workflow step |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. A failed run shows as Failure in the content table |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found beyond the fixed exclusion of delete and unpublish |
| DD-5 — Record of automated versus human-approved decisions | Unknown◦ near-miss | Per-field approve or revert is built into the review; the KPIs page keeps a run table with status, result and duration. The pages do not say the reviewer, the time of approval or the fields reverted are recorded, and the audit log lists no agent trigger type |
| DD-6 — Reversibility as a property of an action | Verified Native · higher tier | "Reverting all fields returns the entry to its exact pre-agent state"; the agent's changes "are already written to the entry" and wait for sign-off, and the most destructive actions are excluded for agents and MCP. Caveat the setup page gives itself: the Translator "overwrites all existing content for the selected locales" (AI Agents, Set up AI Agents) |
| DD-7 — Automation scoped per operation | Verified Configured | One agent per task type (SEO & GEO Expert, Translator, Content summarizer), each limited to the models and fields it is configured for ("Agents only write to the fields and models you explicitly configure"); MCP tokens come in fixed permission sets (AI Agents) |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Agents and guidelines are editable and can be switched off; no version history or threshold configuration found |
| DD-10 — Reliability reportable per decision class | Unknown◦ near-miss | AI Hub KPIs per agent: runs, success rate, last run, average duration, tokens, with a token trend and a run table. "Success rate" is "runs that completed without errors", so it measures completion and not the quality or acceptance of output; no revert or override rate |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | Agents are named, configured per model and trigger, and have their own permissions (create, update, read agent config: Admin; trigger a run: all roles). But "agents respect your project's existing role and permission configuration" and no agent identity is described. Over MCP, a PAT is a distinct token identity with a fixed permission set, but it stands for the person's external assistant, not a Hygraph agent |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native · higher tier | "The review step means no agent output reaches your published content without an editor sign-off"; side-by-side diff, approve or revert per field, the entry stays read-only until the review is complete; workflow agents are advised to sit before a human review step (AI Agents). Agent runs started over MCP land in DRAFT and "MCP does not publish agent output" |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss | The audit log's trigger types are User, PAT, Open, App Token and Third Party; none is an agent. The AI Hub keeps a separate run table per agent, which is not the content audit trail |
Acquia
Acquia Source CMS and Acquia Source documentation (197 pages, including 60 dated release notes from 16 September 2025 to 15 October 2026), the Acquia AI pages (23 pages, including governance and control, modes and the approval workflow) and the developer portal (MCP server, authentication). Scope is Source CMS, Acquia AI and the bundled digital asset management integration; Acquia's self-managed hosting product is not graded. Acquia Academy was not read.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | Workflows with states and transitions, and permissions "which roles can perform specific transitions" (for example only a custom administrator role may move content from In Legal review to publication) (Content workflows, Managing workflows). Caveat: "available only for CMS content and not for Drupal Canvas pages" Scope: CMS content only. |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | Transitions are gated by role (Content moderation permissions per transition). No task assignment or inbox found, and Acquia AI starts from a person's request in chat; nothing sends work to an agent when content reaches a state. Over MCP, `update_node` can request a state change (`moderation_state`) under the same permissions |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Custom states (Draft, Review, Published as examples), each with a Published and a Default revision flag, assigned per content type (Managing workflows) |
| DB-4 — Telemetry per stage | Unknown | Nothing found |
| DB-5 — Traceability: who changed what, when and why | Verified Native | Content has revisions and a Revision log message on every save; entries carry author and changed date (Media library, Content model, Source CMS product guide). Caveat: no site-wide audit log is documented, and Canvas page drafts are auto-saves Scope: revision history extension 90 days on the Standard tier. |
| DB-6 — Deprecated and retired as real states | Verified Configured | The scheduler sets "Unpublish On" and an Unpublish State, "for example, Archived"; the example Content publisher role may "publish, archive, and delete" (Enabling content scheduling, Roles and permissions). The Archived state is an example the customer builds, not one the product ships |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Fixed two-stage approval: "The agent proposes a plan and takes no action without human approval. Publication requires a second, separate approval" (Governance and control management). One pattern for every task; not set per action type. Over MCP no such gate exists beyond workflow permissions: `update_node` can request published, and Canvas edits land as drafts until `publish_auto_saves` is called Scope: Acquia AI Work mode. |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Two modes: Advisor (read-only, user identity) and Work (acts after approval, scoped agent identity) (Modes in Acquia AI). A choice per request, not per decision class |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. Documented as not provided: "Does not perform continuous monitoring" and "cannot submit a support case" |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found. The governance check returns a score out of 100 with a passing mark of 80, but "scores below 80 do not prevent publication" (Run a governance check) |
| DD-5 — Record of automated versus human-approved decisions | Unknown◦ documented absent The vendor's own words, read 22 October 2026 | Stated absent: "No customer-visible record of agent activity is provided"; "Acquia retains records of agent activity for internal operational purposes. This release provides no customer tools to review or export agent activity records" (Governance and control management, Data handling) Scope: Acquia AI Work mode, "this release". |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss◦ documented absent The vendor's own words, read 22 October 2026 | Drafts can be discarded (`discard_auto_saves`, with a documented leftover for new menu items), and content has revisions. For approved agent changes: "No automatic reversal: A revert operation requires the same approval process as any other change" (Governance and control management) Scope: approved agent changes; drafts can be discarded. |
| DD-7 — Automation scoped per operation | Unknown◦ near-miss | Acquia AI tasks are fixed types (build or update a page, governance check and fix, find DAM assets); the fix scope is "a reviewed set of common accessibility errors" on custom components. Not configurable per operation. MCP clients can be given minimal scopes, but the dev portal reports "scope gating was not observable in MCP server verification" |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found beyond the governance score, which grades the page and not the agent |
| DD-9 — Decision authority as versioned configuration | Unknown | The agent role "cannot change" on Source CMS; "Source CMS provides no edits to the agent role or permission set". The agent access policy in the July 2026 Acquia AI module is for Drupal sites building their own agents and is outside this scope |
| DD-10 — Reliability reportable per decision class | Unknown | AI credit usage and balance only (AI credits and usage); no reliability reporting |
| AO-1 — Agents as named, scoped actors with permissions | Verified Native | "The agent holds a dedicated Agents Team role, separate from user roles, and never inherits permissions from the requesting user"; an Agent (bot) account is added to the organisation and "by default... has no access to any application or site" until an administrator assigns it (Governance and control management, Agent (bot) account). Caveat: on Source CMS "the agent holds a fixed member role", so the only control is which sites it may reach, and the agent's reach can exceed the requesting user's Scope: Acquia AI Work mode. |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native | Approve, change or reject the plan; the agent works as a draft; "Publication requires a second, separate approval", with a Slack notice when the result is ready for review and approval done in Acquia Source (Delegate and approve a task) Scope: Acquia AI Work mode. |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss◦ documented absent The vendor's own words, read 22 October 2026 | The agent has its own identity ("Work mode tasks run under the agent identity instead of a user account"), but the pages do not say a content revision names it, and the documentation states “No customer-visible record of agent activity is provided” (Governance and control management). Over MCP, "attribution follows the credential": a browser-authorized agent "acts as its approver", while a client-credentials token "acts as the client's own identity" (MCP guide) Scope: Acquia AI Work mode; the statement does not cover the MCP route. |
Contentful
Contentful developer documentation (MCP server, workflows, AI Actions, automations, snapshots, roles, scheduled actions, audit logs), the developer changelog from January 2025 to 20 October 2026, and Help Center pages on the Content Operations Agent, workflows, automations, AI Actions and versioning, which were read by hand because Contentful's Help Center blocks automated reading. Contentful Personalization is not included.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured · higher tier | A workflow definition is an ordered list of up to 20 steps, applied to content types, with per-step permissions and actions, an optional "strict neighbour" mode and automatic start on entry creation; several workflows can run on one entry (Workflow definitions, Workflows) |
| DB-2 — Task routing by role and to AI agents | Inferred Assembled · higher tier | Role routing: a step can create a task assigned to a user or team with a due date, and step permissions decide who may move or edit. AI routing: an automation can start on a workflow trigger limited "to a specific workflow step", run an AI Action, and move the workflow on; the Help Center example moves a workflow "from Draft to Translation to translate multiple fields with AI" and then to "Ready for review for a translator to check" (Automation actions). The changelog (31 Mar 2025) also claims AI Actions can be added directly to workflow steps; the API reference lists only email, task and Slack as step actions, so the automation route is the verified one Arrives as Assembled: the route from a workflow stage to an AI Action is built by an administrator from generic Automation nodes (trigger, condition, AI Action, workflow action), so it is capped at Inferred; a direct AI-Action-in-workflow-step setting is claimed in the changelog but not confirmed in the API reference. |
| DB-3 — Explicit lifecycle state beyond draft and published | Verified Configured | Custom workflow steps with their own colours and rules, plus archived entries and assets, and Timeline releases for scheduled states (Workflows steps management) |
| DB-4 — Telemetry per stage | Unknown◦ near-miss | The Content Insights app (Marketplace, 19 Feb 2026) shows "publishing velocity, average time to publish, and content that needs updates". Overall, not per workflow step |
| DB-5 — Traceability: who changed what, when and why | Verified Native · higher tier | A snapshot is taken on every publish with the user and time, and fields or whole entries can be compared and restored (Versioning FAQ). Audit logs record actor (user or app), action and entity, delivered to the customer's storage (Audit logs). Caveats: snapshots only on publish, only on the master environment; assets, webhooks and roles are not versioned; no reason field |
| DB-6 — Deprecated and retired as real states | Verified Native | Entries have archive and unarchive (API and MCP tools); an asset can be archived only when unpublished, and archiving removes it from the delivery network within 24 to 48 hours (Archive an asset); scheduled unpublish exists via scheduled actions and releases. Entry archiving is evidenced by the API and MCP reference, not a Help Center page |
| DD-1 — Human-in-the-loop gates per action type | Verified Configured · beta | "The agent never publishes, archives, or changes a content type without your explicit approval"; multi-entry changes are proposed, surfaced for review and applied only on approval; bulk AI Action runs "require your approval before they execute". Caveat: these gates belong to the agent and to bulk AI runs. An admin-built automation has Publish, Unpublish, Archive and Delete entry actions with no approval step of its own (Automation actions). Admins add policies with Allow or Deny rules per action (read, create, update, publish, unpublish, delete, archive, unarchive), optionally per content type (Content Operations Agent). For MCP, an admin-set allow-list picks tool categories read-only or read/write per environment Scope: Content Operations Agent (beta). |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | Allow and deny policies and read-only versus read/write per MCP tool category set what an agent may do; the three gated actions (publish, archive, content-type change) always need approval and cannot be switched to automatic. No approve-or-auto setting per class |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found. The agent runs pre-publish validation and "if any content type rule fails it reports the failure and does not publish" |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found |
| DD-5 — Record of automated versus human-approved decisions | Unknown◦ near-miss | Audit events carry an AI Actions enrichment (invoking user, entry and field, AI Action id and version, model and provider) and a Bulk Actions enrichment (action and affected entries); AI Runs lists pending and reviewed suggestions that can be applied, dismissed or restored. The pages do not say a human approval is recorded as such |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | Snapshots allow restore of entries; AI suggestions can be restored; content types are versioned with no interface. Nothing marks agent actions reversible or irreversible |
| DD-7 — Automation scoped per operation | Verified Configured · higher tier | AI Actions are defined per task and can be assigned to specific content types and fields, with default and locked variable values (18 May 2026); agent policies scope by action and content type (AI Actions: roles and permissions, changelog) |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found. AI Runs shows "reasoning and change previews" for suggestions, which explains a change and is not a confidence signal |
| DD-9 — Decision authority as versioned configuration | Unknown◦ near-miss | AI Actions are published configuration objects with versions (the audit event records the version used), and who may create, modify, invoke and publish them is set per role. Agent policies are not shown as versioned |
| DD-10 — Reliability reportable per decision class | Unknown | Usage dashboards for AI Actions (consumption); no reliability reporting |
| AO-1 — Agents as named, scoped actors with permissions | Inferred | The agent is installed per space and environment, is off by default for each user, and has admin policies; but "permissions are inherited from your existing user role" and it can only do what both its policies and the installing user's role allow. No separate agent identity is described. Remote MCP uses each user's own OAuth identity Scope: Content Operations Agent (beta). |
| AO-2 — Supervision: agent output reviewable by another actor | Verified Native · beta | Approval before publish, archive or content-type change; AI Actions output "remains fully reviewable ... inspect, edit, and approve results before publishing"; suggestions are applied, dismissed or restored in AI Runs. Bulk runs are saved as reviewable AI Runs: "approve, decline, or adjust" in a diff view, with edit permission needed to apply, a check for entries changed during review, and results kept for 7 days (Run AI Actions in bulk). The reviewer is a person with view permission, not necessarily the requester Scope: Content Operations Agent; AI Runs. |
| AO-3 — Agent actions attributed in the audit trail | Unknown◦ near-miss | AI Action invocations are labelled in the audit log with the invoking user and model, and actors are typed User or App. The pages do not say the Content Operations Agent's actions are labelled as agent |
RWS Tridion
Tridion Sites 10 documentation pages read by hand (functional overview, workflow, security and access management, publishing and deployment, Semantic AI, unpublishing) because docs.rws.com blocks automated reading, plus the earlier 9.6 workflow page and two RWS marketing pages. Versioning, auditing, workflow sub-pages and release notes were not read, so most cells are Unknown.
| Capability | Grade | Evidence |
|---|---|---|
| DB-1 — Workflow orchestration across production and approval | Verified Configured | "Workflow ... ensures that changes to certain item move through a prescribed sequence of steps. A workflow process typically includes one or more review steps by authorized gatekeepers." Triggered by item type on create or edit, or by putting items in a Bundle that goes through approval together; processes are drawn in Visio Workflow Designer (Workflow). Also task, programmatic and classic editing workflow (9.6 page) |
| DB-2 — Task routing by role and to AI agents | Unknown◦ near-miss | "Authorized gatekeepers" review, and a default Task process has perform and review activities; how work is assigned to people or groups is on sub-pages not read. Programmatic workflow can start a process from custom code through the Core Service API. No page routes work to an AI agent |
| DB-3 — Explicit lifecycle state beyond draft and published | Unknown◦ near-miss | Position in a workflow process is a state, and a bundle or editing workflow is exclusive per item ("An item cannot be in editing workflow and Bundle workflow at the same time", 9.6). No named lifecycle states found in the pages read |
| DB-4 — Telemetry per stage | Unknown | Not found in the pages read |
| DB-5 — Traceability: who changed what, when and why | Unknown | Versioning, history and audit pages were not read |
| DB-6 — Deprecated and retired as real states | Unknown◦ near-miss | A Component can be unpublished now or on a scheduled date and time, from chosen Web sites and optionally child publications, with status in the Publishing Queue; unpublishing can fail or succeed partly (Unpublishing a Component, pasted help topic; the pasted Publishing and deployment page describes the delivery pipeline only). No retired or deprecated item state found |
| DD-1 — Human-in-the-loop gates per action type | Unknown◦ near-miss | Smart Tagging works in two modes: request tag suggestions for one item "and then reviewing and changing the tags, as needed", or "in a bulk, fully automated way by requesting automatic classification for a group of selected items (changing the tags later is still possible)" (Tridion Semantic AI). A review-or-automatic choice, for tagging only Scope: Optional Semantic AI package. |
| DD-2 — Autonomy level per decision class | Unknown◦ near-miss | The same choice, suggest or fully automated, is made per request for one action class (classification). No setting for other classes, and AI output is not described as entering a workflow Scope: Optional Semantic AI package. |
| DD-3 — Escalation when a threshold is breached | Unknown | Nothing found |
| DD-4 — Risk level as an input to routing | Unknown | Nothing found |
| DD-5 — Record of automated versus human-approved decisions | Unknown | Nothing found; auditing pages not read |
| DD-6 — Reversibility as a property of an action | Unknown◦ near-miss | Automatic tags can be changed afterwards ("changing the tags later is still possible"); nothing marks actions reversible or rolls back a bulk run |
| DD-7 — Automation scoped per operation | Unknown | Smart Tagging is one scoped operation; no per-operation configuration found |
| DD-8 — Uncertainty exposed by the system | Unknown | Nothing found |
| DD-9 — Decision authority as versioned configuration | Unknown | Nothing found |
| DD-10 — Reliability reportable per decision class | Unknown | Nothing found |
| AO-1 — Agents as named, scoped actors with permissions | Unknown | No agent identity described. Access Management manages "client credentials for applications, end users and service accounts" and maps IdP groups to Content Manager roles (Security and access management), which is the mechanism an agent identity could use; no page says it does |
| AO-2 — Supervision: agent output reviewable by another actor | Unknown◦ near-miss | Suggested tags are reviewed by the requesting user before they apply; whether AI output enters the review steps of a workflow is not stated |
| AO-3 — Agent actions attributed in the audit trail | Unknown | Nothing found; auditing pages not read |
What to ask each vendor
If you're evaluating any of these ten platforms, the grades above are a starting point for your own conversation, not a substitute for it. Worth knowing before you ask: a sales rep telling you "yes, we do that" on a call isn't actually stronger evidence than what's graded Unknown here — it's weaker than even Vendor-claimed, since a marketing page is at least public and citable, and a verbal answer isn't. When you ask about any capability below, ask specifically for a link to developer or technical documentation describing the mechanism — the same standard we held every vendor to. If they can produce it, you've effectively verified it for your own evaluation. If they can't, or the answer stays vague, that's worth weighing on its own.
One question for all ten vendors
- Show me, in documentation, where an agent's action appears in the audit log and how it is labelled, compared with the same action by a person. (AO-3)Only two of the ten (Optimizely, Kontent.ai) documented this.
Optimizely
the one vendor with the decision layer documented, so ask to see it working:
- The settings screen where autonomy is granted per action for a Virtual Teammate, and where it is withdrawn. The pages we read describe the idea without the screen. (DD-1, DD-2)
- Whether Execution Guardrails, Output Evaluation and the sensitive-tool review apply to Virtual Teammates too, or only to specialized agents. (DD-3, DD-4, DD-8)
- Whether a Virtual Teammate's own account shows up by name in the CMS change log, not only in the agent platform's activity log. (AO-3)
- Whether an approval step in a workflow can be assigned to an agent, and how an agent is sent work when content reaches a stage. (DB-2)
Kontent.ai
strong documentation, and the agents sit in an Innovation Lab:
- Which plans include the Innovation Lab agents, and what moves them out of the lab. (availability)
- Whether the Management API labels a change made by an expert agent differently from one made by Aiko, and where. (AO-3, DD-5)
- Whether an agent can be limited by risk, for example a publish only after a person confirms, as a setting and not only as advice. (DD-1, DD-2)
- What stops an agent at a threshold, such as many changes in one run. (DD-3)
- Any reporting on how often agent changes are accepted, reverted or edited. (DD-10)
Acquia
the strongest agent identity, with the record the documentation says is missing:
- Whether a content revision made by the Agent (bot) account carries that account's name, and where an administrator can see it. (AO-3)
- When customer-visible activity records and automatic reversal of approved changes are planned, in the product roadmap documentation. (DD-5, DD-6)
- Whether the Source CMS agent role can be narrowed per site or per content type, and not only by choosing which sites it reaches. (AO-1, DD-7)
- Whether Acquia AI can be started by a workflow step, not only by a person's request. (DB-2)
- What the MCP server's "experimental" status means for support, and whether scope settings on API clients are enforced, since the developer portal says it could not observe scope gating. (DD-7)
Hygraph
the agent is a workflow step; ask about the record and the limits:
- Which actor type an agent's write carries in the audit log. The trigger types listed are User, PAT, Open, App Token and Third Party. (AO-3)
- Whether the review step records who approved or reverted each field, and when. (DD-5)
- Whether an agent can be set to act with less review in a low-risk step, or whether every run always stops for review. (DD-2, DD-4)
- Which plan includes AI Agents and the workflow features around them (the documentation says Enterprise). (availability)
- Any figure for how often agent output is accepted, beyond the success rate, which counts runs that finished without errors. (DD-10)
Contentful
the audit trail for AI Actions is documented; the new agent and the workflow link are not yet:
- The Help Center page on adding AI Actions to a workflow step. The changelog says it is possible; the API reference lists only email, task and Slack as step actions. (DB-2)
- Whether Content Operations Agent actions are labelled as the agent in the audit log, as AI Actions runs are. (AO-3)
- Whether the agent can have its own identity, or always acts with the installing user's role plus the admin policies. (AO-1)
- Whether an automation that publishes or deletes entries can be made to wait for approval. (DD-1)
- When the Content Operations Agent leaves beta, and what changes. (availability)
Contentstack
Agent OS has an approval mode; ask about the rest and the launch status:
- Which Agent OS features are generally available and which are still Early Access, since some pages say Early Access while the changelog dates the launch to 1 June 2026. (availability)
- Whether an agent's writes are labelled as the agent in the content audit log. The pages say the audit trail names the person. (AO-3)
- Whether an agent run can be started by, or assigned to, a workflow stage. (DB-2)
- Whether Confirmation mode can be set per action type, and who can change it. (DD-1, DD-2)
- Whether anything stops a run that is going wrong beyond the person pressing stop. (DD-3)
Sitecore
agents run as the user; ask what the log shows:
- Whether the audit log labels agent actions as agent, rather than as the connected user. (AO-3)
- What the "revert operations" tool in Jobs reverses, and how. (DD-6)
- Whether an agent can change a workflow state through the Agent API, and whether approval states still apply. (DB-2)
- Which confirmations are built in (for example removing a component) and which can be set by an administrator. (DD-1, DD-2)
- Release notes covering the last 24 months for Agentic Studio. (dating)
Adobe
approval is documented; the record and the routing are thin:
- Whether the Coworker audit trail labels each agent step, and where the "full audit trail" in the overview is documented. (AO-3, DD-5)
- Whether Plan mode can be required for certain actions by an administrator, not chosen by each user. (DD-1, DD-2)
- Whether agent-led work other than translation can be routed through AEM workflows. (DB-2)
- Release dating for Plan mode and the AEM Governance agent. (dating)
Storyblok
agents are a Labs beta since 10 September 2026:
- Whether a scheduled custom agent asks for approval before it writes, or runs unattended. (DD-1)
- Whether an agent's change can be shown as the agent, not only as the person who set it up. (AO-3)
- Whether an agent's tools can be narrowed to some of the 23, per agent. (DD-7)
- When Agents leave Labs, and which plans include them. (availability)
RWS Tridion
our access was limited, so these are the questions our pages could not answer. Ask for the Tridion Sites 10 documentation on each:
- Whether Smart Tagging's automatic bulk classification records who ran it and which tags it added, and whether those tags enter workflow review. (DD-1, AO-2, AO-3)
- Whether the ai12z copilot has its own account with set permissions in Tridion, and what it is allowed to change. (AO-1)
- The Tridion Sites documentation on versioning, history and auditing. (DB-5)
- How a Component is retired in practice, beyond scheduled unpublish. (DB-6)
- How work is assigned in workflow activities, and whether an agent could be a participant. (DB-2)
Licensed, Enabled, Practised
Want to know if this is true for your own stack?
Nine of these ten vendors document a person approving an AI agent's work, and only one documents how that agent's autonomy, risk and uncertainty are controlled, so how far you can safely let an agent act in your content operation depends on which of these platforms you use.
A Content Value Chain diagnostic runs this same evidence-graded check — the same capabilities, the same four evidence grades — against what your organization is actually licensed for, has configured, and genuinely uses in practice.
Your structural report: how ten CMS platforms handle taxonomy, components and content patterns. →