Ten questions to ask before you let an agent touch your production website.
Agentic features are converging. Every website platform and every editor is shipping an agent or is about to, and within a year the question of whether a product has one will get the same answer everywhere. When everyone has an agent, the agent stops being the difference. What differs is the quality of the governance around it, what data the agent is allowed to see, and what you can take with you when you leave. These ten questions are meant to be asked of any vendor, including us.
A note on fairness first. A platform-native agent is a fine answer for a team that wants one vendor, one bill, and one support line. Nothing below says otherwise. The questions are about knowing what you are buying before an agent has write access to the site your pipeline depends on.
The ten questions
- Who approves, and is it enforced or just a UI toggle? A good answer names a role, not a person, and shows you where the rule lives. If the approval can be skipped by calling the API directly or by an admin flipping a switch, it is a suggestion, not a gate.
- What is the record, and can a non-engineer read it? Ask to see the history of one real change: who asked, what context governed it, who approved, what shipped. If the answer is a commit log, ask how the marketing lead reads it.
- Can we restore, and what does restore actually do? Restore should be one action that returns a prior version and preserves history. Find out whether it reverts content only, code only, or both, and whether the deploy follows automatically.
- Which agent, and can we change it? If the vendor's own agent is the only option, the answer to every other question depends on that agent staying good. A layer that accepts any agent has no such dependency.
- Where does the code live and who owns it? The right answer is a repository you control on a host you chose. If the code lives inside the platform, or is generated on export, you own an approximation of your site.
- What happens when we leave? Ask for three things separately: the code, the content, and the record. Content should export in a standard format such as Markdown or JSON. The approvals and findings should come with it, not stay behind.
- Which changes need a human, and can we tune that per risk? A headline and a redirect rule are not the same risk. A good answer lets you set tiers, requires more sign-off as risk rises, and shows you what triggered the tier.
- Does it find problems or wait to be asked? A system that only responds to requests puts the burden of noticing on your team. Ask whether it crawls on a cadence, scores pages, and drafts the fix before anyone files a ticket.
- What does it cost as the site and team grow? Look for the unit. Per seat punishes wide review; per page punishes large sites. Ask what changes at ten times the pages and three times the team.
- Does it work with the host and framework we already chose? If the honest answer is best on ours, you are being sold a migration. Ask for a demo on the stack you run today.
Separation of duties
The person who asks for a change should not be the person who approves it, at least for high-risk work. Any system that lets one account do both has no approval step. It has a confirmation dialog.
What the questions are really testing
Read together, the ten questions test three things. Governance quality: questions one, two, three, seven, and eight ask whether the controls are real, legible, and proactive. Data access: questions four and five ask what the agent can see and who owns what it changes. Portability: questions six, nine, and ten ask what leaving costs and whether the price is fair as you grow. A vendor can be strong on one and weak on another, and the mix that suits you depends on how much you want to own.
The same questions, answered for Dispatch
We said the questions apply to us, so here are the answers without decoration. Approvals are enforced in the database, not in the interface, so there is no toggle that skips them, and high-risk work needs a second approver. The record is a plain-language activity feed, and it exports as JSON and Markdown along with the rest of your workspace. Restore lands as a normal commit with history intact. Bring your own agent; Dispatch never builds, hosts, or edits the site, and the code stays in your repository on your host. Risk tiers are configurable per site. The Inbox re-crawls on a schedule and drafts a fix when a page drops ten points. It is free for one website, then $29 for Starter and $99 for Team. Dispatch governs the work; other systems execute the work.
What to do with the list
Put the ten questions in front of every vendor you are considering, write the answers down, and keep them where the agent can read them. Then test the answers on a real site rather than a demo. Connect one website to Dispatch, free, and ask all ten of it this afternoon.
Is a platform-native website agent a bad choice?
No. For a team that wants one vendor, one bill, and one support line, a platform-native agent is a reasonable answer. The ten questions are about knowing what you are buying: how approvals are enforced, what the record looks like, whether restore is real, and what you can take with you when you leave.
Which of the ten questions matters most?
Approval enforcement. If the approval step can be skipped through an API call or an admin toggle, every other guarantee rests on nothing. Ask where the rule lives and what happens when someone tries to go around it.
Why does data access matter when every platform has an agent?
Because agents are converging on the same models and the same capabilities. What an agent can see, whether that is the whole codebase, your context library, and your page scores, or only the fields a platform exposes, is what separates a useful change from a plausible one.
Do these questions apply to Dispatch?
Yes, and the post answers them. Approvals are enforced in the database, the record exports as JSON and Markdown, restore lands as a normal commit, the agent is yours to choose, and the code stays in your repository. It is free for one website.
Dispatch Team
Writing about AI-powered websites, AI governance, and collaboration, helping teams turn AI from scattered experiments into shared organizational capability.