How the plan learns from execution
Most plans are written once and never learn. The estimates that go in on day one are the estimates you live with, and when they turn out wrong the dates quietly drift. Plenar works the other way: every time you start, finish, block, or re-estimate a task, the result feeds back into the plan and the dates recompute. The plan you look at on day 30 is built from what actually happened, not the guesses you made on day 1.
The feedback loop
The recompute feeds straight back into the next plan, so the loop repeats — and each pass through it sharpens your estimates.
- Plenar computes your plan from your tasks, team, and dependencies.
- You execute — start tasks, complete them, hit blockers.
- Each action emits an execution signal that updates the plan.
- The plan recomputes from what actually happened.
- Over time, estimate accuracy improves.
Execution signals that feed back
Every one of these is an execution signal — none of it requires manually editing the plan:
| Action | What happens | How it enters |
|---|---|---|
| Task started | The start date is anchored, and downstream tasks lock to it. | plenar_start_task or dashboard |
| Task completed | The actual duration is recorded, dependent tasks can begin, and the schedule recomputes. | plenar_complete_task or dashboard |
| Blocker reported | The task is marked Blocked and Plenar surfaces other tasks you can pick up. | plenar_report_blocker or dashboard |
| Estimate revised | The timeline shifts for the task and everything downstream. | plenar_update_estimate or dashboard |
| Work linked | A pull request or commit is connected to the task. | plenar_link_artifact |
| Time off added | Capacity drops for the affected days and tasks shift. | Calendar sync or plenar_add_time_off |
| Scope changed | Tasks are added or removed and the plan recomputes. | plenar_add_tasks, plenar_delete_tasks |
The plan stays current because these updates are part of the normal flow of work, not a separate bookkeeping step.
The signals Plenar captures
Those plan edits are the tip of it. As you and your agents work — and as your git and CI activity flow in once Claude Code and your pipeline are connected — Plenar captures a much wider stream of execution signals. They fall into a few families:
- Lifecycle — work sessions and tasks starting and completing. Anchors actual start and end dates, records how long work actually took, and suggests what to pick up next.
- Code — commits, branches, pull requests opened, files changed. Ties code activity to the task it belongs to, so progress reflects what’s actually shipping, not status guesses.
- Quality — test, build, lint, and type-check results, plus failed commands. Tracks whether work is passing its checks — surfaced as CI pass rate, test trends, and review latency.
- Delivery — CI runs, merged pull requests, deploys, pushes to main, reviews submitted. Measures delivery cadence: deploy frequency, change-failure rate, and time to recover.
- Planning — scope discovered, blockers, decisions, estimate revisions, reassignments, dependency blocks, plan divergence. Reshapes the plan as reality drifts from the original assumptions.
- Cost — AI token usage. Attributes spend by model and by task.
- Calibration — an estimate-vs-actual snapshot, acceptance criteria completed, effort logged. Becomes the ground truth that sharpens future estimates.
Two things happen with this stream. Signals that change the work — a completed task, a new blocker, a moved deadline — recompute the plan. The rest become trends on the Insights tab: delivery, quality, cost, and cadence. Most of them arrive on their own once your agent and CI are connected, so you’re not emitting anything by hand.
Estimate calibration
For every completed task, Plenar keeps two numbers:
- Estimated days — what you predicted at planning time.
- Actual days — the working days the task really took.
Comparing the two across many tasks builds a calibration history for your team, and patterns emerge:
- Tasks consistently take 1.4× the estimate → your team underestimates by about 40%.
- Backend tasks land on time but frontend tasks take twice as long → accuracy differs by kind of work.
- One person’s estimates are consistently tight → calibration can be per person.
Call plenar_get_velocity_context to see this data — your calibration factor (how actual compares to estimated), whether accuracy is trending up or down, and your throughput (tasks completed per week). If your calibration factor is 1.4, a task you’d estimate at 3 days is probably closer to 4 or 5.
To estimate a specific new task, call plenar_get_exemplars to pull up completed tasks that touched similar areas of the work. Each one shows its title, original estimate, and actual duration — concrete reference points instead of a guess.
How agents keep it current
When you’ve connected Claude Code, your agent produces these updates automatically as it works:
- Starting work →
plenar_start_task→ the plan knows work began. - Finishing →
plenar_complete_task→ the actual duration is captured and the next task is suggested. - Stuck →
plenar_report_blocker→ alternatives surface. - Shipping →
plenar_link_artifact→ the pull request is connected to the task.
The agent doesn’t maintain the plan. The plan maintains itself from the agent’s normal workflow. External systems — your calendar, issue tracker, and identity provider — feed in the same way; see Integrations for setup.
Common questions
Do I have to update the schedule by hand? No. Starting, completing, blocking, and re-estimating tasks each update the plan on their own — whether you do them in the dashboard or through an agent.
How does Plenar know my estimates are off? It compares the days you estimated against the working days each completed task actually took, then reports the ratio as a calibration factor in plenar_get_velocity_context.
Where do better estimates for new tasks come from? plenar_get_exemplars finds completed tasks similar to the one you’re estimating and shows you their actual durations, so you can anchor to history instead of guessing.
Does the plan change the moment I complete a task? Completing a task recomputes the schedule with the actual duration. Like any change, you see the New Plan before it becomes the Plan of Record.
What to do next
- How scheduling works — what Plenar optimizes for when it builds the plan.
- Track progress with Claude Code — the daily loop that produces these updates.
- Goal health — how ETAs and target dates turn execution into health signals.
- Integrations — connect your calendar and issue tracker so they feed the plan too.