Outcomes

An outcome is the record of a unit of value an agent delivered. Outcomes are the ledger you read to find out what your agents actually did — as opposed to how many messages they sent or tokens they burned.

What an outcome carries

Where they come from

Two paths:

• Conversational work. An agent closes its session by reporting the outcome itself, as its final act once it has delivered what was asked or hit a dead end.
• Task work. The outcome is materialized automatically when the task finishes. The status follows the task's result and the executor's final message becomes the summary — which is exactly why agents are told to write that final message as the deliverable rather than as a status update.

Agents don't supply their own conversation id in either case; the platform fills it in.

What makes a good outcome

Agents are instructed to judge the status themselves, honestly, against what they were asked to deliver — and the guidance is specific enough to be worth repeating here, because it's what makes the ledger trustworthy:

• Delivering the core of something with a few named exceptions is a success. Say what you couldn't do and why in the summary.
• Failure is for genuinely not delivering it.
• Error is for something breaking.
• Unknown is only for when you truly can't tell.

And the summary should be concrete:

"Created 16 of 19 draft vendor bills; 3 POs had no invoice on file, flagged

for follow-up"

beats

"did the AP work"

The numbers, names, and exceptions are exactly what a manager needs and exactly what a vague summary hides.

Why this rather than metrics

Token counts, message volumes, and uptime measure activity. None of them answers "is this agent worth what it costs?"

An outcome ledger does, because it's denominated in delivered work. It also makes a failing agent legible: an agent producing twenty outcomes a day that are all "unknown" is telling you something a dashboard of green checkmarks never would.

Reading them

Every agent has a Ledger tab, laid out like a notes app: the days it delivered something down the side, newest first, and the day you pick written out as one note — each entry's time, title and write-up, in the order they happened, with the facts, structured result and tasks behind it under Details. Days and times are in your organization's time zone: US Eastern unless an owner or admin changes it in Settings, so everyone reads the same days. Search finds an entry by any words in it — a PO number, a task name, something said in a comment — and narrows the days to the ones with a match. The organization's Outcomes page shows every agent's outcomes together.

An agent can also read its own outcome ledger, which is what lets a weekly-summary routine report on the week's work rather than being told what happened.

Commenting on an entry

The ledger is read-only: nobody edits what an agent reported. When an entry needs an answer or a correction, comment on it. A comment starts a session with the agent about that entry — the agent gets the entry and your comment, answers it, and when the comment asks for it, goes back and fixes or follows up on the work. Its reply appears under your comment, and the session stays in the agent's Chat so you can carry on there. Follow-up work the agent reports from that session becomes a new entry, linked to the one you commented on.

Honesty as a design property

The platform deliberately makes honest reporting the easy path:

• Reporting an outcome is cheap by design — it rides the turn the agent is already producing, so it costs no extra reasoning.
• Escalating instead of guessing parks the work rather than failing it, so admitting uncertainty is never punished.
• Partial success with named exceptions is explicitly a success, so there's no incentive to round up.

An agent that's penalized for saying "I couldn't finish" learns to say it finished. The design tries hard not to teach that.