Outcomes
The per-agent ledger of delivered value — what your agents actually produced, not how many tokens they burned.
On this page
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
| Field | Meaning |
|---|---|
| Status | success, failure, error, or unknown |
| Title | Short label |
| Summary | One to two sentences on what was accomplished, or why not |
| Result | Structured detail where the work produced any |
| Session | The conversation it was recorded from |
| Requester | The user or delegating agent who asked |
| Tasks | Every task it was assembled from, with the agent's side (executed or delegated) and each task's status, progress, and instructions |
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
The console shows outcomes per agent and across the organization, freshest first, with the tasks each was assembled from. 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.
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.