Agents Can’t Act on
Content Nobody Governs

Four questions a platform has to answer before an agent acts

An agent that returns a suggestion is a very good assistant. An agent that changes your content, its metadata, its permissions or its distribution is something else entirely, and it only works if the platform underneath it can answer four questions without hesitating.

What actions exist?

Not what a model can imagine, but the finite, typed, documented set of things that are allowed to happen to an asset. An agent with an open-ended ability to update the record is not governable. An agent that calls a named action with a known signature is.

Who is allowed to take them?

A permission model built for people does not automatically cover processes. When a person clicks a button, something checks whether that person may do that thing, to that asset, at that moment. Automation routinely skips the check, because it runs as a single service account with broad rights that nobody revisits once the integration goes live.

The right shape is the one enterprises are already converging on for their own agents. Give the agent a durable identity of its own. Scope its credentials narrower than any human's rather than mapping it to a shared account. Evaluate access at the moment of the call rather than at the start of a session. Write a record that names the agent and the person it acted for as two separate facts. Those four primitives are becoming what an architecture review expects, and the reason is simple: a boundary can be read and audited, and a habit of clicking approve cannot.

Tenovos evaluates permission at the moment of the action rather than assuming it at login, so an automated action is bound by the same policy that binds a human one. Accepting agent identities issued by the customer's own identity provider is work we are doing, not work we have finished. We would rather say that here than have a buyer find it in an architecture review.

What triggered this?

Content operations are event-driven whether or not anyone designed them that way. An asset arrives. A rendition finishes. A rights window closes. A connected system changes upstream. Agents earn their keep precisely when they respond to those moments unattended, which means a platform needs an event spine before it needs a model.

Can you prove what happened, and undo it?

Every automated action needs a record: what ran, on which asset, which rule fired it, what changed, and how to put it back.

The reason is arithmetic rather than caution. A cataloguer working through an afternoon can get fifty records wrong. A rule can apply the same mistake to five million assets before lunch, which is close to how Laurent Groult put it in DAM News this month. The error rate does not have to rise for automation to become dangerous. Only the blast radius does.

This is why undo is a product decision rather than a nicety. The first bad automated batch is the moment a customer decides whether automation ever runs again. Teams who cannot answer "which assets did this touch, and can we reverse it" do not file a bug. They switch the automation off, permanently, and every later conversation about AI in that organisation starts from a worse position.

A per-execution job record is the unglamorous artefact that prevents that outcome. It is also the first thing anyone asks for after something goes wrong, and the last thing anyone asks for in a demo.

How the governed action layer works

We built that layer first, deliberately.

Rules watch for content events and evaluate conditions against the asset itself. Actions are a defined, permissioned catalog rather than an open door: set a property, set a relationship, set a policy. A rule can be tested against a sample asset before it goes anywhere near production, enabled and disabled on its own, and every execution is tracked as a job you can inspect. Connected sources are scanned and reconciled continuously, so the events reflect what is actually happening across the systems your content already lives in, not only what happens inside ours.

Set a property

writes a value onto the asset itself, under the rule that fired.

Set a relationship

connects the asset to another object, so the context travels with it.

Set a policy

changes what people are permitted to do with the asset.

Why setting a policy automatically is the difference

Almost all content AI describes. It looks at an asset and produces words about it: tags, a summary, a caption, a compliance opinion. That work is becoming a commodity, because the models doing it are available to everyone on the same terms.

Changing what people are permitted to do with an asset, based on what that asset actually is, is a different category of act. It is enforcement rather than description. It is also the only content automation we know of with a hard, arguable return, because it removes a manual gate instead of speeding one up.

Several platforms now describe themselves as governed, and inside a single repository that claim is increasingly fair. The distinction worth testing is where the governance stops. Ask whether the policy still holds when the asset is a derivative rather than the original. When it moves to a channel the platform does not own. When the rights window closes six months after publication. When the same content lives in three systems with three different owners.

Policy that holds only inside one repository is a setting. Policy that resolves to a governed record, with its variants, its rights state and its history intact, wherever the content travelled, is governance. That is the line we build to.

What Article 50 makes concrete

Until recently this argument had to be made in the abstract. It does not any more.

Article 50 of the EU AI Act became enforceable on 2 August 2026. Deployers must visibly disclose AI-generated or manipulated content in defined circumstances. Providers must embed machine-readable markings and supply a means of detection. Generative systems already on the market have until 2 December 2026 to meet the marking obligation. Penalties reach EUR 15 million or 3% of worldwide annual turnover, whichever is higher.

For most brands the interesting part is not the label. Producing a label is easy. The hard part is that the marking has to survive the asset. A machine-readable mark applied at generation lives in the file and in its metadata, and a library exists to crop, resize, transcode and re-export that file for a new campaign, a new market or a site relaunch. Every one of those operations is an opportunity to strip the very thing the regulation requires to be detectable, and the tool that generated the asset is long gone by the time anyone notices.

That makes AI involvement a property of the record rather than a property of the generation event. It has to be captured when the asset arrives, inherited by every derivative and rendition, survive a re-crop and a resize, and be checked at the moment content leaves for a channel. Those are four things a governed action layer does. They are four things a generation tool cannot do, because the generation tool is not in the loop when the asset is republished eighteen months later.

We are not going to tell you we have shipped a compliance product. What we have is the layer this requirement actually runs on: conditions evaluated against the asset itself, a state you can set on the record and carry forward to everything derived from it, and a permission that changes when that state changes. What we are still building is the check at the channel boundary and the reporting a regulator would expect to see. We would rather name that gap than sell around it.

Cooley's summary of the transparency obligations is a good starting point, and the Commission's own FAQ on Article 50 is the authority on scope and dates.

What comes next for model-driven decisioning

None of this is glamorous, and none of it can be retrofitted later. It is also why our model-driven work is going where it is going. Enrichment already runs as an action inside this pipeline rather than alongside it, which is why a generated description arrives attached to a governed object with its version, its rights state and its audit trail intact. The decisioning layer, where a model chooses which action to take rather than executing one we specified, comes next, and it will land inside these same guardrails or it will not land at all.

We would rather ship the foundation late than ship autonomy nobody can audit.

What to ask when you evaluate agentic content capability

Most agent demos are built to be watched. Here is a shorter list, built to be asked.

• What is the complete list of actions an agent can take on this platform? If the answer is a category rather than a list, there is no list.
• Under whose authority does an action run, and is that checked when the action executes or when the session begins?
• What fires an action? If the answer is always a prompt, nothing runs while your team is asleep.
• Show me one execution record end to end. Now undo it.
• Does the policy still hold on a derivative, in a channel you do not own, after the rights window closes?
• Where does the AI-involvement state live, and will it survive republication two years from now?
• Which of these exist today, and which are on a roadmap?

Smarter content starts with content you can trust.