Source-reviewed product comparison
Trajectory vs. Honcho — Two layers of agent memory
They are adjacent, not interchangeable. One standardizes session records. The other operates durable, derived memory across sessions and participants.
How do we represent many harnesses’ session history consistently?
What durable context should an agent have about a changing user, agent, project, or group?
A possible system boundary
Representation first, policy in the middle, memory after-
Native histories
Agent sessions
Claude Code, Codex, Hermes, Letta Code, OpenClaw, OpenHands, Pi, and Deep Agents.
-
Trajectory
Normalize
Adapt transcripts into a validated record with messages, tool activity, time, reasoning when available, and diagnostics.
-
Your policy boundary
Select and govern
Apply purpose, consent, redaction, retention, identity mapping, and deletion rules before durable ingestion.
-
Honcho
Persist and derive
Store workspace, peer, session, and message data; process it asynchronously into memory artifacts.
-
Agent runtime
Inject context
Retrieve context, search results, representations, peer cards, summaries, conclusions, or chat output.
The layer distinction
Transcript infrastructure is not memory policy.
Trajectory makes records legible across agent harnesses. Honcho retains interaction history and derives cross-session context. Neither choice removes the need to decide what should be remembered.
Letta Trajectory
Apache-2.0 TypeScript and Python tooling for turning native coding-agent transcripts into an agent-readable, validated record shape.
- Schema: metadata, messages, optional reasoning, tool calls and results, timestamps, and diagnostics.
- Adapters: Claude Code, Codex, Hermes, Letta Code, OpenClaw, OpenHands, Pi, and Deep Agents.
- Session access: it can enumerate local sessions, while normalization itself is generally driven by transcripts supplied by the caller.
- Efficiency: optional bounds and filtering favor agent-readable token efficiency over perfect source fidelity.
It does not persist a user model, derive conclusions, or choose which memory policy is appropriate. The reported 5.4-5.6× sample reductions are vendor-reported examples, not a general performance result.
Honcho
AGPL-3.0 stateful-memory infrastructure delivered as a FastAPI service, with managed and self-hosted operating models.
- Data model: workspace → peers → sessions → messages.
- Processing: asynchronous Deriver, Summarizer, and Dreamer work creates conclusions, representations, peer cards, and session summaries.
- Retrieval: context, search, representation, and chat results can be injected into agent runtimes.
- Scope: peer-centric, multi-participant, and cross-session rather than bound to one transcript.
It requires durable storage, a running service, background workers, and an explicit memory and privacy policy. Derived representations are useful context, but they are also interpretive artifacts that need lifecycle controls.
Comparison matrix
The overlap is “agent history.” The useful distinction appears when purpose, identity, lifecycle, and operations are compared.
| Axis | Trajectory | Honcho |
|---|---|---|
| Purpose | Normalize heterogeneous coding-agent transcripts into one validated, agent-readable record schema. | Maintain stateful memory and produce durable context about peers, sessions, projects, and groups. |
| Input | Native harness transcripts, generally supplied by the caller; local session enumeration is also supported. | Messages and events associated with workspaces, peers, and sessions, submitted to a persistent service. |
| Output | Validated records containing metadata, messages, optional reasoning, tool calls and results, timestamps, and diagnostics. | Context, search results, representations, peer cards, conclusions, session summaries, and chat results. |
| Process | Adapt, normalize, validate, and optionally bound or filter transcript content. | Persist first, then asynchronously derive, summarize, and synthesize memory artifacts. |
| Identity and scope | Session-record oriented. It does not maintain a durable user or peer model. | Peer-centric, multi-participant, cross-session, and scoped through the workspace → peer → session → message hierarchy. |
| Lossiness and fidelity | Deliberately trades some native-format fidelity for consistent, token-efficient agent readability. Bounds and filters can reduce what is retained. | Persists submitted messages and events, then creates lossy, interpretive derivatives such as conclusions and summaries. |
| Operational footprint | TypeScript and Python tooling called as part of an application or data flow; no durable memory service is implied. | FastAPI service plus durable storage and background workers, operated through managed hosting or self-hosting. |
| Privacy boundary | The caller controls transcript access, selection, filtering, and downstream use. Normalization does not decide consent or retention. | The service becomes a durable memory boundary. Operators must define participant consent, access, isolation, derivation, retention, and deletion policy. |
| License | Apache-2.0. | AGPL-3.0. |
Source state reviewed 24 July 2026. Product behavior, adapters, deployment options, and APIs can change; verify implementation decisions against the linked repository and documentation versions.
When to choose each
Choose the layer your system is missing.
Use both only when you need both a common transcript boundary and durable derived memory.
Choose Trajectory when…
- You ingest several harness formats.Downstream evaluators, reviewers, or agents need one dependable record shape.
- You need portable session evidence.Tool calls, results, reasoning when available, timestamps, and diagnostics should travel together.
- Context budget matters.You accept bounded or filtered records in exchange for more agent-readable token use.
- You already own persistence and policy.Your application decides storage, identity, retention, and what happens after normalization.
Choose Honcho when…
- Memory must cross sessions.An agent needs durable context rather than a single normalized historical record.
- Relationships and participants matter.The system must model peers, agents, users, projects, or groups within workspaces.
- Derived context is the product need.Conclusions, representations, summaries, search, and peer cards should be retrievable.
- You can operate a stateful service.Durable storage, workers, observability, privacy controls, and deletion workflows are in scope.
How they fit together
Composition needs a policy seam.
Trajectory can provide a consistent transcript boundary before memory ingestion. Honcho can then retain approved messages and derive useful cross-session context. The important architectural element is not the handoff alone. It is the control plane between them.
Architecture status: this is a suggested integration pattern inferred from the products’ complementary roles. It is not evidence of an official, supported, turnkey Trajectory-to-Honcho connector.
- Collect native session historyRead or receive transcripts from supported coding-agent harnesses.
- Normalize with TrajectoryProduce a validated, bounded record that downstream controls can inspect consistently.
- Apply user-controlled policySelect fields and messages, redact sensitive data, map identities, set purpose, and assign retention.
- Ingest approved material into HonchoWrite retained messages and events into the intended workspace, peer, and session boundaries.
- Derive and retrieve contextAllow background processing, then request only the summaries, conclusions, representations, search, or chat context needed by the agent.
Governance before ingestion
A clean schema does not grant permission to remember.
Make these decisions before normalized transcripts cross into durable memory or produce derived representations.
Purpose limitation
State why each class of transcript data is being retained and which agent behavior it may influence.
Participant identity and consent
Define how humans, agents, tools, projects, and groups map to peers, including notice and consent for multi-participant sessions.
Selection and redaction
Exclude secrets, credentials, irrelevant tool output, sensitive reasoning, and data outside the approved memory purpose.
Retention and deletion
Set expiry by data class and ensure deletion covers source messages plus downstream summaries, conclusions, and representations.
Access and isolation
Enforce workspace, peer, tenant, project, and environment boundaries for ingestion, derivation, search, and context retrieval.
Correction and provenance
Keep enough lineage to explain which messages produced a conclusion, correct false inferences, and rebuild derived memory.
Trajectory offers useful normalization, bounds, and filtering controls, but it does not choose this policy. Honcho provides the durable memory machinery, but operating that machinery responsibly remains an application and governance decision.
Sources
Primary product material
Repository and documentation claims were reviewed as published on 24 July 2026.
- Letta Trajectory Repository, schema and adapter implementation, language and license state, transcript normalization behavior, and vendor examples. Open repository
- Plastic Labs Honcho Repository, service implementation, deployment model, processors, data structures, and AGPL-3.0 license state. Open repository
- Honcho architecture Core concepts for workspaces, peers, sessions, messages, background processing, and context retrieval. Open documentation
Source-state caveat. This page describes publicly documented and repository-visible product behavior at the review date. It does not guarantee a specific hosted plan, unreleased feature, adapter version, or future API.
Performance caveat. Trajectory’s 5.4-5.6× reductions are identified here as vendor-reported sample results. They should not be generalized across agents, transcript types, workloads, or quality thresholds without independent evaluation.