intelligent.page is an agentic workspace. You give it a problem; it reads what it knows about your organisation, decides what to build, builds it, checks the result against everything else it holds, and writes what it learned back. This page explains that loop, what the work can reach, where you use it, and the controls that keep you in charge.
For step-by-step walkthroughs, see the Quickstart. For the extension layer — connectors, skills, the Chrome companion and more — see Extend intelligent.page.
The task loop
Every request is a task: one request and everything it sets off. A task moves through four phases.
The loop adapts to what you ask. A quick question on Only this stops after Build. A question on Connected follows the work it triggers — a pricing question wakes the channel and margin work that depends on it — and reconciles the lot. Entire system rebuilds every stage of the model whether the request touched it or not.
You are part of the loop. When the work meets a fact it cannot find or a decision only you can make, it pauses and asks. Your answer is written into the artefacts and the run continues. If you turn on Ask for permission at interface selection, it also pauses at Decide and shows you what it intends to build first.
The full stage list, and exactly which stages each build scope turns on, is under Under the hood. You do not need it to use the product; it is there for when a result surprises you.
The model
Underneath the loop is the organisation model: what is known about your organisation, organised stage by stage — market, customers, product, pricing, channels, strategy, team, operations and so on. It starts from your website and is refined by every task, every answer you give, and every source you connect.
When this page says "the system decides", it is reasoning over that model rather than over your prompt alone. That is why two people modelling the same company get the same starting point, and why the tenth task is better informed than the first.
Interfaces
Interfaces are what make the output work rather than prose. Sheets calculate; boards move; timelines have dates; diagrams have edges. The system chooses among them by the shape of the answer — a comparison becomes a table or cards, a sequence becomes a timeline or board, a model becomes a sheet — and you can move a result to a different surface afterwards.
See Interfaces and surfaces and the interface reference.
What the work can read
When a task runs in a directory, it can reach:
- Your organisation model. Everything under Memory: the stage-by-stage read of the business, every earlier dossier, every answer you have given.
- Your website. Re-read whenever the company audit runs, so a repositioning reaches the model.
- Connected tools. Whatever you have authorised under Settings → Connectors — a repository, a calendar, analytics, a tracker, a Seller Central account. Connectors inform the model; they are read, not copied.
- What you attach. Files, voice notes and pasted material on the task itself. These stay with the task and are not written to the model.
- Skills. Published thinking on the kind of problem you are working on, matched to the request.
- Your browser, through the Chrome companion. Pages behind your login, and meetings, that no server can reach.
Because the work sees the whole model, it can work across it. Ask where you are losing to a competitor and it reads positioning, pricing, channels and the last three dossiers on the subject — not just the sentence you typed.
Where you use it
The loop is the same everywhere. What changes is how you reach it.
See Platforms and integrations for the full comparison.
Tasks, dossiers and versions
A task returns a dossier: the entry doc, the artefacts, and an honest account of what stands behind them. Dossiers do not disappear into a thread. They are docs in the directory, filed into sections, and every change to them adds a version rather than overwriting — a later run that rewrites a document you reviewed cannot destroy your copy.
Tasks are independent of each other but the model is shared. A task started today reads what yesterday's task wrote back. That is the whole point of the design: steering accumulates.
Staying in control
Three mechanisms keep a large amount of machine work under a small amount of human steering.
Scope bounds the reach
Build scope is set per task, and your last choice sticks. Only this answers; Connected does real work; Entire system reconciles everything. Nothing reaches further than the scope you set.
Issues surface the doubt
The work does not hide uncertainty in confident prose. Anything it assumed, could not verify, or needs you to decide lands under Issues with a label — evidence needed, assumption, data request, decision, risk, divergence. Answering a data request writes the real number into the artefacts.
The gate and the versions let you undo
Turn on Ask for permission at interface selection and no artefact is built before you have seen the plan. Every artefact versions, so you can read an earlier state and see what a run changed. Activity shows what the run actually did, stage by stage, when a conclusion surprises you.
Work effectively with intelligent.page
A few habits get noticeably better work back. For the full list, see Best practices.
It is a delegation, not a prompt
Describe the problem the way you would to a capable colleague and let the system decide what to read and build:
The checkout conversion fell after the redesign. Find out why and tell me what to change first.
You do not name the sheets, the sources or the surfaces. It works that out.
Iterate on the model, not the wording
When a result misunderstands the business, a longer request will not fix it next time. Correcting the doc in Memory will. Treat the model like a shared brief that gets sharper every week.
Read Issues before Index
The artefacts are the easy part. The Issues tab is where the work tells you what it is unsure about — which is exactly what will be probed in the meeting you are preparing for.
What's next
- Extend intelligent.page — connectors, skills, the companion, directories, projects and the API
- Best practices — patterns that hold up across teams
- Reading a dossier — the entry doc, the artefacts, the doubts