Rules first, AI second

Every content team I’ve worked with has a version of the same problem. Over a few years, a CMS fills up with things nobody remembers creating: the same hero image uploaded four times under four different names, entries that nothing links to anymore, references that point at deleted content or loop back on themselves, “test-do-not-publish” entries that were published anyway, and schema fields someone added for a campaign two seasons ago. None of it breaks anything on its own, so it rarely gets prioritized. It just makes the stack slower to work in and harder to trust, until somebody finally books a week for a manual audit.

When our team signed up for the Contentstack partner hackathon this summer, that was the problem we wanted to take on. Many of the obvious agentic ideas in the CMS space are about generating content, but we wanted to explore an agent that could look after the content a company already has, because in the large stacks we work on, the debt grows faster than anyone can clean it up. The result was Curator, a governance agent for Contentstack. We demoed it live on the sponsor floor at ContentCon US 2026 in Chicago, where it won the North American edition of the hackathon.

Curator crawls a Contentstack stack and gives it a health score from 0 to 100. The score is built from six areas:

• Duplicate assets
• References, including orphaned entries and broken or circular links
• Stale and test content
• Unused schema fields
• Publishing
• Personalization, covering empty audiences, duplicate variants, and orphaned variant content in Contentstack Personalize

Curator then works through a loop. It looks at what’s in the stack, proposes fixes, acts on them once a person approves, and verifies the result by re-auditing and rescoring. Editors see all of this in a full-page dashboard that runs inside Contentstack as a Marketplace app, so they never have to leave the tool they already work in.

The dashboard is meant to make invisible debt visible. It includes a wall of duplicate-asset clusters, a graph of the reference relationships that shows orphans and loops, and a heatmap of which fields are being used. Seeing it laid out tends to change the conversation, because “we should clean up the CMS someday” turns into a specific list of things with a score attached.

The most important call we made early on was deciding how much Curator should be allowed to decide on its own.

Most content debt has a precise definition. Duplicate images, orphaned entries, broken or circular references, unused fields, and publishing problems can all be identified with rules, so Curator finds them with deterministic code. It fixes them the same way, through the Content Management API. Archiving entries, quarantining assets, and removing fields happen identically every time, in a way we can test and audit. When something looks wrong, there’s one place to look, and nobody has to explain to a client that a language model edited their production content on its own initiative.

Some of the work does need judgment. Deciding whether an entry called “Holiday Banner v2 FINAL” is live content or leftover test data means reading it in context, and rules handle that imperfectly. Curator currently flags those cases and leaves the decision with an editor. That’s the one place where we see a role for AI: a model that classifies the ambiguous cases and explains its reasoning, while the fixes continue to run on the same deterministic code.

Duplicate detection follows the same approach. To compare images, Curator downloads each one into the engine’s memory, which in the current deployment is a Vercel serverless function. There, sharp shrinks the image to a 9×8 grayscale grid and keeps two 64-bit fingerprints, and the image bytes are discarded. Nothing is written to disk, and images are never sent to a third-party AI service or any other service. Reference cycles and orphans come from graph analysis with graphology.

An agent that changes live content has to be safe by design, so we built several layers of protection into Curator:

• Branch protection. By default, fixes go to a branch you choose in the app, and main and production are protected. The engine supports an override for teams that want to change that.
• Preview and dry run. Before anything changes, Curator shows exactly what it intends to do and simulates the result.
• One-click human approval. Nothing runs until a person says yes.
• Rollback for most changes. Most fixes can be undone, and the re-audit shows whether the score actually improved. Removing a field deletes its data permanently, so that step asks for an extra confirmation.

For the hackathon, we ran Curator against a stack seeded with realistic retail-style mess. A one-command seeder injects duplicate-asset clusters, orphans, reference loops, broken references, stale and test entries, drafts, and dead fields, and it can be reset so the demo runs the same way every time. We got Personalize API access after the event opened, in time to include personalization in the ContentCon demo. On the floor, Curator connected to the stack, scored it across all six areas, worked through a set of previewed fixes, and rescored the stack to show the improvement.

Teams building agents that take action in enterprise systems all face the question we did about how much to let the system decide on its own. Starting with rules for everything that can be defined precisely, and bringing in a model only for the calls that need judgment, with a person approving changes and a rollback ready wherever one is possible, is a pattern that applies to commerce catalogs, order management, and any other system where an agent’s mistakes show up in front of customers. If your team is working through how much autonomy to give agents in your own stack, we’d be happy to compare notes.