Self-hosted/local Honcho ingests messages but derived memory does not appear automatically; peer card/context/search remain empty

[qaqcvc]

Bug Description

In a local/self-hosted Honcho deployment, messages are successfully written into Honcho and queue items are created, but derived memory does not appear automatically unless the deriver is started manually. Even after manually running the deriver and processing queued work, peer card / profile-style surfaces still remain empty.

This makes the local deployment appear partially functional:

• message/session ingestion works
• queueing works
• manual deriver execution works
• but peer card, peer context, and profile/search surfaces remain empty or incomplete

Environment

• Honcho version: 3.0.5
• Deployment: local/self-hosted
• API server running locally on http://localhost:8000
• Hermes configured to use Honcho as memory provider
• Hermes Honcho host config:
  • memoryMode: hybrid
  • recallMode: hybrid
  • writeFrequency: async
  • saveMessages: true
• Deriver config observed from local runtime:
  • DERIVER_ENABLED = True
  • DERIVER_PROVIDER = custom
  • DERIVER_MODEL = gpt-5-mini
  • OPENAI_COMPATIBLE_API_KEY = set

What we observed

1. Messages are being logged into Honcho

• workspace, peers, and sessions are created successfully
• local API endpoints are reachable
• messages/session structures exist in the backend

2. Queue items are created, but were not being processed automatically
   Before manually starting the deriver, queue status showed:

• completed_work_units = 0
• pending_work_units = 33

3. No separate deriver worker process was running
   The API server was running, but there was no separate python -m src.deriver process alive.

4. Manually starting the deriver processed work successfully
   Running the deriver manually (python -m src.deriver) processed queue items and increased completed work units, e.g. later queue status showed:

• completed_work_units = 23
• pending_work_units = 15

This suggests model/API configuration is functional enough for derivation, and that the major operational issue is that the deriver was not running automatically in our local deployment.

5. Even after manual derivation, peer-card/profile surfaces remained empty
   Direct API checks still returned empty results:

• GET /v3/workspaces/myHoncho/peers/hermes/card?target=ctx

  • returned {"peer_card": null}

• GET /v3/workspaces/myHoncho/peers/hermes/context?target=ctx

  • returned something like:
  • {"peer_id":"hermes","target_id":"ctx","representation":"","peer_card":null}

• POST /v3/workspaces/myHoncho/peers/hermes/search

  • returned []

In Hermes-side tools this corresponds to behavior like:

• profile/peer-card-like surface says no facts yet
• search can return nothing
• while higher-level synthesized context may still sometimes produce partial facts

Steps to Reproduce

1. Run Honcho locally/self-hosted with API server available on localhost
2. Configure Hermes (or another client) to write messages into Honcho with async write behavior
3. Send messages and verify sessions/messages are being created
4. Check queue status
5. Observe that queue items accumulate but nothing completes unless python -m src.deriver is started separately
6. After manually running the deriver, re-check:
   • peer card endpoint
   • peer context endpoint
   • peer search endpoint
7. Observe that these surfaces may still remain empty/null even after derivation work has completed

Expected Behavior

• In a correctly configured local deployment, async ingestion should lead to derivation without confusion about missing background processes
• If a separate deriver process is required, the docs/runtime behavior should make this very obvious
• After derivation runs, peer-card/profile/context/search surfaces should reflect the derived memory, or documentation should clarify which of these are/aren't expected to populate automatically in OSS/self-hosted mode

Actual Behavior

• Messages are ingested and queued
• Derivation does not happen unless a separate deriver process is started manually
• After manual derivation, peer card / context / search can still remain empty/null

Questions

1. Is this expected for self-hosted Honcho, i.e. the deriver must always be launched as a separate persistent process?
2. Is there any supported single-process local mode where the API server also runs the deriver automatically?
3. Are peer cards supposed to be auto-generated in OSS/self-hosted mode from ingested observations, or are they only populated by a separate path/tool/agentic flow?
4. If peer cards are expected to auto-populate, is there a missing worker or feature in self-hosted mode?

Notes

We are not reporting this as a confirmed bug in intent; it may just be an operational/documentation gap. But from the outside, the local deployment feels like it is only partially working:

• ingestion works
• queueing works
• manual deriver works
• peer-card/profile/search UX still appears incomplete