Chat decisions and organisation activity

Review a founder decision

Open a founder decision from Today to review the source snapshot, preceding stage outcome, any records the preceding stage attached (a plan, for example) and expected decision. Only the owner can read or answer it. The proposal is filled from the preceding outcome; review and edit it before recording your decision. AI Assist uses that evidence when helping you revise the wording. When the chain carries a stage plan, the page shows it in full: the plan type and title, the decision it answers, its owner, the amount or headcount where given, the review date and the measure. A CHAIN7 experiment or hiring proposal shows before you decide; a CHAIN6 capacity or budget plan shows once the Revenue leader records it after your decision.

Recording a decision completes this stage, attaches the decision as the stage's output, and opens the next waiting stage, if there is one. Declining preserves your reason and marks later waiting stages unresolved. Neither action sends a message, changes a provider or executes the proposed work. Missing source evidence or an unfinished preceding stage prevents a decision.

Review a chat decision

Open a Slack or Microsoft Teams request from Today to inspect its stored approval and execution state. The selected request remains scoped to its owner. Approval, provider success and an unknown outcome are separate facts. A failed read shows unavailable. The page reads top to bottom as the other work pages do: the Team decisions heading, a notice that names the state of the request, then the chat card beside the application decision.

A request waits 72 hours for a decision. After that its Approve button does nothing and says so, nothing is sent, and Today stops listing it; ask again in the thread for a current version. Denying still works. An approval given in time keeps its safe retry after a provider rejection. The card shows when the request expires and its revision, the same fingerprint a Teams card is tied to, so you can tell two versions of a request apart.

The card quotes the message you were asked to approve, read from the stored request. When the request holds no message text, it says "Message not recorded" rather than guessing. The rest of the provider payload stays off the page.

The notice at the top names what the record shows: waiting for your decision, expired without one, denied with nothing sent, approved with the provider reporting success, or approved with the outcome unknown. The Scope row says exactly what an approval covers: which action, through which provider, to which destination, run once.

If you open a request with an account that does not own it, the page shows Access required and asks you to open the application with an authorized account. It shows nothing about the request, and it reads the same whether the request belongs to someone else or does not exist.

Approve or deny through the original chat request after reviewing the exact destination and message. This page does not introduce another approval control. Organisation activity and provenance remain in the disclosure below, with the existing colleague-content boundary.

Today remains your pending-work list. This detail view shows only recorded evidence. A verified contact is not implied by the presence of a request.

Overview

Org inbox is where you watch the fleet. Every scheduled run across your organisation appears here with its outcome, how long it took, and what it produced in counts. Alongside it sits anything the system will not decide on its own, and a lookup that answers "why does the agent believe this about this account".

If you do not hold a role yet, the page explains what will appear after your first scheduled run, shows a small preview, and gives you one way to choose a seat. It does not pretend an empty inbox is a quiet organisation.

You see that a colleague ran something, not what it said

This is the part worth understanding before you use the page, because it is deliberate and it is enforced by the database rather than by the screen.

Your organisation's activity is shared: every seat can see which role ran which skill, when, whether it succeeded, and what it cost. Your organisation's content is not. A run belonging to a colleague shows a "metadata only" marker, and the artifact behind it does not load, because your session is not entitled to read it.

The exception is anything shared on purpose. A finding promoted to team or organisation visibility is readable by everyone it was promoted to, which is the whole point of promoting it. Your own drafts stay yours unless you promote them.

This is the same boundary the leadership rollups have always had: a manager sees that a rep's agent worked, never the words it wrote. The inbox does not widen it.

Waiting on you

Lessons and candidate prompts also reach you through Today, ranked against everything else that needs you. Each item opens its own evidence and decision controls here.

This page still explains what each decision is and what accepting it does. The ruling itself happens on the Org inbox, opened from the item: following one takes you to that lesson or candidate on its own, with the evidence behind it and the two verbs. There is no list here to work through, only the thing you clicked.

A lesson someone else has already ruled on, or one your seat is not entitled to see, says so rather than showing you an empty card.

• A lesson. Your agents extract durable craft from what actually happened, for example that naming a compliance deadline in the first line earns replies on manufacturing renewals. A lesson the system is confident about and can tie to a real buyer event accepts itself. A lesson it is unsure about waits here. Approving one changes what every seat in its scope is grounded in from the next run onward, so each card shows the claim, how confident the system is, and the observed signal it rests on.
• A candidate prompt. A proposed change to how a skill is written can run in shadow against a slice of your real traffic first. Its output is scored and never delivered to anyone. The card shows how the candidate did against the live version on the same runs, because a candidate's own pass rate means nothing without knowing what live did on that week's work.

Rejecting either needs a reason. A refusal nobody can review later is not a decision, and both of these are kept as a record rather than deleted.

Why does the agent believe this?

Give the lookup an object type and a subject key (a company and its domain, for instance) and it lists every live fact your organisation holds about it: the claim, how far it is shared, who established it, and which agent recorded it.

Two things are worth reading closely:

• "Needs recheck" means something the fact was derived from has since been retracted. The fact is still believed and is flagged for revalidation; it has not silently disappeared, and it has not silently stayed true either.
• An empty result means no facts you are entitled to see, which is not the same as none existing. The page says so rather than implying the account is unknown.

What it costs

Nothing. The inbox reads what has already been recorded and runs no model of its own. The one figure it shows that is about spend is the shadow cost on a candidate card, which is what the shadow runs have cost so far, so the price of an experiment is visible before you decide whether to keep it going.