Product Blueprint / August 2026
Wooolfmesh does not need another large architecture pivot. The repository already contains the main capabilities for the Studios model. The next job is product compression: keep the data and services, remove competing surfaces, and make one calm Studio shell the normal way to work.
The current code already has Projects, Work Threads, tasks, memory scoped by project, focus sessions, links, conversations, routines, Obsidian context, context packs, decision context, intervention suggestions, local learning feedback, Hermes, DIAL, and deterministic fallback behavior.
At the same time, the frontend still exposes many route families and two very large work surfaces: the main Workspace page and the Project workbench. Both try to organize the same underlying work from different angles.
Studio should first be a product view over the existing Project scope. Keep the internal Project model and Markdown formats for compatibility. Use “Studio” as the user-facing concept. A Work Thread is the current active thread inside that Studio.
This gives the product a major UX change without introducing a new Markdown entity family, migration, sync rule, or parallel canonical model.
Target product
The product can become much smaller without deleting the underlying capabilities.
The normal place to work. Open a Studio, see the goal, resume point, current thread, artifact, and next action. Tasks, sources, memory, Focus, AI and runs appear only when relevant.
Internal mapping: existing Project scope + Work Thread. Keep current IDs and Markdown compatibility.
A global place to search, inspect, correct, pin, archive and understand durable memory. Normal memory reuse still happens quietly inside Studios.
Rule: Memory is a library and trust surface, not a feed the user must process every day.
Vaults, Hermes or DIAL, permissions, diagnostics, backup, integrations and advanced system controls. These belong outside the daily work loop.
Rule: system complexity may exist, but it should not leak into the normal Studio experience.
Studio shell
One stable shell can support research, planning, coding, writing, analysis and personal execution without changing the product grammar.
A short statement of what this Studio is trying to achieve. Microsoft Research argues that goals should become first-class abstractions in human-AI collaboration because planning, orchestration and evaluation all depend on them.
Microsoft Research, 2026Last meaningful outcome, exact next action, blocker and active source. This should be more prominent than analytics, history or project health.
The thing being worked on: a task, plan, note, report, checklist, analysis or linked external artifact. The artifact wins the visual hierarchy.
The current Work Thread provides the next action and execution state. Other project tasks live behind a compact task drawer instead of becoming a permanent queue.
Sources, one to three admitted memories, decisions and relevant Obsidian notes. Show why each item is present. Do not dump raw retrieval results into the work surface.
Optional and collapsible. It works with the current Studio context and can Think, Collaborate or Run. Provider choice stays in Settings and does not change the Studio model.
Focus is not a page or mode inside the Studio. It is a temporary state of the current thread: protect work, park interruptions, then leave a resume anchor.
Finish with outcome, next action and optionally one reusable lesson. Reviews become a closeout behavior first and a specialist record second.
Routines and agent work appear as small Studio-local runs: last result, next run, exception and history. A global automation view remains a troubleshooting tool.
Reuse before rewrite
The important change is where a capability appears, not whether its backend still exists.
Use Project as the durable scope. Replace the separate project workbench experience with the Studio shell over time. Keep `/projects/*` as compatibility or specialist routes during migration.
The current Workspace already derives a Work Thread without a new canonical entity. Keep that principle, but remove mode bars, relationship graph, permanent queue and competing workbench layers.
Keep the task model and detailed editor. Inside a Studio, expose only current thread, next action, blockers and a compact list when needed.
Keep existing focus services and fallback route. Primary controls stay inline with current work.
Use the existing review records and generation logic, but make the normal entry point the end of work or a deliberate weekly reflection.
Keep both internal formats while daily UX says Memory. Lessons, facts, preferences and procedures return through the same contextual retrieval surface.
Conversation history and reusable instructions should support a Studio. They do not need equal navigation status. Full libraries remain secondary.
Unify active links, local notes and external references into one contextual source shelf. Preserve original provenance and open the source when trust matters.
Keep scheduling, proposals and execution services. Normal users see runs in the Studio they serve, not a separate automation universe.
These may inform ranking or intervention underneath the UI. Do not expose a permanent panel unless dogfooding proves a repeated decision that needs it.
Do not make provenance a daily destination. Surface compact lineage where a result, memory or action needs verification.
Preserve for bulk work, but keep it outside the default Studio grammar until repeated real use proves otherwise.
Rather than adding another “Studio service”, compose a small Studio read model from existing services. The current Work overview already proves the pattern: it derives a provider-independent Work Thread from existing task and focus data without creating a parallel canonical entity.
Project context packs, decision context, Obsidian retrieval and work feedback can become inputs to one context compiler. The frontend should not independently query every capability and assemble a mini operating system inside one React page.
Context Compiler: creates the smallest useful Studio context packet.
Memory Governor: admits, ranks, verifies, supersedes and forgets memory.
Attention Governor: decides whether a suggestion deserves visible attention now.
Action Governor: decides whether work can continue, needs preview, or needs a checkpoint.
Recovery Ledger: keeps enough provenance, snapshots and outcomes to explain, undo, retry and resume.
Implementation
The order matters. First remove product ambiguity, then make the intelligence deeper.
Document Studio = Project scope + current Work Thread + contextual layers. Keep Project IDs, Markdown and APIs. Add no new entity family.
Start with goal, resume anchor, current artifact/thread, next action and one contextual drawer. Reuse current services. No graph, mode bar or permanent queue.
Move context pack, Obsidian context, decision context, project intervention and work trail into the Studio shell as optional layers. Stop developing a second full work surface.
Task capture, clarification, Focus, interruption parking, closeout and next-action handoff become one continuous thread flow.
Return one Studio context response: goal, state, resume anchor, sources, admitted memory, active runs and explanation of why each contextual item matters.
Hermes or DIAL use the same context packet. AI disabled remains a valid state. Start with Think and Collaborate; add Run only for bounded actions with existing preview and recovery rules.
Remove old areas from normal navigation one by one after their useful entry points exist in Studios. Keep redirects and specialist routes during the compatibility window.
Measure whether a person can open a Studio after 24 hours, understand state in seconds, continue without searching old pages, and close work with a useful resume trail.
What to remove from the main experience
The following concepts can still exist internally or in specialist routes. They should not define the daily product.
Flow, Routines, Batches, Focus and Review should not be five different ways to reinterpret the same page. They become contextual states or tools.
A graph can remain a Lab or diagnostic view. It should not sit between the user and the next action.
Show current work first. Other tasks appear when the user switches thread or opens the task drawer.
Learning from corrections is useful, but it should happen through lightweight feedback and later reviewable proposals, not a permanent “improve future recommendations” section.
Project health, context, intervention and work trail become Studio context. One project should not require both Project Workbench and Workspace to understand it.
Hermes and DIAL are infrastructure choices. AI appears beside the work when useful, while deterministic retrieval and manual execution remain first-class.
Recent human-AI research is increasingly interested in explicit goals, persistent common ground, bounded context, reusable structured memory and collaboration that remains steerable over time. These ideas fit the repository better than another set of independent AI widgets.
Microsoft Research argues for goals as first-class abstractions in human-AI collaboration. PlugMem explores turning raw interaction history into structured reusable knowledge instead of repeatedly retrieving long raw histories. Agent-Memory Protocol proposes purpose-built context packing at the privacy boundary.
Studio as the user-facing name for Project; goal visibility; one-context-response orchestration; task drawer instead of queue; contextual memory limit; AI sidecar; runs inside Studio; and 24-hour restart performance.
If these do not reduce navigation and restart friction in real use, we should remove or revise them rather than protect the concept because it sounds elegant.