The Intelligence hub

Intelligence (/intelligence) is the hub that answers a different question from the rest of the product. Tasks, Runs and the Backlog are about the work. Intelligence is about how well the agents do that work, and how that improves over time. It sits in the sidebar’s Evaluate group next to Reports for exactly that reason: Reports tells you what the work produced, Intelligence tells you how good the machinery that produced it is.

It holds four tabs — Memory, Agent KPIs, Auto Agent / Models and Councils. Opening /intelligence lands on Memory; the other three live one segment deeper.

Why these four sit together

Each tab is one stage of a single loop. Memory is what the agents know going in. Auto Agent / Models records who was chosen to do a given piece of work, and under which policy. Agent KPIs measures how the choices actually performed, benchmarking one execution strategy against another on the same work. Councils is what happens when one agent deciding alone is not good enough, and several deliberate instead. And a recommendation from Agent KPIs can be pinned straight back into Memory, which is where the loop closes. None of these four is a place where work happens; all four are about the quality of the work — which is why they are one surface rather than four sidebar entries.

Memory

A memory is a durable note that agents receive as context: a convention, a trap, a decision worth remembering. Every memory has a scope — personal (yours alone), project (bound to one project) or workspace (shared across the workspace) — and the scope decides both who sees it and whether it travels with your synced repository.

The Memory tab holds several views over that store, of which Governance is the one worth knowing about here: it is where a workspace owner or admin decides, per scope, whether a new memory of that scope goes live immediately or queues for a human to approve first, and how long memories of that scope are kept. Requiring review is the safe default, and it applies to every new memory of that scope — one you type yourself as much as one an agent proposes at the end of a task.

Writing, editing, reviewing proposals and reading a memory’s version history are covered end to end in Manage memories.

Agent KPIs

The route says experiments and the tab says Agent KPIs. Both are honest: the underlying object really is an experiment, and the tab was named for what it shows you rather than for the object it is built on. The word survives in the URL and the API; the surface is a KPI dashboard.

An experiment is a benchmark you define: a small dataset of task cases, plus at least two variants. A variant is a complete execution strategy — which agent and harness, which provider, which model, which tool and budget policy. Launching the experiment expands cases × variants into real tasks in a real project, so the comparison is made of genuine agent runs rather than a simulation. As each run terminates its telemetry attaches on its own: cost, tokens, wall time, retries, tool errors, timeouts, and whether a pull request came out of it.

Cases × variants is usually more tasks than a workspace runs at once, and that is fine: the launch starts as many as there are free slots and queues the rest. A queued run has not failed and has not been dropped — it is waiting, it is listed under Waiting for a slot in the launch panel, and it starts by itself as earlier runs finish. This matters for the figures as much as for your nerves: a run that never started must never be counted as a variant that lost.

You do not have to launch the whole dataset every time. Tick individual dataset cases to launch exactly those — useful for filling one gap in the matrix rather than repeating everything before it. A launch also declines to duplicate a case that is already running, or has already succeeded, on that variant; it reports those as already covered instead of quietly measuring the same thing twice. When a repeat is what you want — reproducing a flaky result, say — tick Repeat existing runs.

Variants can be added to an experiment that is already running. A new variant starts at a sample size of zero, which is fair rather than unfortunate: every figure on this board is measured per variant, so the newcomer earns its numbers exactly as the others did, and no existing variant’s figures move.

Within one experiment, variant names must be unique — ignoring case and surrounding spaces. That is not bookkeeping: the name is how a result is attributed, on the leaderboard, in the ratings and in anyone’s review of the run, so two variants called “Control” would make every figure between them ambiguous. A clash is refused and the refusal names the variant. Separate experiments are free to reuse the same names.

That design is the answer to the question the tab exists for: how do you know a change to how an agent works made things better rather than merely different? Because every variant faced the same cases, the comparison is like-for-like, and the metric that settles it is usually not the success rate on its own but the cost per accepted result — a variant that succeeds a little less often for a third of the money can still be the better default.

The dashboard reads the same set of runs through six views: a Leaderboard per variant, the same figures regrouped by Harness and by Model, a Task classes matrix naming the winner for each class of work, a per-run drilldown, and a Benchmark matrix. Per variant it reports the sample size, the share of runs accepted, cost, minutes and tokens per accepted result, the test-pass and review-accept shares, the timeout share, and waste — the money spent on runs that produced nothing. From that it derives recommendations, each carrying its sample size and a confidence, and each pinnable into workspace memory so agents read the conclusion as context on their next run.

Auto Agent / Models

When you launch a task without pinning an agent profile, SupaCloud picks one for you. It scores every enabled profile on capability fit, how that profile’s past runs turned out, a learned signal from recorded outcomes, budget pressure, whether it is the workspace default, and cost efficiency. The model then comes from the profile that won: the one it pins if it pins one, otherwise the model the learning layer has settled on for it. Each decision is stamped with a policy — auto when SupaCloud chose, manual when you pinned a profile yourself or automatic selection is switched off for the workspace.

This tab is the history of those decisions: one row per selection, showing when it happened, the agent type and model that were chosen, the policy, and a one-line summary of the input it was choosing for. It is searchable, sortable and filterable by provider, model and policy.

It is read-only by design, and that is a deliberate boundary rather than a missing feature: automatic selection records what it decided and what you overrode, and it does not retrain from that record inline. Nothing on this tab changes how the next selection is made.

Three things people reasonably expect here live somewhere else:

The autonomous backlog router is a different selector. When the delivery engine dispatches a backlog item it routes on the item’s severity, scope and effort across a candidate set of profiles, and it records that in its own routing decision log — with the candidates, the chosen profile and the reasoning. That log is under Reports → Operations, not here, and backlog routing decisions therefore do not appear on this tab. How far the engine is allowed to go on its own is Autonomy and the delivery engine.
The live model catalog is not shown here. SupaCloud syncs a catalog of models with their context windows, prices and capabilities, and that catalog feeds the model pickers and the Models tab in Settings. This tab’s model column is the raw value recorded at the time of the decision, so a model you have since stopped using still appears in its history.
Quota and model fallback are not shown here. Provider saturation gauges live under Reports → Operations, and the chain that moves a task to an equivalent model when the pinned one hits its quota wall is a workspace setting, described in Handle a model quota wall.

Councils

A council is several agent profiles deliberating on the same question, with one of them acting as judge and synthesising the answers into a single recommendation carrying a confidence. A council never changes anything by itself. It produces a recommendation and stops; acting on it is an explicit, separate step — from a finished council you can fork it into another deliberation, convert it into a task, or pin its synthesis into memory.

So a council today is produced by a pipeline stage configured to run as one: instead of a single agent working that stage, several candidate profiles deliberate on the identical stage prompt and a judge synthesises the outcome. It is available on the deliberative stages — planning a change and reviewing it — and deliberately not on the stage that writes code: a council weighs a plan or a review, it does not implement. It is entirely opt-in; no pipeline arrives with it switched on.

The Councils tab is where you read the results. It lists the workspace’s councils with a status filter, and opening one shows the question it deliberated on, the participants, the judge’s synthesis, its confidence, and the three follow-up actions. You do not start a council from this tab — you turn the option on for a stage, and the deliberations show up here as that pipeline runs.

The governor — the loop that closes

Underneath Auto Agent / Models sits a learning loop, and above that loop sits a governor whose entire job is to make sure the learning never quietly makes things worse.

The shape is worth carrying even if you never configure it. Selection starts from a static heuristic, which is what a brand-new workspace runs on and which stays authoritative on safety and budget. Recorded outcomes then feed a reward signal, and a learned layer is allowed to nudge the heuristic’s ranking once there is enough data to be trustworthy. The governor watches that: it compares a profile’s recent outcomes against the profile’s own earlier baseline, and when the recent distribution has genuinely degraded rather than merely wobbled, it freezes the learned selection for that profile — selection falls back to the plain heuristic — records an audit event, and opens a proposal for a human.

Nothing the governor concludes is applied on its own. Its proposals — and the skills it induces from successful runs — land in the one decision queue at Inbox → Decisions, alongside workflow gates, tool approvals and memory reviews. Approving a profile-version proposal writes a new version of the agent profile through the ordinary validated path and lifts the freeze; rejecting it closes the proposal and leaves the freeze in place, so a rejection is a safe answer rather than a silent resumption. The full mechanism — the learning layers, the golden-set audit, the calibrated judge and the drift test — is The self-learning Governor.

Who may see and change what

The hub is not admin-gated: any member of the workspace sees all four tabs, and reading is member-level throughout — the memory list, the KPI dashboard, the selection history and the councils list are all open to members, and every query is scoped to your workspace, so no tab can show another workspace’s data.

What differs is writing. Creating a benchmark, launching its tasks and pinning a recommendation into knowledge require workspace owner or admin, and so does setting the memory governance policy per scope. Memory is the deliberate exception: any member may write a memory, and the governance policy — not a role — decides whether it publishes immediately or queues for review. Councils are read-only for everyone from this surface; their follow-up actions are open to members, because none of them changes a repository. In the decision queue the two governor-adjacent kinds differ: an induced-skill proposal may be decided by an owner or an admin, while a profile-version proposal is reserved for the workspace owner.

One gate sits above all of that: each of these surfaces is an entitlement of its own, so on a plan that does not include them the tab reports that the feature is not enabled for the workspace rather than showing an empty board. How plans and the deployment edition compose is Entitlements and the MCP tool tiers.