feat: expose tool traces to memory providers by devwdave · Pull Request #28065 · NousResearch/hermes-agent

devwdave · 2026-05-18T15:37:05Z

What does this PR do?

Adds Memori to the community plugin documentation as a standalone external memory provider, and adds the generic memory-provider trace support needed for providers like Memori to capture meaningful agent memory.

This does not add Memori as an in-tree provider. Memori remains distributed as a standalone community plugin/package. The Hermes-side change is a backward-compatible optional trace payload for external memory providers, so they can receive structured completed-turn tool execution metadata.

Trace data is critical for agent memory because the final assistant response often does not contain the actual work the agent performed. For example, an assistant may say “Tests passed,” but the useful memory is that Hermes ran terminal({"command": "pytest"}), received the test output, and then summarized it. Without trace data, external memory only captures what the assistant said, not what the agent actually did.

Existing memory providers remain compatible. Hermes only passes trace to providers whose sync_turn() accepts it.

Related Issue

Fixes #

Type of Change

🐛 Bug fix (non-breaking change that fixes an issue)
✨ New feature (non-breaking change that adds functionality)
🔒 Security fix
📝 Documentation update
✅ Tests (adding or improving test coverage)
♻️ Refactor (no behavior change)
🎯 New skill (bundled or hub)

Changes Made

README.md
- Adds hermes-memori to the community plugins section.
website/docs/user-guide/features/memory-providers.md
- Adds Memori under community providers as a standalone external memory provider.
agent/memory_provider.py
- Adds optional trace parameter to the MemoryProvider.sync_turn() interface.
- Documents that providers can ignore the trace if they do not need tool execution metadata.
agent/memory_manager.py
- Updates sync_all() to accept an optional trace.
- Uses provider signature inspection to preserve compatibility with providers that still implement the older sync_turn(user, assistant, session_id=...) shape.
agent/agent_init.py
- Initializes per-turn tool trace storage on the agent.
agent/conversation_loop.py
- Resets tool trace storage at the start of each turn.
- Passes the final message list into completed-turn external memory sync.
agent/tool_executor.py
- Records structured trace entries for sequential and concurrent tool calls.
- Includes tool name, arguments, result content, duration, error state, blocked state, and cancelled state.
- Records skipped/cancelled tool calls so interrupted execution is represented accurately.
run_agent.py
- Adds helpers to record per-turn tool observations and build a versioned external memory trace payload.
- Sends the trace to memory providers during completed-turn sync when tool calls occurred.
tests/agent/test_memory_provider.py
- Adds coverage proving trace is passed to opted-in providers and omitted for legacy providers.
tests/run_agent/test_memory_sync_interrupted.py
- Adds coverage for completed-turn trace sync, ordering, final tool result content, and blocked/cancelled status.
website/docs/developer-guide/memory-provider-plugin.md
- Documents the optional trace argument for sync_turn().
- Adds a note that cloud providers should document what trace data may be sent off-device.

How to Test

Run the focused memory provider and trace tests:

uv run pytest tests/agent/test_memory_provider.py tests/run_agent/test_memory_sync_interrupted.py

Verify the focused test suite passes:
```
83 passed
```

Optionally test with a memory provider whose sync_turn() accepts trace=None and confirm it receives a payload like:

{
  "version": 1,
  "capture_policy": "full_raw_after_hermes_processing",
  "tool_calls": [
    {
      "order": 1,
      "name": "terminal",
      "arguments": {"command": "pytest"},
      "result_content": "...",
      "duration_seconds": 2.21,
      "is_error": false,
      "blocked": false,
      "cancelled": false
    }
  ]
}

Checklist

Code

I've read the Contributing Guide
My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
I searched for existing PRs to make sure this isn't a duplicate
My PR contains only changes related to this fix/feature (no unrelated commits)
I've run pytest tests/ -q and all tests pass
I've added tests for my changes (required for bug fixes, strongly encouraged for features)
I've tested on my platform: macOS

Documentation & Housekeeping

I've updated relevant documentation (README, docs/, docstrings) — or N/A
I've updated cli-config.yaml.example if I added/changed config keys — or N/A
I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

N/A

Screenshots / Logs

Focused test run:

uv run pytest tests/agent/test_memory_provider.py tests/run_agent/test_memory_sync_interrupted.py

83 passed

…-provider-docs

Added a new function, _record_turn_tool_trace, to facilitate per-turn tool tracing for agents. This function is invoked in multiple locations within execute_tool_calls_concurrent and execute_tool_calls_sequential to record trace data, enhancing the tracking of tool call executions. This change improves the observability of agent actions during tool interactions.

kshitijk4poor · 2026-05-28T20:06:51Z

Thanks for reworking this as a standalone plugin + generic hook rather than an in-tree provider — that's the right call, and the backward-compat signature inspection is clean.

Before we lock in a new structured-trace contract though, I want to make sure we're not adding core surface we already have. A couple of things:

The full message list — tool calls and results included — is already handed to providers via on_session_end(messages) and on_pre_compress(messages). So the raw "what did the agent actually do" data was never inaccessible; a provider can read every terminal(...) call and its result from there today.

The genuine gap is timing/granularity: sync_turn is the only per-turn persistence hook and it's text-only, while on_session_end deliberately fires only at real session boundaries (not after each turn). That's a real limitation for incremental background ingestion.

But the minimal fix for that is to thread the existing messages list into sync_turn — which this PR already plumbs through _sync_external_memory_for_turn — and let providers extract what they need from it. That's a few lines and no new contract for us to maintain.

The part that genuinely isn't reconstructable from the message list is the per-tool duration_seconds / blocked / cancelled metadata and the capture_policy final-content normalization. If those signals are central to Memori, could you make the case for them specifically? Otherwise we'd prefer to keep the core contract as sync_turn(..., messages=...) and avoid owning a structured-trace schema (version, capture_policy, per-tool envelope) on behalf of an out-of-tree package — that's a stability commitment that's hard to walk back once it ships.

Happy to merge a slimmed-down version quickly. Feel free to push back if I'm missing why the structured envelope needs to live in core.

devwdave · 2026-05-28T20:16:07Z

Thanks for the feedback!

That framing makes sense.

I’ll slim this down to pass the existing OpenAI-style messages list into sync_turn with backward-compatible signature inspection, and remove the structured trace envelope from core. Memori can extract tool calls/results from the transcript and use plugin hooks for richer provider-local telemetry if needed.

I don’t think duration/block/cancel metadata is essential, so that is fine!

I'll have an updated PR shortly!

devwdave · 2026-05-28T20:23:58Z

@kshitijk4poor this PR has been slimmed down and incorporates the feedback you've provided.

Thank you!!

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai>

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes.

…sages feat: expose completed-turn message context to memory providers (salvage #28065)

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai> #AI commit#

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes. #AI commit#

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai>

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes.

The OpenVikingMemoryProvider.sync_turn() previously only received user_content and assistant_content as plain text (truncated to 4K each), discarding all tool calls, tool results, and intermediate messages from multi-step agent turns. This commit wires the optional messages kwarg (added in commit 5a95fb2 / NousResearch#28065) to OpenViking's session sync path: - Accept messages: Optional[List[Dict]] in sync_turn() signature - Track _last_message_count to POST only the delta of new messages on each turn (avoids re-sending entire history every call) - Serialize tool_calls to compact text form for the session API - Include role:tool messages (tool results) alongside user/assistant - Skip system prompts (session-wide state, not conversational turns) - Reset _last_message_count in initialize() and on_session_switch() - Keep legacy text-only fallback when messages is not provided Closes NousResearch#34762

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai>

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes.

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai>

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes.

Adds an optional `messages` keyword to the `MemoryProvider.sync_turn` contract so external/community memory plugins can receive the OpenAI-style conversation message list for the completed turn — including assistant tool calls and tool result content — not just the final assistant text. Dispatch uses signature inspection (`_provider_sync_accepts_messages`): only providers that declare a `messages` parameter (or `**kwargs`) receive it; all existing in-tree providers keep their legacy text-only signature and are called unchanged. No structured-trace envelope is added to core — providers reconstruct whatever they need from the standard message list. Also documents Memori as a standalone community memory provider. Salvaged from NousResearch#28065 — rebased onto current main. Co-authored-by: Dave Heritage <david@memorilabs.ai>

Maps both commit emails (david@memorilabs.ai, dave@devwdave.com) used on NousResearch#28065 to the devwdave GitHub account so the contributor audit in scripts/release.py passes.

…ri-trace-messages feat: expose completed-turn message context to memory providers (salvage NousResearch#28065)

devwdave mentioned this pull request May 18, 2026

Memori memory provider #24476

Closed

23 tasks

AStruck24 approved these changes May 18, 2026

View reviewed changes

alt-glitch added type/feature New feature or request comp/agent Core agent loop, run_agent.py, prompt builder tool/memory Memory tool and memory providers P3 Low — cosmetic, nice to have labels May 18, 2026

devwdave force-pushed the memori-memory-trace-provider-docs branch from b9f553b to ffbab38 Compare May 18, 2026 19:30

feat: expose tool traces to memory providers

d531b1b

devwdave force-pushed the memori-memory-trace-provider-docs branch from ffbab38 to d531b1b Compare May 18, 2026 19:32

Merge remote-tracking branch 'upstream/main' into memori-memory-trace…

4e0d63f

…-provider-docs

lsaether mentioned this pull request May 23, 2026

[Feature]: Persist and replay ACP tool-call timing metadata #31117

Open

1 task

devwdave and others added 2 commits May 28, 2026 09:46

Merge branch 'main' into memori-memory-trace-provider-docs

8254eac

refactor: pass turn messages to memory providers

23d993a

kshitijk4poor mentioned this pull request May 28, 2026

feat: expose completed-turn message context to memory providers (salvage #28065) #34097

Merged

kshitijk4poor closed this in #34097 May 28, 2026

kshitijk4poor added a commit that referenced this pull request May 28, 2026

Merge pull request #34097 from kshitijk4poor/salvage/memori-trace-mes…

11d9309

…sages feat: expose completed-turn message context to memory providers (salvage #28065)

BrewTestBot mentioned this pull request May 29, 2026

hermes-agent 2026.5.29 Homebrew/homebrew-core#285204

Merged

1 task

github-actions Bot mentioned this pull request May 29, 2026

chore: bump NousResearch/hermes-agent version from v2026.5.16 to v2026.5.29 Docker-Hub-sirmark/docker-hermes-agent#7

Merged

This was referenced May 29, 2026

feat(openviking): sync full turn context (tool calls + results) to OpenViking session #34762

Open

feat(openviking): sync full turn context (tool calls + results) to OpenViking session #34763

Open

gweeteve pushed a commit to gweeteve/hermes-agent that referenced this pull request Jun 2, 2026

Merge pull request NousResearch#34097 from kshitijk4poor/salvage/memo…

37e4dc0

…ri-trace-messages feat: expose completed-turn message context to memory providers (salvage NousResearch#28065)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: expose tool traces to memory providers#28065

feat: expose tool traces to memory providers#28065
devwdave wants to merge 5 commits into
NousResearch:mainfrom
devwdave:memori-memory-trace-provider-docs

devwdave commented May 18, 2026

Uh oh!

kshitijk4poor commented May 28, 2026

Uh oh!

devwdave commented May 28, 2026

Uh oh!

devwdave commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

devwdave commented May 18, 2026

What does this PR do?

Related Issue

Type of Change

Changes Made

How to Test

Checklist

Code

Documentation & Housekeeping

For New Skills

Screenshots / Logs

Uh oh!

kshitijk4poor commented May 28, 2026

Uh oh!

devwdave commented May 28, 2026

Uh oh!

devwdave commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants