From 61197f3613510f91c2f3df4f0edd1bee118c24a0 Mon Sep 17 00:00:00 2001 From: ajspig Date: Wed, 27 May 2026 12:08:42 -0400 Subject: [PATCH] docs: minor edits --- .../guides/recipes/unified-memory-setup.mdx | 27 +++++++------------ 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/docs/v3/guides/recipes/unified-memory-setup.mdx b/docs/v3/guides/recipes/unified-memory-setup.mdx index 4106dcf3..35a3bfa1 100644 --- a/docs/v3/guides/recipes/unified-memory-setup.mdx +++ b/docs/v3/guides/recipes/unified-memory-setup.mdx @@ -5,7 +5,7 @@ icon: "diagram-project" description: "Wire one shared Honcho workspace across a chat companion, a coding agent, an autonomous agent, and a scheduled ingestion job" --- -This guide wires four integration points into a single coherent Honcho setup: a +This guide wires four integration points into a single Honcho setup: a chat companion (Discord/Slack), a coding agent (Claude Code), an autonomous agent (Hermes), and a cron job that ingests external data. They share one workspace and one user peer, so everything Honcho learns about your user in one place is @@ -13,8 +13,7 @@ available everywhere else. This is a how-to, not an intro. It assumes you know what workspaces, peers, and -sessions are. If you don't, start with [Design Patterns](/v3/documentation/core-concepts/design-patterns) -and come back. +sessions are. If you don't, start with [Core Concepts](/v3/documentation/core-concepts/). ## The shared configuration @@ -22,8 +21,7 @@ and come back. The unification comes from two choices applied everywhere: **one workspace** and **one peer for the human**. How you set them depends on the integration: -- **Code you write yourself** (the companion and the ingestion job below) passes them - directly — `Honcho(workspace_id="my-product")` and `honcho.peer("your-user-id")`. +- **Code you write yourself** passes them directly — `Honcho(workspace_id="my-product")` and `honcho.peer("your-user-id")`. - **The Honcho plugins** for Claude Code (and others!) read from `.honcho/config.json`. Point each host at the same `workspace`, and use the same top-level `peerName` so every host attributes you to one peer: @@ -114,17 +112,14 @@ substantive explanation lands in the session. Because this uses the **same user peer** as the companion, a preference the user states while coding ("keep it simple, pass config directly") is queryable from the Discord bot via `user.chat(...)`, and vice versa — both write to the same peer -representation. (Reasoning is async, so it surfaces once the observation is derived, -not the same turn.) That's the whole point of the shared peer. +representation. --- ## 3. Autonomous agent (Hermes) -Hermes ships its own Honcho plugin, configured through `honcho.json` -(`$HERMES_HOME/honcho.json`, falling back to the global `~/.honcho/config.json`). -To fold it into this shared setup, set its `workspace` and `aiPeer` there — -otherwise it defaults to the `hermes` workspace and a `hermes` agent peer. +The Hermes Honcho plugin is configured through `honcho.json`, set its `workspace` +and `aiPeer` there. See the [Hermes guide](/v3/guides/integrations/hermes) for the full config schema. - **Sessions** follow a `session_strategy` (default `per-directory`, like the coding agent above; `per-repo` or `per-session` for a fresh Honcho session each run). The @@ -134,10 +129,8 @@ otherwise it defaults to the `hermes` workspace and a `hermes` agent peer. representation of itself as well as the user. - Hermes exposes Honcho as agent **tools** (`honcho_reasoning` for synthesized answers, plus lighter `honcho_search` and `honcho_context` lookups) and decides when - to call them mid-task. Unlike the companion and ingestion sections above, you write - no retrieval code — the agent pulls cross-session context on its own. - -See the [Hermes guide](/v3/guides/integrations/hermes) for the full config schema. + to call them mid-task. Unlike other sources, you write no retrieval code — + the agent pulls cross-session context on its own. --- @@ -187,13 +180,11 @@ import examples. From any integration, the same call — `user.chat("What is this user working on, and what do they care about?")` — draws on all four sources at once: Discord chats, coding -decisions, Hermes task runs, and imported emails. They blend because of three choices +decisions, Hermes task runs, and imported emails. They blend because of two choices applied everywhere: - **One workspace and one user peer**, so the representation accumulates in one place instead of fragmenting into `user-discord`, `user-cursor`, etc. -- **Every peer observed by default**, agents included — unless you deliberately set - `observe_me=False` on one you fully control. - **Sessions scoped to the live interaction** (channel, repo, task run, import batch), so local context stays coherent while the user peer carries the long view.