Post workflow results back into chat and answer follow-ups from them

Summary

Part of #1543 (Phase 6). When a plan starts a workflow run from a private chat, the plan ends right away ("Started Weekly digest. I'll post the results here when it finishes."). When the run finishes, even hours later with the browser closed, the server posts an AI answer to the original request into that chat. Follow up lets the user ask questions that are answered from the stored run result.

User Value

A chat plan can't wait for a long workflow. Its deadline is 900 s by default and 7,200 s at most, while a durable run can take 24 hours. Posting the results later means the answer arrives where the user asked, with the same unread dot and notices as a normal reply, and the user can keep asking about it without re-running the workflow.

Proposed Behavior

6a: results reader and Follow up (depends on Phase 4)

One server reader for workflow results in chat. It authorizes through authorize_workflow_run_read and authorize_workflow_task_result_read (functions_workflow_results.py:358-530), reads bounded pages from the result store, and returns a snapshot descriptor with the run, status, completion time and result SHA-256. Personal workflows only.
Follow up, modeled on saved-analysis follow-ups (functions_saved_analysis.py, V2 lib/savedAnalysis.ts):
- a composer chip: "Answering from the Weekly digest run of Mon 9:02 AM — not re-running the workflow"
- the request sends workflow_result_context. Other sources are off for that turn, reads are bound to the result SHA, and later turns inherit the context.
- clear messages when the result changed or access was lost
- entry points: the delivered message, the run card, the recurring-workflow card, and Ask in chat on a run in the V2 Workflows page
A read-only planner capability, workflow_results, for questions like "what did my Monday digest find last week?"
Follow up and workflow_results are unavailable in shared and collaborative chats.

6b: post-back delivery, run card and chat-list indicator (depends on Phase 5, 6a and N1)

A chat_delivery record on the run (personal_workflow_runs, so no new container and no deployer change) with the origin conversation, request message, requester, model selection, status and expiry.
Workflow finalization triggers delivery, and a background sweep with a distributed lock picks up anything missed. Delivery:
1. claims a lease
2. re-checks that the chat is still personal, private and owned by the requester, and that the requester can still read the run
3. waits for the next sweep if a reply is streaming in that chat
4. composes from a bounded excerpt, with run output fenced as untrusted content
5. creates the message with a deterministic ID
6. marks the chat unread and creates the "AI responded" notice idempotently
A failed or cancelled run posts a short note with Open run and Retry.
If the result can't be delivered (chat deleted, made shared, access lost, or expired), nothing is posted and the bell gets one notice that links to the run.
An owner-only, batched status route for the user's chat-linked runs.
V2:
- a WorkflowRunCard with Running, Needs you, Finished and Failed states
- one tracker in the app shell
- a WorkflowRunningTag spinner in the chat list
- a recurring-workflow card for approved Phase 4 proposals
- a run deep link, such as /workspace/workflows/:workflowId/runs/:runId

6c: in-plan wait (later, optional)

A saved_workflow_run wait kind for quick runs, added only if planners need a workflow's output later in the same plan.

Acceptance Criteria

6a: Follow up answers only from the stored run result, a changed result or lost access shows the unavailable message, "what did my digest find last Monday?" reads the right run, and shared chats can't read workflow results.
6b: a run started from a private chat posts exactly one answer through restarts, retries and concurrent sweeps.
6b: closing the browser, reloading, or pinning the chat and coming back later all work. The unread dot appears, with no extra pop-ups.
6b: the card moves through Running, Needs you, and Finished or Failed, and Check now works.
6b: a deleted or shared chat, or lost access, gets no post and exactly one bell notice, and a delivery never lands mid-stream.
Functional tests, route policy tests for new routes, Playwright coverage, a feature doc, release notes and a config.py version bump for each part.

Notes

Roadmap: §6, Phase 6 and decisions 4 and 11–14 in §2. Related gotchas in §8: 31–45.
Open decisions (§9), with recommendations: results stay available for Follow up until the run is deleted (a retention setting can come later); keep trying to deliver until the durable deadline plus 24 hours; use /workspace/workflows/:workflowId/runs/:runId for the run deep link; add 6c only if planners need it.
Also in §9: detached orchestration answers don't mark the chat unread today (gotcha 34). That's a small separate fix that can reuse 6b's helper.
Depends on: 6a on Phase 4 (Let chat orchestration propose workflows with an Approve, Deny and Edit card #1547); 6b on Phase 5 (Let chat orchestration run existing durable workflows #1551), 6a and N1 (Add a notification bell, panel and desktop notifications to the V2 UI #1554). Phase 7 (Hand off big one-time jobs from chat to a durable workflow #1549) depends on 6b.

Withhold workflow results from collaboration copies, exports and replays

Test that a message's own Follow up context marks its turn

Document where workflow-result answers are withheld

Import uuid as a module in the offline workflow-result harness

Clear the chat summary in the group route's private-chat conversion

Document workflow results in chat

Pin each owner comparison in the workflow result reader

Update roadmap status: 6a done, 6b split, microsoft#1597 fixed

Align the roadmap with container-only result access and self-authored…

Merge origin/paullizer-react-v2-ui into 6b-2

Pin every PermissionError answer of the runtime response as a 403

Merge origin/paullizer-react-v2-ui into 6b-2

Set the run card harness's first stream number through the constructor

Test the workflow run notices and the recurring card's run lines

Document V2 workflow run tracking and posted results (6b-2)

Add 0.261.233 release notes for V2 workflow run tracking (6b-2)

Renumber 6b-2 to 0.261.234

Update roadmap status: 7b done; the capability is complete

Phase 6 complete (6a and 6b)

6a and 6b are merged into paullizer-react-v2-ui. 6c, the in-plan wait, is deferred (see Follow-ups).

6a, the results reader and Follow up: Phase 6a: workflow results reader and Follow up in chat #1592 (0.261.214), merged as 520132d. It's behind Use Workflow Results In Chat (enable_chat_workflow_results), which is off by default.
6a, the workflow_results planner capability: Read saved workflow results from chat orchestration (workflow_results) #1607 (0.261.217), merged as 8a802f1.
6b-1, server delivery and the status route: Phase 6b-1: post workflow results back into chat (server and status route) #1610 (0.261.227), merged as ac63b3a.
6b-2, the V2 run card, tracker and chat-list indicator: Phase 6b-2: show chat-started workflow runs and their posted results in V2 #1639 (0.261.251), merged as 6bd12cf.

Acceptance criteria

6a: Follow up answers only from the stored run result. Reads are bound to the result's SHA-256, so a changed result or lost access shows the unavailable message. "What did my digest find last Monday?" reads the right run through workflow_results (Read saved workflow results from chat orchestration (workflow_results) #1607). Every turn checks that the chat is private, so shared, collaborative and converted chats can't read workflow results.
6b: a run started from a private chat posts exactly one answer. The message ID is a hash of the run, the chat and the delivery generation. A lease and a sweep lock keep concurrent sweeps from posting twice, and a delivery reopens only when the durable run resumes.
6b: the server marks the chat unread before it creates the message, so the unread dot is there after the browser was closed. The tracker keeps a baseline for each chat, so a reload doesn't announce the same run twice, and there's no extra pop-up. No test pins the chat first.
6b: the card shows Queued, Running, Needs you, Completed, Partly completed, Failed, Timed out, Cancelled or Status unavailable, and Check now reads the run again. In a visible tab the tracker checks at 15 s, 30 s, 1 min and 2 min, then every 5 min. A hidden tab checks every 5 min, and only while desktop notifications are on and a run is in flight.
6b: a deleted or shared chat, or lost access, gets no post and one bell notice. While a reply is streaming in the chat, the delivery waits for the next sweep.
Functional tests, route policy tests for the new routes (route_tests/test_workflow_result_context_policy.py, plus the route inventory and unauthenticated-contract entries), Playwright coverage (test_v2_workflow_run_card.py, test_chat_workflow_results.py and test_v2_workflow_run_tracker_spa.py), the feature docs CHAT_WORKFLOW_RESULTS_FOLLOW_UP.md, CHAT_ORCHESTRATION_WORKFLOW_RESULTS.md and CHAT_WORKFLOW_RESULT_DELIVERY.md, release notes and a version for each part.

Verified from tests and review, not on a live tenant.

Where it differs from the issue

Run deep link: /workspace/workflows?workflow_id=…&run_id=…. The proposed /workspace/workflows/:workflowId/runs/:runId would collide with the /workspace/:section/:resourceId route.
Needs you: the card doesn't approve anything. Review and approve opens the run, which shows the approval prompt.
Retry resumes the same durable run. Cancelled and skipped runs can't be retried.
Follow up starts from the delivered message, the recurring-workflow card (Open latest results and Follow up), Ask in chat on a run, and Ask about this on a workflow alert. The run card has Open run, Check now, Review and approve, Retry and Cancel, but not Follow up.
The card doesn't show which step a run is on, because the status route always returns an empty step name.
In a chat with more than 20 chat-started runs, the older runs show only Phase 5's links.
Follow up on a v3 workflow run is refused with workflow_result_unsupported, except for a hand-off's report.
If the workflow is deleted or its runtime control is missing, the delivery closes without a notice.

Validation on each PR's final head

Phase 6a: workflow results reader and Follow up in chat #1592 at badfff8: CI 11/11, and CodeQL reported no new alerts. The review passed at 47187e4. The three commits after it move conversation_is_private, merge paullizer-react-v2-ui (Roadmap status: Phase 3 complete, Phase 5 done, 6a in review #1595) and edit a comment.
Read saved workflow results from chat orchestration (workflow_results) #1607 at 3059ac4: mutations 60/60 and UI mutations 16/16. Batch B: 2,318 passed under both normal Python and -O. CI 11/11, and no new alerts.
Phase 6b-1: post workflow results back into chat (server and status route) #1610 at 543f1a5: 16 suites in 4 modes all passed (worker 112, run adapter 129, status route 48, contract 72 and the rest), plus route inventory 11, unauthenticated contract 6 and imports 31. Guardrails found 0 blockers. The review's mutations, at edd7484, were all caught except two, which were accepted as equivalent or optional. 10 checks passed. The CodeQL check was neutral ("2 configurations not found"), while the Python, JavaScript/TypeScript and Actions analyses succeeded. An earlier head, edd7484, reported no new alerts.
Phase 6b-2: show chat-started workflow runs and their posted results in V2 #1639 at bd1a250: 429 passed across 18 jobs, mutations C1–C7 and U1 killed, and guardrails found 0 blockers. CI 11/11, and no new alerts.

Follow-ups (not blocking)

6c, the in-plan wait, is deferred. The issue says to add it only if planners need a workflow's output later in the same plan.
Add a test that pins the chat before a delivery lands.
Gotcha 34, where detached orchestration answers don't mark the chat unread, wasn't in 6b's scope and hasn't been re-checked.
The remaining items in each PR's Follow-ups section.

This issue is ready to close.

Add the wait-for-quick-workflows setting and its wait cap

Navigation Menu

Repository navigation

Post workflow results back into chat and answer follow-ups from them #1546

Summary

User Value

Proposed Behavior

6a: results reader and Follow up (depends on Phase 4)

6b: post-back delivery, run card and chat-list indicator (depends on Phase 5, 6a and N1)

6c: in-plan wait (later, optional)

Acceptance Criteria

Notes

15 remaining items

Phase 6 complete (6a and 6b)

Acceptance criteria

Where it differs from the issue

Validation on each PR's final head

Follow-ups (not blocking)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Post workflow results back into chat and answer follow-ups from them #1546

Description

Summary

User Value

Proposed Behavior

6a: results reader and Follow up (depends on Phase 4)

6b: post-back delivery, run card and chat-list indicator (depends on Phase 5, 6a and N1)

6c: in-plan wait (later, optional)

Acceptance Criteria

Notes

Activity

15 remaining items

paullizer commented on Oct 8, 2026

Phase 6 complete (6a and 6b)

Acceptance criteria

Where it differs from the issue

Validation on each PR's final head

Follow-ups (not blocking)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions