AI Organiser

Designing guided agentic action inside a Digital Asset Management platform
 

---

Background

Frontify's DAM (Digital Asset Management) holds large, often messy libraries of brand assets. Organizing them — sorting into folders, applying structure — is manual, repetitive work that most users put off. We wanted to test a different hypothesis entirely: could a conversational agent do this work for the user, instead of the user doing it through traditional UI?

This is an active experiment, not a conventional feature build. The underlying question isn't "does this feature work" — it's "will people trust and adopt a conversational interface over a familiar UI for real DAM tasks."

The challenge

The Brand assistant had already taught us how to design AI that answers questions responsibly. The Organiser is a harder problem: this agent doesn't just talk, it acts — moving real assets in a real library. That shifts the design question from "is this response calibrated?" to "how much autonomy do we hand over, and how do we make sure the user never gets surprised by what the agent just did?"

We landed on a guided execution model: propose → confirm → execute. The agent never moves anything without an explicit user confirmation step, no matter how confident its analysis.

My role

I own agent behavior design, the language and communication system, and cross-surface coherence for this feature — working alongside a DAM designer (who owns the UI container and interaction shell), an agent-behavior/backend designer, a frontend engineer, an AI engineer, and PM/tech lead. The split kept two hard problems — "does the shell feel native to the DAM" and "does the agent feel trustworthy" — with clear, separate owners.

Key design decisions for MVP

Selection as the entry point, not natural language. Rather than asking users to describe which assets to organize, the agent reads whatever the user has already selected in the DAM. This sidesteps a genuinely hard agent problem — resolving vague language into specific asset IDs — by letting the UI do that work for free.

The selection snapshot. One subtle but important behavior: the agent reads the current selection at the moment a message is sent, not continuously. This raised a real edge case — what happens if a user changes their selection after a plan is proposed, then just says "proceed"? We decided the agent must detect the mismatch and re-confirm before executing, rather than silently acting on a stale plan. Small decision, but it's the difference between an agent that feels safe and one that quietly does the wrong thing.

Scoping confirmation for MVP. Rather than building a dedicated editing UI for adjusting a proposed plan, we kept the edit loop entirely conversational — the user can just tell the agent what to change, in plain text. This kept the MVP lean, though it means we're deliberately deferring a fuller structured-confirmation experience (which would need meaningful frontend/backend investment) until we've validated the core hypothesis.

Deciding what not to build yet. Every MVP scoping call was a trust-vs-speed tradeoff: no chat history (kept per-library instead of global), no auto-clear of selection after a move, undo deferred to open beta. Each of these was a bet that we could learn from a narrower experience before investing in the fuller one.