Ask the org

Overview

Ask the org takes one question and puts it to every role agent you hold. Each role answers from its own records only: Customer Success from health scores and tickets, the Sales Engineer from technical validation and open product gaps, and so on. A final pass reads those answers and writes one synthesis.

The role you are asking from is left out of the plan on purpose. You already have that view, so paying a second time for it adds nothing.

You see the plan before you spend

"Preview who gets asked" runs the planner and stops there. It shows exactly which roles would answer, the instruction each one would get, and roughly how many turns the run costs. Nothing has run at that point and nothing has been charged.

This is on the page rather than hidden in the API because the plan decides whose perspective ends up in the answer, and that is the one thing you are best placed to judge. If the plan leaves out the role that actually knows, you want to find that out before the run, not after.

If the preview shows the run would cost more than your remaining budget for the period, it says so with the figure, and the run button goes away. You can narrow the question or raise the cap.

Every claim traces to a role that read it

The answer carries a chip per role saying whether that role answered. The pass that writes the synthesis has no tools and no access to the underlying records: it can only work from what the roles reported. That is what makes the attribution meaningful rather than decorative, and it is why a synthesis can never quietly introduce a fact no role actually found.

A role that fails is shown, not hidden

One role failing does not fail the run. An answer built from three roles out of four is worth having, so you get it, with the missing role marked and its reported reason shown beneath. What you never get is a gap filled in silently.

If every role fails, there is no answer at all. A synthesis over zero readings would be the model's assumptions wearing your org's name, which is worse than nothing because it looks like something.

When it refuses, and why that is the feature

Three refusals happen before any spend. The run costs more than your remaining budget. No other role you hold can add anything, which happens when you hold one role and are asking from it. Or a role faces more tools and topics than one agent routes well, in which case it refuses and names the role rather than answering worse and saying nothing about it.

In all three cases nothing runs and nothing is charged, and the message says which case it was.

Nothing here writes anything

Every role agent in a run is read-only, enforced before any of them start rather than by convention. A run can tell you a renewal is at risk; it cannot update the opportunity, send the email, or create the task. Those go through the normal proposal path where a human approves them.

What-if questions

A question shaped like a scenario is answered by the world model before any role is asked, so it costs nothing and returns at once. "What if we hire two reps", "what if we raise price 10%", "what if the Acme expansion slips 30 days" and "what if we bring an exec into Globex" each become a lever on the same simulation the scenario card runs. The answer says how it read your question first, so a misreading is obvious, then how the quarter moves, then how much of that rests on measurement and how much on assumption.

Under the answer, the deals your question touched (or, for a change to the whole book, the three with most at stake) show their chance of closing this quarter before and after the change. Each carries the calibration badge: the evidence label, and how often your calls in that range have come true. The odds after the change carry the weakest label among the levers behind them. See reading the badge.

A deal is matched only by a name in your open pipeline. A what-if the page cannot map to a lever, such as "what if the market turns", goes to the roles as an ordinary question.

Asking for work instead of an answer

The same page takes a second kind of request. Say what you want done rather than what you want to know, in whatever words you would use to a colleague, and the intake card names the role that does it.

It names the role and stops. There is no run button here, because the run belongs in that product's console where the approval gate and the budget already sit. A button on this page would be a second door into paid work with neither of those behind it.

Each console takes the same kind of request and can run it, under Ask for work in plain words on its Schedule tab. The difference is reach: a console looks at the seat you are in and links out when the match belongs to another role, while this card searches every role you hold at once. Use this one when you do not know whose job it is, and the console when you do.

It refuses three ways and says which: nothing matches closely enough, two roles match equally well, or there is nothing at all. A tie is reported as a tie rather than broken for you, because picking one of two equal matches silently is how work ends up in the wrong console.

How it is shown

A question box with the role you are asking as, then two buttons: preview, and ask. The plan appears as one card per role with the instruction that role would receive. The answer appears below it with its attribution chips, and any refusal or missing role appears as its own flagged note. Changing the role you are asking as clears the plan, since the plan depends on it.

The work-intake card sits beside it with its own box and one button. Its result is a named role and a pointer to the console that runs it, or the reason it will not guess.