refactor: run Data as a Zo persona instead of a self-hosted Letta agent - #22
Conversation
Data no longer has a runtime of its own. The Discord bridge talks to Data's Zo persona through POST /zo/ask, the same shape Goop uses, and the whole Letta layer is retired: - channels/discord/index.ts asks Zo instead of forwarding to data-http, and keeps the conversation_id Zo returns so a channel keeps its thread. - data-http, its two support libs, and the MemFS persona seeding move to archives/letta-brain/ with the reason they were retired. - deploy.yml deploys one service instead of two.
|
This pull request refactors Data to run as a Zo persona instead of a self-hosted Letta agent. This change simplifies the architecture by removing the
Reviewers, please start by examining the updated |
|
This pull request refactors Data to run as a Zo persona instead of a self-hosted Letta agent. This change simplifies the architecture by removing the
Reviewers, please start by examining the updated |
The inventory table still named data-http as a running service while the retirement rule said a retired record is kept and marked. The table now lists only data-discord, the retired record is named as archived, and the rule says what actually happens: the record moves to archives/ with the reason and leaves the inventory.
The file still carried the Letta MemFS memory section from the retired self-hosted runtime (PR #22): records under records/<topic>.md, a memory checkout with no remote, the weekly local backup as the durability story. None of that exists now, and the repository's own AGENTS.md already says Data keeps no runtime memory. The read-only bullet also still said "against the codebase" and treated memory as a write surface. Drops the Memory section and aligns that bullet with the persona text.
Data no longer has a runtime of its own. This is the Data half of the simplification: one persona and one bridge, the shape Goop already runs.
What changed
channels/discord/index.tsasks Data's Zo persona throughPOST /zo/askinstead of forwarding todata-http, and remembers theconversation_idZo returns (channels/discord/data/conversations.json, gitignored) so a channel keeps its thread across mentions.ZO_CLIENT_IDENTITY_TOKEN); it still holds no model credential of its own.data-http,lib/zo-secrets.ts,lib/conversation-recovery.ts,lib/sync-persona.ts,scripts/sync-persona.ts, and thedata-httpservice record move toarchives/letta-brain/with the reason. Their tests stop running; the suite is 13 tests, all passing.deploy.ymldeploys one service instead of two, andpackage.jsondrops theserveandsync-personascripts.Why
The Letta layer bought exactly one thing — Data writing its own memory — and cost a second long-running service, a provider/model configuration on the host, a persona-seeding script, two provider keys, and four open PRs (#18, #19, #20 are all specific to that runtime). A question asked in Discord is a question about Wazoo's source, and the persona answers it with
files:readover the same checkouts.Verification
npm run typecheckclean;npm test13/13.POST /zo/askwithpersona_idset, the reply is posted back as a reply, and the second mention on the same channel carries the returnedconversation_id.POST /zo/askwith persona64e4d78b-cf2a-43e9-839f-33b7e48af8e5returned 200 and aconversation_id.Not covered
Data keeps no runtime memory now. Anything worth keeping from an investigation becomes a published artifact here (
knowledge/,public/guides/,public/field-notes/) through a pull request, which is a different thing from the per-turn memory the Letta agent had.