Planning and tracking agent work beyond tickets

Origin. On September 28, 2026, Dru asked for this as part of Agentic Software (path agentic-coding), not a separate area. His hunch: teams may quickly move from tickets toward delegating larger swathes of functionality. Research the claim rather than assume it is standard.

Questions. How do teams represent scope and intent at feature scale? How do humans delegate to parallel agents, know what each proposes, intervene ergonomically, reconcile conflicts, and keep a current mental model of the system? Where do versioned specs, step plans, decision records, checkpoints, previews, acceptance tests and ownership fit?

Dru’s September 30, 2026 conversation, opened from the Anthropic manager-workflow post. Just-in-time planning and asking agents rather than people resonate with him. He has tried having agents summarize incoming asks for him or the team, but says even good summaries leave an unmanageable volume to follow. He wants to be out of the routine loop, with agents answering and closing requests themselves. This goes further than the source account’s ‘ask Claude first’ and automated morning customer-feedback digest: it changes who owns closure, not merely who compresses the queue. His statement is a proposed operating direction, not a claim that current agents reliably close all requests.

Dru’s qualification in the same conversation, September 30. He disagrees with treating planning through prototypes and PRs as the general answer. In his experience/assessment, agents can anchor on a prototype’s approach even when code is cheap; reworking that prototype may preserve the wrong solution. He favors fully throwing away discovery code, or building prototypes outside the eventual implementation environment, and then using early real interaction to elicit feedback and interest rather than relying only on interviews or discussion. This is a design hypothesis and personal judgment, not an established measured comparison. Keep distinct early, interactive discovery and incremental commitment to production code; just-in-time decisions need not make PRs the product plan. Ask in future traces whether the prototype was discarded, which observations survived into requirements, and whether the final agent implementation escaped prototype-approach anchoring.

Design question raised by agent-owned closure. A useful unit is a bounded request with a verifiable terminal state: answer or change delivered to its actual consumer, evidence of resolution, explicit owner and an accessible record; unresolved ambiguity, irreversible changes, privacy/security, legal commitments or contested priorities require escalation to a designated person. Instead of forwarding every summary to a manager, use sampling and exception review, and track reopenings, wrong answers, downstream repairs and requester satisfaction. Just-in-time planning can mean deciding when evidence and feedback arrive, while retaining constraints and escalation authority in advance. These are proposed checks to test, not observed outcomes.

One original planning-to-execution example (September 30). Faire’s named engineer described iterating a plan for a PR-triggered build-preview tool, dividing it into five stacked PRs and handing it to a cloud agent. The report claims two-hour agent run and a working internal tool within a day. No PR links, review time, merge status, actual use or repair are supplied; it supports the unit-of-delegation shift, not maintained-change economics. Feature trace tracks the missing evidence. Do not assume its PR plan would substitute for Dru’s separate discovery-prototype phase.

Evidence to seek. Firsthand production workflows with inspectable plans, task boundaries and human touchpoints; comparative data on parallelism and review load; failures in context drift, prototype-solution anchoring, hidden changes and conflict; interfaces that demonstrably reduce them. For closed-loop asks, seek original request-to-resolution traces with reopens and escalation denominators, not only agent replies or digest counts. Distinguish demos and work-in-progress from maintained systems. Connect to review autonomy, role responsibility, and cost and human attention.

Administrative correction. A separate area was created in misunderstanding and marked superseded. All substantive work belongs here.