Manage your AI agent with content, not code

Written by Jeremy Rivera

Running an AI agent as an organization can feel like a heavy responsibility. Naturally, you may shirk at the idea of handing your org’s system prompt to editors, but if they update your website, they should be able to update your agent too. The system prompt, like any other content, should have legal review, input from marketing, and feedback from customer support; it should be something that each editor on your team can change.

These five patterns will mitigate most of the risk that comes with modifying the system prompt, but first let’s make the case that the system prompt should not always be code.

Your system prompt is content. Treat it that way.

Your system prompt shouldn’t be a file that’s fully relegated to a git repo. Since it’s a document with the same fields as other content, it should be handled just like any other piece of content operations.

And it's good that your system prompt can be treated like anything else in your content operations. Editors are quite often the people interfacing with your customers and users: they sit in marketing meetings, read the support queue, and speak with the people most likely to share feedback. This puts them in a critical position, much closer to what your agent’s desired output is than the engineer who set it up. And think, an agent that the people closest to your users can update will: deflect more support tickets, give more accurate responses, or will sell more.

A system prompt that only a few people can edit isn’t something a better or faster model can fix. A superior model cannot compensate for a prompt that is unaware about this season’s campaign or a sudden price drop, but allowing your content editors to control your system prompt, like any other content, will.

Doesn't this risk breaking something?

It very much could, if you just handed your editors a text box. Instead, the system prompt gets split into fields with separate owners, which is the first pattern below. Document history shows what changed and who’s responsible for that change. It also lets you make a revision if you need to, just like any other content you’re used to editing, such as a homepage revision.

Also consider that with Workflows, that process can be defined once as code: the stages a change passes through, who approves each one, and a hold that keeps the prompt from publishing until a stakeholder has signed off. This is the same level of governance you already have across your content operations.

If you prefer something more visual the five patterns below come from this video, where John demoed them on a hotel booking site with a concierge agent.

Pattern 1: Break up your system prompt

Your agent's configuration lives in a document type of its own. Instead of one field holding the entire prompt, that document has several fields with each one having an owner.

Which fields you need depends on your specific use case. In the hotel demo, a core prompt holds the technical instruction: how to render a hotel card, what tools to call, output rules. This is something Engineering owns. A separate voice-and-context field holds the tone, what to lead with, and what to avoid. That one is editorial's.