Zep memory integration for AI Flowi Workflow

For Zep-backed conversation storage, AI Flowi Workflow exposes Zep Chat Memory with four settings: endpoint, credential, API path and session. It returns a Memory object, so retrieving text for display requires a compatible consumer rather than treating the output as a JSON search response.

Zep Chat Memory and the Message History retrieval/display path proposed below are documented in the catalogue; not production-tested by Ai Flowi. The AI Flowi Workflow 1.9.2 export dated 9 October 2026 identifies zep.ZepChatMemory and describes it as Retrieves and store chat messages from Zep. Consult the Zep catalogue entry alongside this configuration reference.

The four Zep Chat Memory settings

The Zep settings table has horizontal scrolling so the endpoint and session notes remain available on narrow screens.

Zep Chat Memory field reference
InputField typeRequiredConnection typesConfiguration boundary
api_base_pathstrOptionalNot specifiedExported choices: "api/v1", "api/v2". No default or compatibility matrix is given.
api_keystrOptionalEmpty listService credential setting; confirm the endpoint’s authentication requirement independently of this field flag.
session_idstrOptionalMessageSelects the prepared conversation; assignment and authorization behaviour are unspecified.
urlstrOptionalMessageEndpoint URL setting, accepting Message. URL composition and reachability are not described.

Every field is marked optional in this snapshot. That metadata does not identify a working empty configuration or settle the endpoint’s actual authentication requirements. On api_key, “Empty list” refers to explicit connection metadata; the API-path field has no accepted-connection list at all.

Service URL and API base path

url has field type str and accepts Message. api_base_path is also a string, with exactly two exported choices: "api/v1" and "api/v2". Those options describe the component selector, not all versions currently accepted by a Zep service.

URL/path assembly is unspecified for this Zep component. Obtain the endpoint format required by your actual service before filling both fields; do not guess whether the URL already includes an API suffix. The v2 selector alone cannot establish compatibility with your destination service.

Treat endpoint reachability, path support and authentication as separate setup questions. Changing the path cannot resolve an unapproved host or missing access. A credential accepted by the service still leaves the chosen API route’s availability to verify.

Session identifier and credential scope

session_id is a string accepting Message, but it represents the session selection rather than the current chat text. Use a stable identifier assigned by your application for an authorised session. Do not connect a user’s question into that field merely because the accepted connection type matches.

There is no separately exported user_id, metadata dictionary or search query on this Zep node. Session selection therefore must be inspected on its own terms. The session field provides no evidence of user isolation or automatic creation of a previously unused identifier.

Supply a service API key issued to your own Zep account through the credential handling guide and pay Zep’s charges separately.

A Memory object is the only exported output

Zep Chat Memory output contract
Display labelPort nameTypeUse boundary
MemorymemoryMemoryConnect to an input accepting Memory; this is not a Message, Table or JSON port.

Message History accepts Memory and documents the retrieval and message-display path. Follow that reference for consumer modes and outputs; the Zep-specific questions here concern endpoint selection and the session passed to that consumer.

The Zep output contains no exported search-results port and no documented JSON record schema. It also does not expose named graph-query, deletion or session-list operations. Those omissions limit what this particular component reference can promise, regardless of capabilities offered elsewhere by a provider.

Inspect one authorised synthetic session

example configuration, not a recorded test

Prepare an authorised synthetic session containing a fictional handover note through a service-supported method. Session preparation stays outside this retrieval graph: Zep Chat Memory’s four-field interface includes no creation operation.

  1. Add Zep Chat Memory. Set url to the endpoint supplied for your service and api_key using your credential. Neither a universal endpoint nor a secret value is provided here.
  2. Select api_base_path as "api/v1" or "api/v2" only after verifying which route your endpoint supports. Set session_id to the prepared synthetic session’s actual identifier.
  3. Use the Message History retrieval and display configuration to consume Zep memory, keeping the consumer’s session identifier aligned with the Zep setting.
  4. Inspect identifier precedence at the Memory connection: Zep and Message History each expose session_id, with no exported rule selecting one when their values differ.
  5. Inspect the retrieved text against the prepared handover note. Record empty retrieval, a session mismatch and service failures separately from a completed text retrieval.

The intended output is conversation text from the authorised synthetic session shown in the Playground. No returned note or successful request is claimed. This inspection requests conversation text only; configuration and billing for a subsequent model stage belong in the Language Model reference.

For the handover inspection, record both configured session_id values before reviewing retrieved text. If they differ, the note’s presence cannot tell you which identifier selected it: two prepared sessions could contain similar text. Resolve the consumer’s selection rule before accepting the graph for reuse. Changing Message History display settings would not answer that backend selection question. Keep the handover note attached to its preparation record so missing text can be traced to the intended destination rather than explained by guesswork.

How do I diagnose which Zep boundary failed?

Separate Zep endpoint, session and memory checks
BoundaryHold fixedWhat to inspect
Endpoint selectionApproved service URL and credential.Whether the chosen API path is accepted by the actual endpoint.
Session selectionURL, path and credential.Which authorised synthetic session supplies the retrieved messages.
Memory consumptionThe reviewed Memory connection.Whether a compatible consumer receives the intended conversation text.
Later answerRetrieved text and the actual prompt.Whether the answer uses the text supplied to it; storage alone does not establish recall.

If authentication or the API route fails, investigate the URL, path and key before adjusting retrieval ordering. If the service is reachable but the conversation is absent, inspect session preparation and identifier mapping before adding a model. A model cannot establish that a missing session was created.

The agent memory scope and lifecycle checks cover the general isolation exercise and retention review.

For a Zep endpoint change, retain the service-provided URL format and supported API path together as a configuration record. If a new endpoint requires a different path, validate that pair before reusing the prepared session identifier; a successful request to the former endpoint says nothing about session availability at the replacement. Avoid trying both selector values until one appears to return text and then treating that as a version contract. Obtain the supported URL/path combination and verify the prepared note at that destination. This distinguishes an endpoint migration from a consumer ordering issue.

When this session interface fits

Use this node when your existing Zep endpoint and session contract matches these four settings. The agent memory glossary explains retention and context concepts. For a separately named ingestion and search interface with user and metadata fields, inspect Mem0 integration; its JSON search output is a different contract, not a feature of the Zep node.

Choose another verified interface when direct JSON retrieval, graph operations or deletion is mandatory. Obtain provider-version compatibility evidence before adopting this snapshot for a new endpoint. The integration directory links the existing categories and their configuration scopes.

By Ai Flowi · Published

Workflow usage

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.