The portal’s content is edited by the managing agent, and edited directly — as ordinary files in the portal’s folder, not through a browser. A page is a folder: the agent creates, rewrites, renames and moves such folders with the same means it uses for files. The separate key-protected service address does something else: the agent checks pages with it, runs calculation scripts, looks at data sources and learns the portal’s state — while the portal validates, runs scripts and reports that state.
The management key
A key opens access to management. The server settings store not the key itself but its fingerprint — a SHA-256 hash from which the key cannot be recovered. The agent sends the key in a service request header (X-API-Key), and the portal compares the fingerprints. When no management key is set at all, management is disabled: every request to it is declined. That means only someone who knows the key can open editing.
Hence an important rule: the management key is as secret as the administrator’s password. It is not published and not handed to outsiders.
What the agent can do
- Edit pages as files — write the description file, a text file, a picture or a document next to the page, and fix what is already written.
- Rename, move, copy, delete — put the page tree in order: these are ordinary folder operations, and the portal sees them exactly like any other edit.
- Write calculation scripts — the texts of the programs and the list of libraries they need also lie as files next to the content.
- Check the structure — run a page through the checks by its path and see the errors and hints (see Page Validation).
- Run a script and install libraries — debug a calculation script and add what it lacks (see Scripts & Dependencies).
- Look at the data sources and test a query — which sources are connected, what they read and where the error is; and before writing a query into a page the agent can run it and see the result (see the Data Sources & Visualisations section).
- Work through page comments — read the administrator’s remarks next to a page’s description, make the edit and remove the remark it has handled; the agent answers in the chat, not in the comment thread (see the Page Comments section).
- Learn the portal’s state — the version, the content folder, whether the server is watching the files, how many pages there are, how many data sources and whether any of them is broken, and whether Python is ready. The agent needs this to understand what it is working with before the first edit.
A ready-made guide for the agent
So that the portal does not have to be explained to the agent from scratch, a ready-made guide (a skill) ships with it: how the page tree is arranged, what each of the 28 block types can do, how address templates work, Python scripts, data sources and visualisations, checks, comments and publishing. It lives inside the portal and is updated together with it.
The guide does not need to be installed by hand: when the portal is deployed through Xedant MultiAgent, it is passed to the linked agent automatically — edits can start right away, with nothing to explain.
The portal address and the management key come to the agent from its own environment: being linked to the portal is enough, and naming these values in the conversation is unnecessary. One more convenience follows — a single agent can run several portals, and hosting the application in a subfolder changes nothing for it. And should the guide and the server ever disagree (the guide inside the image may lag slightly behind an update), the server is right: its state, check messages and readable error codes on the page matter more.
Clear rules and limits
- A free name for a copy. When you copy a page and a folder of that name already sits beside it, the portal appends a number —
news2,news3— and never overwrites the existing one. - The root page cannot be deleted. It is the portal’s home page and the whole site’s settings; it cannot be knocked out by accident.
- Address conflicts are explained. When a move touches an existing page or climbs into its own subtree, the portal answers with a clear refusal naming the reason — it never guesses.
- An exact page beats the sample. To put a separate page where an address is served by a sample, the agent first creates a page at that address explicitly — from that moment the address leads to it, and the sample keeps serving the other values.
What the server does itself
When the agent writes files, it maintains the service marks itself: the modification time, the page’s version number and its icon are part of the description, and the agent updates them together with the edit. The portal itself never rewrites the content: it reads the files exactly as they lie on disk. Large block texts live as separate files next to the description — so the description stays short and the edits in the version history stay readable.
How to know it is all ready
Before saving, the agent can run the page through the checks and see whether there are errors. The check result is kept for a few minutes, so a repeated request does not recompute everything. And the portal’s state tells it whether the files are in place, whether change-watching works, and whether the script environment is ready. That is how the agent verifies the result before readers see it.
Next: how to talk to the agent about an edit — in the Chat with the AI Agent section; what exactly gets checked on a page — in Page Validation; how a page is laid out on disk — in Document Format.