The AI That Checks Its Own Work

Here's the failure mode nobody puts in the demo. You ask an AI agent to add a section to your homepage. It calls the API, writes the content, and reports back: "Done — I've added the pricing section." You take its word for it. Two days later a visitor emails to say half the page is blank, because a template reference was misspelled and the whole block silently rendered to nothing.

The agent didn't lie. It genuinely wrote the content. It just never looked at the result — because in most AI-and-CMS setups, it can't. It writes into a black box and gets back an "OK." Whether the page actually renders, whether the layout holds, whether the thing a human would see is right — none of that comes back through the API.

That gap is the whole reason we built verification into Neleto instead of leaving it to hope. An agent working on your site gets three ways to check its own work before it tells you it's done.

The problem with "fire and forget"

When a headless CMS hands an agent an API, the contract ends at "content accepted." The rendering happens somewhere else — a separate frontend, a separate build — so the system the agent talks to has no idea what the visitor eventually sees. The agent can be perfectly obedient and still ship a broken page, because the thing that renders and the thing the agent controls are two different systems.

That's fine when a human reviews every change. It stops being fine the moment you want an agent to do real work unattended — migrate forty pages, fix a batch of redirects, translate a section — because now nobody is looking at the output until it's already live. "The API said OK" is not the same as "the page is right," and the distance between those two sentences is exactly where things break.

Neleto closes that distance because content, rendering, and the agent interface are one system. So the agent can do what a careful human does: write, check, and only then say it's finished.

Layer 1 — the write talks back

The first layer is the quiet one. Every tool on Neleto's native MCP server returns typed structured output, not a vague success string. When an agent creates a page or updates a component, it gets back the actual object it just wrote — the resolved fields, the IDs, the references — in a shape it can inspect.

That sounds small, but it's the difference between "the server didn't reject my request" and "here is exactly what now exists." The agent can compare what it intended against what came back and catch a mismatch immediately — a field that didn't take, a reference that resolved to the wrong thing — instead of assuming the write did what it meant.

Layer 2 — check the template before you publish

The second layer catches the misspelled-reference class of bug before a visitor ever could. Neleto's MCP server exposes LSP checks — lsp_check_page, lsp_check_layout, and lsp_check_component — the same language-server validation the editor uses, available to the agent as a tool call.

The agent loads a page, layout, or component and gets back the errors and warnings in its template: an unknown helper, a reference that won't resolve, a form field that doesn't line up with the template that consumes it. This is the step that would have caught the blank pricing block. The agent runs the check, sees the diagnostic, fixes the reference, and re-checks — all before publish, all without a human noticing anything went wrong, because nothing did by the time you looked.

It's the same instinct that makes a compiler valuable: find the mistake at the point of writing, not at 2am in production. We wrote about why that mindset runs all the way down to Rust — this is the same idea, one level up, handed to the agent.

Layer 3 — open the live page and look

The third layer is the one that feels almost human. Neleto's settings_get tool hands the agent the live instance's real public URLs — publicBaseUrl, adminUrl — so it can go and open the page it just built, the exact URL a visitor would hit, and read the rendered result back.

This is the check the other two can't do. Typed output confirms the write; LSP confirms the template compiles; but only fetching the live page confirms that the finished thing actually looks like a page. The section is there, the heading rendered, the image resolved, the layout didn't collapse. An agent with a screenshot tool can literally look at it. The loop that used to require a human — "let me just load it and see" — is now something the agent does for itself before it reports back.

None of this works without the roles you already set. Every one of these operations — read, write, check, view — runs with the agent's permissions enforced on the server, so "check its own work" never means "quietly gain more access." We went deep on how that server actually works in the MCP deep dive.

Why this needs one system, not three

You could, in principle, bolt a verification step onto a headless stack: wire the agent to the content API, wire it separately to the rendered frontend, stand up a screenshot service, and glue the diagnostics together yourself. People do. It's a pipeline you now own and maintain forever, and every part of it can drift out of sync with the others.

Neleto's version isn't cleverer — it's just that when the content, the renderer, and the agent interface are the same system, the verification is already local. The live URL the agent checks is served by the same box that stored the content it wrote. There's no second system to keep honest, because there's no second system.

Where a human still has to look

Build-in-public means saying what this doesn't do, because the honest limit is the useful part.

Self-verification answers "did it render, and is it structurally sound?" It does not answer "is it good?" An agent can confirm the pricing section exists, renders cleanly, and passes every check — and the copy can still be off-brand, the tone wrong, a number out of date, a claim that isn't true. Those are judgment calls, and judgment is still yours. What these three layers buy you is that the mechanical failures — the broken reference, the collapsed layout, the silent blank block — get caught by the machine, so your review can be about whether the page is right, not whether it works.

And the agent has to actually use the tools. The capability is there; a careless prompt can still skip the check. That's a real edge, and worth knowing before you hand an agent the keys to forty pages.

The point

"AI-native" gets thrown around until it means nothing. For us it means something specific and testable: an agent working on your site can do the whole loop a careful person does — write it, check the template, open the live page, and only then call it done — because it's all one system and the checks are one tool call away.

That's a smaller, more honest promise than "the AI does it all." It's also the one that keeps a blank pricing section off your homepage.

Try it yourself: connect an agent to a free Neleto project, ask it to build a page, and tell it to open the live URL and check its own work. Watch it catch its own mistake before you have to — that's what the complete CMS is for.

Fast websites. Easy content. AI native.