A workspace built as one graph.
These notes accompany the Scint case study. Under the app is a runtime that gives every space, document, command and transcript an identity, and expresses every relation between them the same way. The app is a set of views over those objects and keeps no second copy of any of them. Four ideas carry most of it.
Nothing is copied.
Every object in Scint has one reference, and everything that uses the object holds that reference. A space points to its documents with one. A document points to a document inside it with one. A transcript points to the nested transcript behind a reply with one.
Nobody holds a copy, so nobody holds a stale one. When an agent edits a document someone has open there is nothing to sync, because there is only one document. This is also why a request can list documents instead of including them: the agent reads the one document, as it is, when it needs it.
Edit the first line of the document
Inside another document
Release brief: explain what changed for users.
Research notes
In an agent's request
Listed by name, link and description. When the agent reads it through MCP, it gets:
scint://document/8f2c61d0…
In a scheduled task
Summarize last week's notes, Mondays at 9:00. When it next dispatches, the agent reads:
scint://document/8f2c61d0…
On disk
library/documents/8f2c61d0….json
{ "descriptor": { "name": "Research notes", … },
"value": { "blocks": [ …, "" ] } }
A reference carries five identifiers (object, type, descriptor, context and storage), so a bare reference already knows its type, its store, its name and its file. It leaves Scint as a link and comes back as the same object, whether it travelled through a document, a command's arguments or another application. Remove an object and its descriptor stays behind, so a link held elsewhere still says what it pointed to.
Where things belong, and how they relate.
A project needs a hierarchy and a web of connections, and forcing one into the other bends both. Scint keeps them as two structures over the same spaces. Containment says where a space belongs. Bridges say which spaces work together, and they cross the hierarchy freely.
A bridge is more than a line. It has a closure of its own, with documents and commands, so the relationship between two spaces carries what their collaboration runs on. Compose is the intent that sees this structure: its view lists the space, its child spaces and its attached bridges.
Content that runs.
Documents are built from blocks: headings, paragraphs, code, tasks, and references to files, commands and other documents. A block that refers to another document makes documents recursive. A brief can hold the research it depends on, and a second brief can hold the same research.
A request in Scint is a document too. Its header holds execution settings, keyed by the interface or command they configure, so instructions travel with everything needed to carry them out. One model serves as a page you read, a message you send and a task that dispatches on a schedule.
One path into a space.
Every interaction that starts work does the same thing: it adds a document to a space's input and composes the space. A typed message, a task that comes due, an MCP compose call, one space briefing another and a scint:// callback URL all take this path, so every run is queued, recorded and ended by the same rules.
scintd runs the command line with the user's login-shell environment and SCINT_CONTEXT set to the space's context id, which the agent presents to the MCP server.
RecordThe Parser turns the provider's stream into Scint records (output, reasoning, tool calls, errors) in the nested transcript. The exit code becomes a complete or fail signal in the space's transcript.
The same path also starts long-running services. A published policy document, given to a space, has scintd register and start a long-running service, alongside the agent runs.
The runtime, the MCP server, the process daemon, the app and its design system are designed and built by one person, Tim Kaechle.