Home

Theseus

An AI collaboration system I built for myself. It keeps records from multiple agents, long-term conclusions, capability entries, and service control in one place. The restructure is done, and I'm still building on it.

TYPE
An AI collaboration system for one person
STATUS
Restructure done, basic acceptance passed
WHEN
Since March 2026
BUILT WITH
Python, TypeScript, Go, Bash, and web code
WHO
Just me

What this is

It's an AI collaboration system I made for my own use. Raw records left by multiple agents, conclusions I want to keep, skill entries, and services like speech-to-text and OCR all sit under one set of conventions that keep everything traceable to its source. Drafts, code, and outputs stay in their own original files; only knowledge that might be useful across projects gets distilled into long-term notes.

Saving a record and getting a conclusion back are done with remember and recall. After I switch sessions, recall gives me summaries of the hits by default, and I fetch the full text when I need it. Services have one shared control entry where I can check, start, stop, and toggle them, so I don't have to change a component's code just to turn it off.

Conclusions keep their sources

Memory has a raw layer and a long-term layer, called L1 and L2. In the raw layer, events are append-only, conversation mirrors update as new material comes in, and attachments are stored separately. The long-term layer holds the user model, the system model, topic knowledge, and cross-project experience. When something happens, the raw evidence is kept first; an agent then distills it into knowledge and writes it to the long-term layer through the command line. It does not periodically reorganize all the records on its own.

When writing a long-term note, the body has to cite the raw events, and the command has to declare those citations. If citations are missing, or a declared citation never shows up in the body, the write is rejected. remember with the long-term option saves both the event and the cited note at once. The contract only checks that citations exist; whether the cited events are real and whether the conclusions are actually supported by them is not automatically checked.

Long-term notes must cite their source eventsSOURCE EVENTSEXTRACT AND WRITEMANAGED LONG-TERM NOTESL1 · Raw eventEvent citationEvents are append-onlyAppend a new eventAgentExtract reusable knowledgeMemory CLICheck note citationsWith citationSource cited in noteAlso declared in --refsL2WrittenL2 → L1: citationNo citationRejectedExit code 2remember --durable creates an event and a cited long-term note.L1 also holds conversations and assets; the append-only rule applies to events.

FIG. 1 · Long-term conclusions link back to raw evidence

A schematic, drawn from the write contract of the memory commands. Long-term notes missing citations get rejected.

One copy of each skill

The capability library is called Armory, with entries organized into 8 areas. Each capability has exactly one copy of its content. The hosts where agents run reference that copy through symlinks, and the symlink is the entry pointing to it. Capabilities owned by other repos only get their locations registered. Usage docs for services are generated by the command line and then synced out as skills.

Registering and enabling are two different things. Whether a capability is actually enabled depends on the symlinks on disk, and the manager re-reads them every time. Removing a link does not delete the content, archiving keeps it, and only an explicit delete removes the content, leaving a deletion record. Right now 369 entries are registered, 226 of them marked active. How many are actually enabled, I have not counted.

Two host entries reference the same skill sourceREGISTRY AND MANAGEMENTONE SKILL SOURCERegistryState and source locationManagerLocate source, manage linksSkill textKept when links are removedCreate / remove symbolic linksHost entry ASymbolic linkHost entry BSymbolic linkReferenceRegistration does not mean enabled; host links determine actual enablement.Removing a host link preserves the skill text.Service CLI instructions generate a Skill; the manager updates it and its host links.

FIG. 2 · Two hosts reference the same copy

A schematic, drawn from the library's link management rules. The registry helps locate the content; actual enabling is decided by the symlinks, and removing a link keeps the content.

Registry states of 369 skill entriesRegistry states · 369 entries in totalAll registry states; these are not enabled countsEntries050100150200250Active226Plugin removed71Model covers it56Reference only6User deleted5Moved elsewhere3Archived2All 7 states total 369 entries; this does not establish the number actually enabled.Actual enablement is determined by host symbolic links.

FIG. 3 · Where the 369 registered entries stand

Numbers are group counts from the capability registry on October 10, 2026, with all 7 states shown. It counts registry states, not call counts, and not how many are actually enabled.

Where it stands