feat(node): add xTrace node

[jmaionchi]

Problem Statement

We have a hackathon co-hosted with xTrace on June 5. We should have xTrace integrated.

Proposed Solution

https://xtrace.ai/

xTrace is basically shared memory with reasoning to help identify what's relevant for the prompt.

Alternatives Considered

No response

Affected Modules

• server (C++ engine)
• client-typescript
• client-python
• client-mcp
• nodes (pipeline)
• ai
• chat-ui
• dropper-ui
• vscode
• tika

[github-actions]

[dsapandora]

Read the product docs (docs.mem.xtrace.ai) to ground the node. This integration is xTrace Memory Manager — shared memory with reasoning to surface what's relevant for the prompt. It's GA today.

What xTrace Memory Manager is

Hosted memory service for agents. You send conversation turns; the server LLM-extracts structured facts / artifacts / episodes (resolving conflicts, knowing what's outdated — that's the "reasoning", not just raw storage), embeds each one, and stores them in a per-org index. You retrieve later with natural-language search, scoped to a user or shared across a group.

• Auth: every request needs two headers — Authorization: Bearer xtk_... and X-Org-Id: org_.... Credentials from app.xtrace.ai → Settings → API Keys. (authentication guide)
• Ingest (write): async by default → 202 + job_id, poll GET /v1/memories/jobs/{job_id}; or sync { wait: true } (server holds up to 30s). Required: messages[], user_id, conv_id. Optional: agent_id, app_id, group_ids, extract_artifacts.
• Search / recall (read): vector-ranked, "scope by what you pass" (AND-narrowing over user_id / group_ids / agent_id / app_id; at least one required). recall combines a user's own memories + a shared group's into a ready-to-inject prompt — this is the "what's relevant for the prompt" piece. There's also an agentic search endpoint.
• Groups: tag memories at ingest → shared across users/agents (the "shared" part).
• SDK: TypeScript @xtraceai/memory is the primary client today; Python SDK is on the roadmap. Underlying HTTP API is fully documented.

Proposed implementation

xtrace_memory node, classType: ["memory"], mirroring memory_internal but persistent and shared, controlled by the agent via control: [{"classType":"memory","from":"agent_id"}].

• Backed by the Memory HTTP API directly (RocketRide nodes are Python; the Python SDK isn't out yet — so call the REST API with the two auth headers).
• Maps cleanly to the existing memory contract: agent turn → ingest; context fetch → search/recall.
• Config: api_key (secure, xtk_...), org_id, default scope (user_id / agent_id / app_id / group_ids), ingest mode (async+poll vs wait:true), extract_artifacts, search limit.
• Deliverables: node + examples/xtrace-memory-agent.pipe (agent with shared memory) + ingest/search round-trip test against a test org.

For the hackathon (Jun 5)

Ship the xtrace_memory node against the Memory HTTP API. The recall + groups story is exactly the "shared brain across agents" framing, and it's available now.

Risk notes: async ingest needs job polling (or use wait:true for the demo path); since the Python SDK isn't out, pin the HTTP API contract from the API Reference; surface limit/scope as config to avoid unscoped-search 422s.