Agent Framework
Sign Up Now →Sign Up Now
Agent Framework User guide

Carry work across sessions

A work list tracks explicit items and their checks. Supported lists can become durable workflows that wait for a person and resume after sign-off.

Available

Use the product server#

Work lists require the product server and an installed work-list template. They are unavailable in draft tests and the standalone local CLI service. Check Templates & checks on the agent before starting the scenario.

The sample large-refund template checks the order, records damage information, waits for a member of returns-team, then runs the refund effect. Ask your administrator to add and deploy the template; it is not automatically configured by creating a starter.

  1. Inspect the list#

    Ask the deployed practice agent to handle the sample large-refund scenario. Open Workflows, select the resulting list, and review each item, its evidence, and its completion check.

    A model saying “done” does not satisfy a human acknowledgement or execute an effect. Complete the required check for each item.

  2. Review promotion#

    Select Promote to workflow when available. Read the assessment and named workflow before confirming. Reasons such as WAITS_BEYOND_SESSION and NON_PURE_EFFECT explain why the list needs durable execution.

    Promotion must match a supported workflow. After confirmation, a run waiting on a person is parked and appears under Inbox → Workflow sign-offs.

  3. Handle the sign-off#

    Open the Inbox item, review the evidence and proposed effect, and respond with the required note. Your account must have the named role; admin access alone does not satisfy a returns-team sign-off.

    An approval lets the workflow continue. Rejection or expiry prevents that effect. Inspect the list afterwards: it can remain open with an unmet sign-off.

  4. Read both the run and the list#

    Open the run and inspect the sign-off and effect outcome. Then check the work list’s final state. A workflow run can finish while the business list is cancelled and its effect remains unrun.

    Completion check: identify the list state, the human response, and whether the effect ran. Do not infer all three from a run marked completed.

Cancel work that should stop#

An owner can use Cancel list… with a reason when a list should no longer proceed. Review any recorded effects first. Cancelling remaining work does not undo an action that already happened.

If a tool reports an unknown outcome, including AGENT_STATE_NOT_KEPT, investigate the action’s result before retrying. Keep the list, run, and effect references with the investigation.