Background
Currently a Plan execution stores a single output field in the database. This works well for plans that produce one final result, such as an investment brief or a summary.
However, more complex plans naturally produce several distinct deliverables from a single run. A job application plan, for example, produces two independent documents that a user will use separately: a tailored resume and a cover letter opener. Merging these into one output field forces the user to manually split them apart, and makes individual export or follow-up on a specific piece awkward.
What we need
Plan executions should be able to store and present multiple named outputs, where each output corresponds to a meaningful deliverable from the workflow.
For the job application plan this would look like:
Tailored Resume — the full rewritten resume
Cover Letter — the cover letter opener paragraph
Each named output should be:
Displayed as a separate tab or section in the result view so the user can read and act on them independently
Individually exportable as PDF or Word without needing to export the entire run
Individually refineable via the Follow-up field (the user can say "make the cover letter more informal" without affecting the resume output)
Acceptance criteria
A plan can declare that its final step (or multiple steps) produce named outputs
The execution result view shows each named output independently
Export actions work per output, not only for the full run
Follow-up conversations can target a specific named output
Single-output plans continue to work exactly as today with no change in behaviour
Why this matters
As the plan library grows toward more practical workflows (job applications, client proposals, research reports with appendices), the single-output model becomes a bottleneck. Named outputs make Plans significantly more useful for any workflow that produces more than one thing a user wants to keep and act on separately.
Background
Currently a Plan execution stores a single output field in the database. This works well for plans that produce one final result, such as an investment brief or a summary.
However, more complex plans naturally produce several distinct deliverables from a single run. A job application plan, for example, produces two independent documents that a user will use separately: a tailored resume and a cover letter opener. Merging these into one output field forces the user to manually split them apart, and makes individual export or follow-up on a specific piece awkward.
What we need
Plan executions should be able to store and present multiple named outputs, where each output corresponds to a meaningful deliverable from the workflow.
For the job application plan this would look like:
Tailored Resume — the full rewritten resume
Cover Letter — the cover letter opener paragraph
Each named output should be:
Displayed as a separate tab or section in the result view so the user can read and act on them independently
Individually exportable as PDF or Word without needing to export the entire run
Individually refineable via the Follow-up field (the user can say "make the cover letter more informal" without affecting the resume output)
Acceptance criteria
A plan can declare that its final step (or multiple steps) produce named outputs
The execution result view shows each named output independently
Export actions work per output, not only for the full run
Follow-up conversations can target a specific named output
Single-output plans continue to work exactly as today with no change in behaviour
Why this matters
As the plan library grows toward more practical workflows (job applications, client proposals, research reports with appendices), the single-output model becomes a bottleneck. Named outputs make Plans significantly more useful for any workflow that produces more than one thing a user wants to keep and act on separately.