One project across four specialised workspaces
The fragmentation problem
Modern product work already crosses tools. A design begins in a canvas, requirements become a document, repeated operations move into automation and implementation lands in a repository. AI products often add another boundary: each tool receives a separate conversation and asks the user to reconstruct the project’s context.
The result is locally impressive and globally incoherent. The interface does not know why the runbook changed. The automation cannot see the goal that justified it. The code agent receives a fresh summary written by a human who has become an unpaid integration layer.
The project is the durable object
Miton treats the active project as a cohesive block. Goals, actionable work, documents, workflow runs and project knowledge belong to it. Chat and Plan remain the same as specialised workspaces open, so a workspace change does not imply a new conversational identity.
The workspaces are deliberately different:
- Canvas projects the selected worktree’s front end, App Kit alignment and code-owned boundary.
- Writer organises long-form structure, citations, revision and export.
- Automation organises triggers, nodes, connections, runs and recovery.
- Code organises files, language tooling, terminal work, diffs and verification.
Making those experiences identical would discard the reason they exist. Cohesion comes from shared project primitives, not from forcing every task into a universal chat transcript.
Split and merge
The interaction principle is simple: Chat is constant; surfaces split in and merge out as the work requires. A request may begin without the user choosing a workspace. Intent routing can open the appropriate surface, while a visible workspace switcher lets the user correct the choice.
There is no return or transfer step. Chat is the same conversation wherever it appears, while project activity records the document saved, goal advanced, workflow run or code change available for review.
Current evidence and the remaining gate
The development build supports one active conversation, shared Plan and Goals, revisioned project artefacts and worktree-aware Canvas/Code comparison. The Atlas Migration visual sequence is derived from those production contracts and labels renders separately from literal captures.
The complete promise goes further. A maintained documentation suite, an end-to-end front-end and back-end loop and a packaged release artefact remain part of the v1 programme. Cohesion is already the architecture; complete delivery is the gate it must still earn.