Priority-to-task decomposition
When a Priority is created, Olga proposes 4-8 scheduled tasks — owners, hours, days and times — you iterate on and approve.
Phase 1
A Priority is a 90-day objective. The work that gets it done lives in Tasks. Priority-to-task decomposition is how Olga turns a freshly created Priority into a proposed set of scheduled Tasks you shape and approve — the most significant Phase 1 capability, and the one that most directly differentiates RunOlga: take the larger commitment, propose the concrete work, put it on the calendar, and let the owner correct it.
Olga proposes the breakdown and the schedule. You decide what gets created.
The flow
The decomposition runs as a conversation, not a one-shot generation. It begins the moment a Priority exists and continues until you approve.
- A Priority is created. Through conversational data entry, a Priority is captured with its outcome, its timeline, and the seats contributing to it.
- Olga proposes 4–8 Tasks, scheduled. She drafts the breakdown from the Priority's outcome, its timeline, and its contributing seats — enough Tasks to cover the work, few enough to stay legible — and proposes a specific day and time for each, spread sensibly across the timeline.
- You iterate. You accept, edit, reject, or counter-propose, across as many turns as it takes. Olga revises the proposal each time.
- Approved Tasks are created. Only the Tasks you have explicitly approved are written — and they appear in the Planner and on the assigned seats' To-Do lists.
This is a proposal, not a plan Olga commits on her own. She prepares and surfaces the breakdown; the shape of the work — and the decision to create it — stays with you.
What each proposed Task includes
Every Task Olga proposes carries three pieces of context so you can judge it without leaving the conversation.
| Field | What Olga proposes | Where it comes from |
|---|---|---|
| Suggested owner | A single contributing seat to carry the Task | Drawn from the seats already attached to the Priority |
| Estimated effort | A rough size for the work, in hours | Inferred from the Task's scope against the Priority's outcome |
| Suggested schedule | A specific day and time for the work to happen | Spread across the Priority's 90-day timeline, balanced against what is already in the week |
These are starting points, not commitments. Owners, effort, and schedule are all yours to change before anything is created.
How Olga schedules
Scheduling is what turns a breakdown into a week you can actually live:
- She spreads work sensibly across days instead of piling it all on one.
- She warns about overallocation. When a Priority's tasks would exceed realistic capacity — "Wednesday has 11 hours scheduled — that's too much" — she flags it in the proposal.
- She suggests rebalancing when new priorities arrive, proposing how to adjust — at decomposition time or when you ask. Proactive rearrangement driven by capacity analysis is Phase 2; see Scope & roadmap.
- You can always override — approve a different schedule in the conversation, or drag tasks around the Planner afterward.
How you respond
The proposal is fully editable. You have four moves, and you can mix them freely across turns until the breakdown is right.
| Your move | What it does |
|---|---|
| Accept all | Approve the whole proposed set as-is, ready to create. |
| Edit individual Tasks | Change a Task's owner, effort, schedule, or wording while keeping the rest. |
| Reject specific Tasks | Drop Tasks that do not belong, leaving the others standing. |
| Counter-propose | Describe the breakdown you want and have Olga redraft from your direction. |
Because the flow is multi-turn, you can edit a few Tasks, ask Olga to redraft the rest, drop one more, and only then approve. Nothing is created while you are still iterating.
What gets written, and when
Nothing is created without your approval
Once you approve, each Task is written to the Tasks record with the fields below, and appears in the Planner and on the owner's To-Do list.
Task
├─ priority_id the Priority this Task was decomposed from
├─ assigned_seat_id the contributing seat that owns the Task
├─ estimated_hours the approved effort estimate
└─ scheduled_for the approved day and time the work happensThe priority_id keeps every Task linked back to the Priority it serves, so
the objective and its work stay connected — and colored together in the
Planner.
An example
The dialogue below is illustrative. It shows the loop in miniature: Olga proposes, you edit, you approve.
You: I just added the priority to launch the new caregiver onboarding program by end of quarter.
Olga: Here is a first breakdown — 5 tasks across the quarter:
- Draft the onboarding curriculum — Director of Care, ~8h, Tue Jul 28 & Wed Jul 29, 9:00–13:00
- Build the training materials — Director of Care, ~12h, spread over the week of Aug 10, mornings
- Set up the scheduling workflow — Operations Lead, ~6h, Thu Aug 20, 9:00–15:00
- Run a pilot cohort — Director of Care, ~10h, week of Sep 7
- Review and finalize — Operations Lead, ~4h, Fri Sep 25, 13:00–17:00
That keeps every day under 6 hours of priority work. Want to accept these, change any, or take a different cut?
You: Move the scheduling workflow to the Director of Care, and the pilot feels light — make it 16 hours.
Olga: Updated: 3. Set up the scheduling workflow — Director of Care, ~6h, Thu Aug 20 4. Run a pilot cohort — Director of Care, ~16h, split across Mon–Wed the week of Sep 7
Heads up: that puts about 11 hours on the Director of Care the week of Aug 17. Want me to slide the workflow setup to the following Monday?
You: Yes — and create all five.
Olga: Done. Five tasks created under the caregiver onboarding priority, each linked back to it. They're in the Planner and on the Director of Care and Operations Lead To-Do lists.
Notice what Olga does and does not do: she proposes a breakdown and a schedule, warns when a week looks unrealistic, adjusts on your word — but she never decides the work is right or creates it until you say so.
Related
- Priorities and Tasks — what a Priority is and how Tasks hang off it
- The Planner — where approved tasks land, and how to reschedule them
- To-Dos — the owner's view of the same tasks
- Conversational data entry — how the Priority gets created in the first place
- Grounding and confirmation — the confirmation-before-writes rule in full