The Motir agent loop — plan → implement → deploy, closed end to end

Motir is the AI planning, project-management and agent orchestration platform. The first two pillars are built. This epic is the third one made whole — not "agents exist", but the loop closes: a plan turns into work an agent takes over, that work ships and deploys, Motir sees what actually shipped, and the next plan is grounded in it.

One turn of the loop

   PLAN in Motir  →  an AGENT takes over the work  →  it SHIPS and DEPLOYS
        ↑                                                      │
        └──────────  Motir SEES what actually shipped  ◀────────┘

Every hop above exists in some form today; the circuit does not. A user plans in Motir, hands a work item to their own agent over the MCP, and then Motir goes dark: it does not know a run is happening, it cannot show what the agent did, it never sees the code that came back, and the next planning pass runs blind against a tree it can no longer ground. A loop with one hop missing is not a slower loop — it is a line, and the whole third pillar rests on it being a circle.

Scope — the legs this epic owns

Hand-off (plan → agent), and watching it happen.

• Agent runs — the shared run record + live run surface — one persisted execution record and one live run surface that EVERY way an agent works reports through: the BYOK-local CLI loop today, hosted execution (Epic 9) later. This is what turns "the board says in_progress" into a watchable object with a step timeline, an outcome and a PR link.
• The sandbox setup guide, published in the docs surface — the adoption path for the confined sandbox an unattended run executes in, on the public docs surface rather than behind a git clone.

Return (shipped → plan), so the next turn is grounded.

• Close the BYOK code-index loop — connect prompt after the plan, index freshness, and an explicit code-blind planning signal. Without this the return hop silently does not happen: planning degrades to code-blind and never says so.
• Run the historical-PR mirror backfill + re-run the provenance backfill — the operator run that makes already-shipped work attributable, so the loop's own history is readable.

Planning inside the loop — talking to the plan, not just editing it.

• The AI assistant — Ask about this project — cited answers over plan, docs and work items, in the one universal conversation.
• The AI assistant — Help with a task — item-scoped assistance that drafts and applies a work item's own content. Builds on Ask's per-turn intent model.

The loop learns from its own turns.

• Port the un-seeded lessons into lessons.base.ts — the corpus the planner retrieves from has drifted ~75 entries behind the record; this batch closes it and closes the totality hole that let it drift silently.

Moved back out, 2026-08-05. Captured planning-mistake bugs was briefly filed here as this leg's other half. It is back under its own epic, where the filer resolves it — it is a RUNTIME container for auto-filed bugs, not work this epic sequences. The learning work this epic owns is the lessons port above.

Boundary — where this epic ENDS

• The DEPLOY leg is NOT yet planned, and that is deliberate, not an oversight. The loop's stated span is plan → implement → deploy, and nothing gathered here owns the deploy hop — what "shipped" means past a merged PR, what Motir observes about a deployment, and how a deployment outcome feeds the next plan. This epic is the container that will own it; the stories are planned in a later pass (Yue, 2026-08-05: "don't plan other new stories. we will plan new stories later"). Until then this epic is honestly incomplete against its own title, and the gap is named here rather than hidden.
• It does NOT own hosted agent execution. Container orchestration, provisioning, run-scoped auth and lifecycle enforcement stay with Epic 9; this epic ships the seam Epic 9 writes into, so a hosted run becomes a second WRITER of an existing record rather than a second run UI.
• It does NOT re-open the planning substrate. The generation engine, the plan-change conversation, the retrieval, the gateway and the provider integrations are Epic 7's and already shipped; this epic composes them.
• It does NOT own the docs SHELL. The public documentation surface, its rail and its content-as-data renderer are the public-API epic's (11.4); the sandbox-guide story adds one page and one rail row to a shipped surface.
• It does NOT own platform-wide rollups. Cross-tenant run and spend aggregation is Epic 10's.

Dependency shape

Every cross-epic need is carried at the EPIC level. No story under this epic is blocked_by a story outside it (re-plan 2026-08-05).

• This epic is blocked_by Epic 7 — the loop builds on the AI planning layer. Chosen with the cost understood: Epic 7 is in_progress, so readiness cascades and every story here reads not-ready until Epic 7 closes, even though each one's actual prerequisites are already-done Epic 7 stories (the CLI, the git integrations, the planning workspace, the callout shell, work-item provenance, the repository set).
• This epic is blocked_by the public REST API epic — the sandbox guide mounts into the public docs surface 11.4 shipped. Same trade as above: the story's own prerequisite is done, and the lifted edge gates on the whole epic. Recorded this way because a story edge across an epic boundary is the thing the plan rules forbid; if the cascade ever costs more than the honesty is worth, DROP this edge rather than re-hanging a story-level one.
• Epic 9 is blocked_by this epic — hosted execution writes into the execution record MOTIR-1789 owns. Three Epic 9 cards were authored against a table no card was creating; this edge records the real order rather than leaving it to be rediscovered mid-run.

With the pre-existing Epic 7 → Epic 9 edge these form a DAG: Epic 7 → this epic → Epic 9, with the public-API epic → this epic joining at the same node. validate_work_item on this epic therefore returns valid: false naming exactly those two blockers, and that is the recorded intent, not a defect to repair. The ACTIVE sprint is unaffected: MOTIR-1754 sits in the planned Sprint 38, which will hold this epic's gated work when it opens.

The eleven satisfied cross-epic STORY edges this epic was seeded with are GONE (2026-08-05). They were left in place at seeding time on the reasoning that a done blocker never gates and each would stay correct if its prerequisite were ever re-opened. That reasoning is wrong on the rule that matters: plan-rules.md requires every blocked_by to join two SIBLINGS of the same kind under the same parent, and a cross-epic story dep is LIFTED to an epic↔epic edge, never kept. What was removed, and where each need now lives:

No ordering information was lost — every dropped blocker is done, and each is still named on its story as a relates_to and in prose. Within the epic the only real edge is Ask → Help with a task; the remaining legs are genuinely independent and run in parallel.

A defect this pass found — the planner-bug home no longer resolved (FIXED, in review)

Verifying that re-filing the captured-mistakes story was safe turned up a live break in the self-learning loop, pre-existing and independent of that move. aiWorkItemsService.fileBug resolved the @planner-bug-home marker as the first story child of the epic titled "Planner self-improvement — auto-reported quality bugs" (MOTIR-1464). That epic had no story child at all, so the marker path raised WorkItemNotFoundError and the inward loop could not file.

Tracked and fixed as MOTIR-2201 (PR open, in review): the marker now resolves to the home epic itself — a row a move_to_parent cannot void — and an unresolvable home fails loudly instead of being swallowed. The story has since been moved back under that epic, which independently restores the old path; the fix is what stops the next re-organisation from breaking it again in silence.