Checks are the portal’s “inner voice”: they watch that a page is assembled correctly and tell the agent what to fix. The idea is simple: problems should surface before readers see the page, not after.
When checks run
Some checks run on every read of a page — invisibly to the reader. The rest the agent starts on request, usually before saving: that is how it makes sure nothing got broken. That check’s result is kept for five minutes, so a repeated request does not recompute everything.
What gets checked
- The page title — is there one at all? A page without a title cannot be found in the tree either.
- Access — whether it holds a understandable value: draft, for staff, or public.
- Block ids and width — the ids are unique, and the width fits the allowed range.
- Block types and their fields — the type is known to the portal, every required field is filled, and a visualisation carries a type the portal recognises.
- Buttons — every action has what it needs (an address, a path, a request text or a script), and there are at most three buttons per block; for a step inside the portal, a script and a task to the agent, the new tab and the consequences after acceptance are stated explicitly.
- Content — whether there are empty lists and invalid values.
- Files and scripts — whether what the blocks reference is in place: pictures, text files, calculation programs.
- Templates — whether the variable substitutions hold errors.
- Data and queries — whether the source a block takes data from is in place, whether the query itself is filled in, and whether its waiting time and row count fit the allowed limits (see the Data Sources & Visualisations section).
- Tables — whether the rows and cells are written correctly: does the portal understand the icon, is the colour not broken.
- Forms that send to the agent — whether the request template is filled in, whether it names fields the form does not have, and whether the consequences after acceptance are clear: what to refresh and what to open.
Two kinds of messages
- Errors — what keeps the page from showing in full: no title, an unusable access value, a block without an id.
- Hints — what the agent simply forgot: an empty list, a reference to a missing picture, too many buttons. The page still works, but is worth polishing.
What it looks like
When there are problems, a strip appears above the page: The agent left {count} issues on this page, with the number of findings. It expands, and every message says exactly what is wrong and what to do about it. No unpleasant riddles remain: a hint always carries a suggestion, not just a statement.
Who sees it
Service messages are shown to the portal’s administrator only. Ordinary readers — and all the more visitors of the public site — do not see them: people come for information, not for a page assembly report. Even on a public page where something is wrong, an outsider simply sees the page without technical remarks.
Next: how the agent edits content — in the Agent Management section; how to talk to the agent about an edit — in Chat with the AI Agent; a general introduction — in Getting Started.