Modes of Operation

Enumeration of the deployments, UXes, and application shapes Honcho should serve, and the capabilities each implies.

Companion doc: Failure Modes — running catalog of observed and suspected failures, organized against the capability taxonomy below.

Two axes:

• What people build with Honcho (application / UX)
• Structural interaction shapes (orthogonal, same shape across apps)

Capabilities list:

• What Honcho actually does under all of that

Layers (orthogonal to all of the above):

• L1 — Honcho-as-component: capabilities Honcho’s substrate (deriver / dreamer / dialectic / summarizer + storage) provides natively.
• L2 — Honcho-in-context: capabilities the wrapping agent (Claude Code, Hermes, SillyTavern, custom MCP) implements on top of what L1 returns.

Many capabilities below could be implemented at either layer; several open questions at the bottom of this doc are really “which layer should own this?” decisions. See Failure Modes for how the same cut applies to known and suspected failures.

---

Applied AI/Use Cases/Tools

• Chatbots
  • Generic conversational (ChatGPT-shape)
  • Companion / persistent personality (Replika-shape)
  • Roleplay & character agents (SillyTavern, character.ai — agent itself has an identity that grows)
  • Tutoring / education (adapts to learner across sessions)
  • Coach / therapy / wellness (sensitive, episodic, drift-aware)
• Coding agents
  • In-IDE pair (Claude Code, Cursor, Codex)
  • Long-running autonomous dev agent
  • Cross-repo / cross-project memory
• Customer-facing / FDE
  • One agent, many users (support shape — isolate per user, personalize)
  • Customer-deployed (agent learns the customer’s domain quirks)
• Multi-agent systems
  • Specialist agents reading from one shared user model
  • Agent debate / dialectic where peers reason about each other
  • Swarms — cooperative or adversarial roles
• Group / multi-human
  • Team workspaces (humans + agents share state)
  • Async handoff (person-to-person via the agent’s continuity)
  • Multi-peer sessions where observations get attributed correctly
• Async / message-driven
  • Email triage, calendar, scheduling
  • Sales outbound (model each prospect separately)
  • HR onboarding, intake, periodic check-ins
• Research / knowledge work
  • Long-horizon project assistant (accumulates findings)
  • Ingest-now-query-later (no live conversation, just substrate)
• Voice / ambient
  • Smart speakers, always-on home assistants (low-latency)
• Games / interactive media
  • Persistent NPCs across saves
  • Narrative agents that remember player history
• OS-level / personal infrastructure
  • Cross-app personal agent (Apple Intelligence shape, but external & user-owned)
  • Identity layer that survives vendor swaps

---

Structural shapes (orthogonal to application)

• 1 user + 1 agent
• 1 user + N agents (specialist routing, dialectic, panels)
• N users + 1 agent (support, classroom, group chat)
• N users + N agents (collaborative workspace)
• Single-shot / async (no back-and-forth — agent operates on data and reports)
• Cross-session (resume after gaps, sometimes long ones)
• Cross-tool / cross-vendor (same peer, different surfaces — Claude Code → Hermes → custom MCP)
• Background ingestion only (no immediate query — eval is correctness of resulting state)

---

What Honcho needs to do

Primitives today: workspaces · peers · sessions · messages · conclusions (typed by pattern_type — preference / behavior / personality / tendency / correlation — with high / medium / low confidence) · peer cards · session summaries (short + long) · representations. Agents today: deriver (forms conclusions from messages) · summarizer · dialectic (answers peer.chat()) · dreamer (consolidates / deletes / updates).

”Right now”: Situational awareness in a session

• Know what the session is about
• Know who’s in it and what role each peer plays
• Know what’s been said recently (last N turns)
• Know what’s actively being worked on (open task, current thread)

Today: session.context(summary=True) returns short-summary + peer card + recent messages on every turn — the canonical ambient-injection surface a wrapping agent pours into the prompt.

Across sessions

• Orient quickly when a new session opens (representation / peer card)
• Know when things happened — timestamps, relative recency
• Distinguish active from archived — old projects shouldn’t crowd out current ones
• Resume gracefully after long gaps without making the user re-explain

Today: peer cards and conclusions persist across sessions. Long summaries fire every 60 messages by default (configurable via messages_per_long_summary). Gap: no first-class “active vs. archived” distinction; older conclusions stay until the dreamer prunes them.

Concept models — entities and projects

• Track recurring work threads, projects, deliverables
• Identify named entities consistently (people, repos, products, files)
• Model relationships between entities (X reports to Y, repo A depends on B, project P spawned project Q)
• Disambiguate (two Vinnys, two projects with similar names, the user’s “current project” vs. an old one)

Today: any entity (third-party humans, products, projects) can be a peer with its own card + conclusions; conclusions about entities live as free-text content. Gap: no first-class entity-relationship layer — relationships, when captured, sit inside conclusions as prose rather than as structured edges.

Peers

• Peer preferences (style, tooling, conventions)
• Peer identity, role, expertise, goals
• Peer patterns — how they work, what they avoid, when they’re sharp vs. tired
• Peer conclusions
• Other people a peer has mentioned — model them too
• The agent itself — its own identity, track record with this user, drift in its own behavior

Today: peer card + conclusions + representation cover this. The deriver tags inductive conclusions with pattern_type (preference / behavior / personality / tendency / correlation) and confidence, so “preferences” already exist as a typed slice of the conclusion store. observe_me controls whether Honcho forms a representation of a peer; observe_others controls whether a peer’s representation models the others in a session. Agents are peers — their cards and conclusions are first-class.

Negation

• Things the user said NOT to do
• Past failures and corrections (don’t repeat “mock-the-DB” mistake)
• Surface contradictions when current move conflicts with stored memory — even if not asked
• Constraints inherited from prior incidents

Today: no first-class negative-conclusion or constraint type. “Don’t do X” lives as an ordinary conclusion and surfaces only when the dialectic decides to retrieve it. Gap: no proactive contradiction-surfacing when the current move conflicts with stored conclusions — this is the structural blind spot of agent-decided trigger.

Time

• Drift detection — preferences changed, surface that
• Conflict resolution — latest fact wins, but flag the conflict
• Decay — old facts have lower confidence over time
• Distinguish episodic (“we did X on date Y”) / semantic (“X is true”) / procedural (“how to do X”)

Today: conclusions are timestamped (created_at); confidence is captured at creation but doesn’t decay. The dreamer consolidates and deletes redundancies during scheduled or explicit dreams. Gaps: no first-class staleness/decay, no formal drift detection across time, no episodic/semantic/procedural typing.

Proactive surfacing

• Speak up about relevant memory without being asked
• Flag parked-but-still-open items (“you said this essay was active 11 days ago, still?“)
• Surface patterns the user hasn’t noticed themselves

Today: not built. Honcho is reactive — peer.chat() answers when asked. Proactive surfacing is the wrapping agent’s job, which is why the trigger-policy question is load-bearing for the eval.

Privacy & boundaries

• Workspace isolation (no cross-tenant leakage)
• Peer-level observation policies (configurable: who observes whom)
• Sensitive info handling (medical, financial, legal — different decay, different access)
• User-requested forgetting (delete this fact, this thread, this time period)
• Source attribution (which message did this observation come from)

Today: workspaces enforce multi-tenant isolation; observe_me / observe_others give per-peer observation control; conclusions are deletable (honcho conclusion delete or via API). Gaps: no specialized handling for sensitive categories; source-attribution is implicit (conclusions trace to the messages they came from) but not always exposed in UX.

Infrastructure-level

• Bootstrap from external history (import chats, documents, transcripts)
• Export / portability (move memory between Honcho deployments or out)
• Versioning — history of how facts changed
• Survive model swaps without losing state
• Inspectable — a human can read exactly what’s stored
• Adversarial robustness — poisoning, prompt injection in messages, malicious peers

Today: batch message creation (up to 100 per call) supports bootstrap from imports; everything is inspectable via the honcho CLI / API. Gaps: no formal export/snapshot, no versioning of how a conclusion changed, no specific defenses against poisoning or prompt-injection-into-conclusions.

Cross-context

• Same peer accessible from many tools (Claude Code, Hermes, custom MCP servers)
• Memory consistent across surfaces — what’s said in one tool surfaces in another
• Group memory when multiple humans share a session
• Agent-to-agent handoff preserving context

Today: a peer ID is the same identity wherever it’s used — Claude Code, Hermes, and MCP servers can share a peer if you wire them with the same workspace + peer ID. Multi-peer sessions natively support group state. Gap: no formal cross-vendor / cross-deployment portability protocol.

---

Open questions

• Proactive surfacing — where does it live? (L1↔L2 boundary) Today this is entirely the wrapping agent’s job. Should Honcho start emitting events (drift detected, contradiction with stored conclusion, parked-thread reminder due) that wrappers can subscribe to, or stay strictly reactive and leave all trigger logic outside?

• Negation as a first-class type. (L1↔L2 boundary — first-class type pushes contradiction-surfacing into L1; status quo leaves it as agent-decided L2.) Should pattern_type extend to include constraint / prohibition / negation, or should “don’t do X” stay an ordinary conclusion the dialectic finds via search? Affects the defensive-memory eval shape directly.

• Scope and lifecycle on conclusions. A conclusion today is “true about this peer, until the dreamer touches it.” There’s no notion of scope (this-message / this-task / this-project / this-peer-global) or lifecycle state (active / resolved / archived). Two observable failure shapes drop out of this gap directly: task-scoped preferences get promoted to peer-global, and resolved tasks keep surfacing as if active. Should pattern_type or a parallel field carry scope, and should conclusions tied to discrete work get lifecycle states?

• Concept-model layer for entities and relationships. (L1↔L2 boundary — structured edges live in L1 storage; free-text relies on L1 retrieval + L2 prompt assembly to reconstruct.) Today entities are peers and relationships live as prose inside conclusions. Build a structured entity-relationship layer (X-reports-to-Y as an edge, not a string), or commit to free-text and trust the dialectic to reconstruct relationships at query time?

• Cross-tool peer identity. (L1↔L2 boundary — enforce/auto-resolve = L1 owns identity; strictly explicit = L2 application owns it.) Today: same peer ID across tools = same peer, if you wire it that way. Should Honcho take a position — enforce identity, auto-resolve identity, or leave it strictly explicit?

• Confidence decay. Conclusions get a confidence (high/medium/low) at creation and it doesn’t move. Should it decay with age, strengthen with corroboration, drop when contradicted?

• Cross-vendor portability. Federated protocol, export-only snapshots, or both? What’s the minimum viable “I’m leaving this Honcho deployment” story?

• Voice / sub-second latency. Is Honcho explicitly serving this, or is the ambient-injection model too heavy? If pursued, what compromises (skip the dialectic loop, peer-card-only context, cached representations) are on the table?