Best practices

Patterns that get better work back: ask for outcomes, scope deliberately, answer what it asks, and correct the model instead of the prompt.

intelligent.page is an agentic workspace. Unlike a chat tool that answers and waits, it reads your organisation model, decides what to build, builds it, checks it, and writes what it learned back — while you watch, redirect, or step away entirely.

This changes how you work. Instead of writing the analysis yourself and asking a model to polish it, you describe the outcome and the system decides what to read and what to make. The patterns below are the ones that hold up across the teams using it. For how the loop works, see How intelligent.page works.


Most of these practices rest on one fact: the organisation model is the product. Every task reads from it and writes back into it. A better model gets better work from the same request; a neglected one gets generic work from a perfect request. Time spent on the model compounds; time spent on the wording of one request does not.


Ask for the outcome, not the artefact

Tip

Say what you need to decide or do. Let the system pick the sheet, deck or board.

The surface is chosen by the shape of the answer. When you ask for a spreadsheet you get a spreadsheet, whether or not a spreadsheet answers anything. When you ask the question, you get the artefact that answers it — and the reasoning that makes it defensible.

Vague requests are fine when you are exploring. "What would you change about how we sell?" can surface things you would not have thought to ask.

Choose the scope deliberately

Tip

Only this answers. Connected does real work. Entire system is a reset. Pick on purpose; your last choice sticks.

Build scope is the control that most changes what you get back, and the largest single factor in what a task costs.

  • Only this when you want an answer quickly and nothing else. Good for checking a fact, drafting a first pass, or seeing how the system reads a question.
  • Connected for almost all real work. The request runs, and so does the work it triggers — a pricing question wakes the margin and channel work that depends on it — and the reviewer reconciles them.
  • Entire system when something fundamental changed: a repositioning, a new market, a pivot. Every stage of the model is rebuilt whether the request touched it or not. Slowest and most expensive, and the right choice less often than people expect.

If a result feels thin, the scope was too narrow. If it produced far more than you asked for, it was too wide. Re-run rather than wrestle with it.

Answer what it asks

Tip

A data request answered once writes the real number into every artefact that used the placeholder. You do not re-run anything.

When the work cannot find a value it needs, it pauses and asks, or proceeds with a clearly-labelled placeholder and raises an issue. Either way the question is precise: what is your current conversion rate from trial to paid?

Answer it. The value is written into the sheets and recalculated downstream, and the model keeps it, so no later task asks again. Leaving these unanswered is the most common reason a directory's work stays generic.

Correct the model, not the prompt

Tip

When a result misunderstands the business, the fix belongs in Memory. One edit there fixes every later task.

A longer request next time will not stop the same misunderstanding. Editing the doc under Memory will — the model is ordinary, editable content, and every task reads it.

Treat the model like a shared brief. Review it when things go wrong, prune what is stale, and check whether the next task actually shifts.

Read Issues before you trust anything

Tip

The Issues tab is where the work says what it could not verify. It is the part people skip and should not.

The artefacts look finished. The Issues tab is where the run tells you which claims rest on evidence it could not find, which figures are placeholders, where two sources disagree, and what a human still has to decide.

Before a meeting, read Issues first. It is exactly the list of things you will be asked about. And when a conclusion surprises you, open Activity — it shows what the run read and did, stage by stage.

Hold alternatives open instead of asking three times

Tip

For a decision with options, let the task carry a choice variable. You get comparable variants off one baseline rather than three separately-argued cases.

Pricing, timing and bundling rarely have one answer. Ask about the change and let the task hold the alternatives open as choice variables. The work is built once as a baseline and once more per alternative, so differences between variants are real differences, not drift between three runs.

Set the limit under Choice variables per task in directory settings — up to three, or zero to turn variants off.

Connect the source of truth

Tip

If a fact lives in a tool, connect the tool. A model that can read your calendar knows what you are working on; one that reads your analytics knows how the product is doing.

Connectors inform the model; they are read, not copied. Grant the narrowest access that covers the question:

Configure the directory once

A few settings make every task better. They live in directory settings.

  • Ask for permission at interface selection pauses the run to show you what it intends to build. Turn it on while you are learning how it decides; turn it off once you trust it.
  • Automatically organise completed tasks files output into sections when a run finishes. Leave it on unless you want to file by hand.
  • Choice variables per task caps how many alternatives one task may hold.
  • Upskill shows you the passages behind a matched skill rather than only its name, so you can judge whether the reference material is any good.
  • The brand book drives anything with a visual form. Check it early; correcting the palette once fixes every deck afterwards.

See Directory settings and Extend intelligent.page.

Model the competition, not just yourself

Tip

A directory is one organisation. Make one for each competitor you care about and benchmark them against your own.

The same modelling that reads your site reads theirs. Create a directory from a competitor's URL and you get their positioning, pricing and channels the way the model sees them — comparable, because it was built the same way. The benchmark then compares your organisation against the category with the numbers exposed.

Use projects for measures, not to-do lists

Tip

A project is a bet on one driver — a number you are trying to move — with milestones that say whether it is working.

Projects are not a backlog and they do not replace your issue tracker. Set one up around the measure that matters this quarter, let tasks attach their milestones to it, and post updates: health comes from updates, so a project that has gone quiet cannot claim to be on track. See Projects.


Avoid common failure patterns

  • The format request. You ask for a spreadsheet and get a spreadsheet that answers nothing.

    Fix: ask the question; let the answer choose the surface.

  • Entire system for a small question. A quick check rebuilds the whole model and costs accordingly.

    Fix: Only this for answers, Connected for work, Entire system for resets.

  • The unanswered data request. Every dossier carries the same placeholder.

    Fix: answer it once; it is written through and remembered.

  • Correcting in the prompt. The same misunderstanding comes back next task.

    Fix: edit the model in Memory, or re-run the audit if the site changed.

  • Trusting the artefact. A confident deck with an unverified claim in slide three.

    Fix: read Issues first; open Activity when a conclusion surprises you.

  • The stale directory. The website moved on and the model did not.

    Fix: update the URL in directory settings and re-run the company audit.

  • One directory for many companies. Your company, a client and a competitor in one model contaminate each other.

    Fix: one directory per organisation. Compare across them with the benchmark.


Develop your intuition

These patterns are starting points. Sometimes Entire system is exactly right, because the strategy did change. Sometimes a vague request is the point, because you want to see how the system reads the problem before you constrain it. Sometimes the placeholder is fine, because the decision does not turn on that number.

Pay attention to what works. When a dossier is excellent, notice what you did: the question, the scope, the state of the model. When it struggles, ask why. Was the model thin? The scope wrong? The question actually three questions? Over time you will know when to be specific and when to be open, when to widen and when to hold back — and the model will have learned alongside you.