Skip to content

Instantly share code, notes, and snippets.

@zmanian
Created February 13, 2026 15:31
Show Gist options
  • Select an option

  • Save zmanian/5ac0a945a3dfe38fbeb74a5c5c96d56b to your computer and use it in GitHub Desktop.

Select an option

Save zmanian/5ac0a945a3dfe38fbeb74a5c5c96d56b to your computer and use it in GitHub Desktop.

Merging daemon-collector into the LLM Branch

Context

The llm-long-running-tasks branch is our main work spike for LLM agent infrastructure on Endo. It includes a llamadrome package (multi-backend LLM agent with Anthropic/Ollama), conversation persistence across daemon restarts, and a set of new daemon verbs for capability-separated evaluation: define, endow, form, requestEvaluation, and storeValue. The idea is that an LLM guest can propose code with named slots, the host endows those slots with capabilities, and the code runs in a sandbox with host approval.

I've looked at the daemon-reply and daemon-collector branches and want to merge that work into the LLM branch so we're building on the latest daemon internals rather than diverging further.

Plan

Merge daemon-collector into llm-long-running-tasks

Bring in the formula GC (collection, deincarnation, reincarnation), reply support, and all the daemon refactoring as the new foundation.

Keep as-is (no daemon overlap)

  • The entire packages/llamadrome/ package -- agent lifecycle, backends, system prompt, conversation store
  • New CLI commands: define, endow, form, approve-eval, respond-form
  • help-text.js for method-level documentation

Drop (already upstream or in Kris's branches)

  • Durable messages / bigint parsing (already merged via PR #3074)
  • All the WIP commits that originated from Kris's branches

Re-integrate against collector's new daemon structure

After the merge, re-wire the define/endow/form/requestEvaluation/storeValue plumbing in mail.js, guest.js, host.js, daemon.js, types.d.ts, and interfaces.js to fit the refactored daemon internals.

Open question: threads vs replies

I started adding threadId propagation through message formulas and a threads CLI command. The daemon-reply branch adds reply support. Are these the same concept or complementary? Happy to drop the thread work and build on the reply mechanism if that's the right foundation.

Question

Is daemon-collector ready to merge into the LLM branch now, or are there pending changes that should land first?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment