---
slug: developer-api-long-running-outcomes
title: Long-running outcomes
category: capability
status: published
tags: [outcome, target, deadline, metric, playbook, long running, poll, 长期目标, 指标, 轮询]
aliases: []
lastEditAt: 2026-08-02
---
Some work does not finish in one turn. A Task can carry a durable target, an
observed Metric, and a bounded review that keeps running after the first
result.

For durable outcomes, `outcome.target` is the success target,
`outcome.deadline_at` is a future deadline, and `outcome.metric_id` must name an
active Metric in the execution workspace. The Metric is an observed signal: a new
sample does not itself declare success. Tycoon records its baseline on the
canonical Task. The accountable Lead must keep a bounded review before the
deadline and uses the existing supporting Routine owner when recurring
observation is needed.

`working_guidance` is bounded Task-local advice about method and output.
`playbook_id` refers to an existing Company Skill in the execution workspace; Tycoon
pins its current immutable revision at create time, so later edits do not change
this Task. Neither field can grant money, connector, tool, data, safety, or
lifecycle authority, and neither is a public Skill-management API.

On a read, `outcome` is `null` until a communication checkpoint exists. It is a
safe projection rather than a trace: it contains no prompt bytes, raw evidence,
connector diagnostics, runtime identity, or hidden child state. `playbook` is
`null` when no Company Skill was pinned; it exposes only the selected Skill id,
immutable revision id, and name, never the Playbook body.

Accepting an `outcome.target` records what the work is aiming at. It does not
promise the business result, and a Metric sample moving is evidence, not a
verdict.

## Next steps

- [Create and read Tasks](/help/developer-api-create-read-tasks)
- [Webhooks](/help/developer-api-webhooks)