Panout review packOverviewFinal memoMVPLive outputsJudge roundsAppendicesDecisions

Source: DECISIONS.md

Panout decisions

Reverse-chronological record of product decisions from the current strategy work. New decisions go at the top. Earlier founding history remains in docs/decision-log.md.

Open decisions

2026-08-23 — Test a private quality model with outcome-based routing

Panout's strongest potential company is a private team quality model that powers a neutral decision layer before execution: classify a Linear task against the codebase, recommend the harness, model, reasoning level, skills, and relevant precedents most likely to meet the team's bar, then learn from independent acceptance evidence, human intervention, and later rework. The router interface is not the moat. A common outcome contract is required to compare configurations, but generic specification is infrastructure rather than the product. The hypothesis is defensible only if the private task/outcome dataset improves routing and remains meaningfully ahead of Entire Experts, Linear model selection, and Harness analytics.

2026-08-23 — Choose the first routing action boundary

The first product could only recommend an execution bundle, or it could also launch the selected local harness from Linear. The recommended boundary is recommendation plus one-click launch, with an explicit override and no live orchestration or monitoring. This must be confirmed before defining the v0 workflow.

2026-08-22 — Define the strict local-privacy boundary

Panout must work without Panout Cloud, but one boundary remains unresolved: whether local analysis may use the Claude or OpenAI services the developer already uses, or whether all Panout grouping, summarization, and retrieval must run through a fully local model.

2026-08-22 — Choose the capture and context-injection mechanism

The preferred experience has no recurring ceremony and avoids harness hooks. A spike must determine whether read-only local session adapters plus Git evidence can reliably capture and restore Claude Code and Codex task context. Git alone cannot preserve the human corrections and reasoning that give the product its value.

Decisions — newest first

2026-09-03 — MVP ships as a commit-boundary recorder with contracts; unit of policy is the contract

The MVP (prototype/panout.py) installs reversible prepare-commit-msg and post-commit hooks that evaluate contracts, print only failures, write Panout-Work and Panout-Contracts trailers, and record a metadata-only evaluation event with an override flag. Departures from the goal prompt, with reasons:

Not built, per the prompt: autonomy levels, auto-merge, cloud, UI, tracker integration, billing.

The ledger is append-only and records evaluations for commits that were later amended or reset (two such events exist from the first hour of dogfooding, both caused by committing while unrelated files were staged). status reports them as "no longer on HEAD" rather than deleting them; the record of what was evaluated is the product, and a reset is itself a fact.

2026-08-23 — Do not duplicate tasks to train the router

Panout will not routinely run the same engineering task through two agent setups. Duplicate execution raises model cost, compute use, review burden, and elapsed time before Panout has proved enough value to justify any of them. The router must learn from normal single executions, user overrides, corrections, natural retries, accepted results, and later rework. Because this evidence is observational, early recommendations must show their basis and avoid causal claims.

2026-08-23 — Entire is optional evidence, not Panout's foundation

Panout will not rebuild Entire's transcript, checkpoint, search, and session-resume stack. When present, Entire may supply read-only local evidence to the same normalized task/outcome graph as native histories, Git, CI, and PRs. Panout must remain useful when Entire is absent. The competitive test is recommendation quality, especially against Entire Experts, rather than archive breadth.

2026-08-23 — Execution reconciliation is not the company wedge

Drafting plan-versus-outcome updates for Linear may be useful, but it is straightforward for Linear, Entire, or a generic agent integration to add. It does not provide a strong right to win and should not lead the company strategy. It may later be an output of a broader task/outcome graph.

2026-08-23 — Panout does not own live agent task state

The harness owns whether a session is running, blocked, waiting for input, or needs the human. Panout cannot observe those states reliably enough to build a product around them, and the harness has the natural right to own their interface. The proposed “agent work supervisor” and verified live inbox are rejected. Panout remains focused on what can be learned after a session and reused before a later one.

2026-08-22 — Panout is local-first; Teams is the paid collaboration layer

The core continuity product must be useful offline and without a Panout account. Raw session data remains on the device by default. The paid product earns its place through encrypted cross-device and team sync, shared task context, permissions, integrations, retention controls, and team-level recommendations.

2026-08-22 — Claude Code and Codex are the first supported harnesses

They are the two harnesses used every day by the founder and therefore provide the smallest credible cross-harness test.

2026-08-22 — V0 must prove one magical continuation

The acceptance test is: capture work performed in one harness, open a fresh session in the other, and continue with the correct task state and next action without the human restating the history. Panout does not need to restore processes, credentials, or the execution environment.

2026-08-22 — The durable unit is a task, not a thread or session

A real engineering task can span days, subtasks, people, harnesses, failed resumptions, and several sessions. Panout maintains the goal, decisions, progress, blocker, relevant work, and next action above those individual sessions.

2026-08-22 — Context continuity is the initial wedge

Repeatedly explaining prior work and reconstructing interrupted tasks is the most frequent pain. Duplicate or conflicting parallel work is useful context but not the lead problem.

2026-08-22 — Human corrections are first-class evidence

The final diff does not reveal whether an agent succeeded in one attempt or needed six hours of steering. Panout should preserve the initial request, rejected attempts, human corrections, and accepted result so it can learn the person's or team's quality bar.

2026-08-22 — Completed tasks become reusable experience

When new work resembles a previous task, Panout should retrieve a small, sourced episode containing the relevant decisions, approaches, failures, code, and outcome. Episodes remain distinct from stable memories and deliberately authored skills. Repeated successful episodes may later be proposed as skills.

2026-08-22 — Agent recommendations are a later compounding product

Panout may eventually recommend an agent, harness, model, reasoning level, context, and approach based on comparable prior tasks. It must first collect enough outcome and human intervention evidence. Early versions should show relevant precedents rather than claim causal rankings.

2026-08-22 — Panout complements work trackers instead of cloning them

Linear and Jira hold the planned work; GitHub holds the resulting code. Panout targets the missing execution context between them: how humans and agents reached the result and what the next worker needs to continue.