Advanced Context Block construction

This guide covers building context blocks from scratch using graph search for maximum customization. See Choosing a retrieval method for a comparison of all three context retrieval approaches.

When searching the graph instead of using Zep’s Context Block, you need to use the search results to create a custom context block. In this recipe, we will demonstrate how to build a custom context block using the graph search API. We will also use the custom entity and edge types feature, though using this feature is optional.

Include fact validity. When you build a custom context block, include each fact’s valid_at and invalid_at dates, and clearly mark any fact with a non-null invalid_at as no longer valid. This lets the agent tell current facts from outdated ones instead of treating every fact as true now. The examples below format validity as a date range: a range ending in present is currently valid, and a past end date means the fact is no longer valid.

Add data

First, we define our custom entity and edge types, create a user, and add some example data:

1import uuid
2from zep_cloud import Message
3from zep_cloud.external_clients.ontology import EntityModel, EntityText, EdgeModel, EntityBoolean
4from zep_cloud import EntityEdgeSourceTarget
5from pydantic import Field
6
7class Restaurant(EntityModel):
8 """
9 Represents a specific restaurant.
10 """
11 cuisine_type: EntityText = Field(description="The cuisine type of the restaurant, for example: American, Mexican, Indian, etc.", default=None)
12 dietary_accommodation: EntityText = Field(description="The dietary accommodation of the restaurant, if any, for example: vegetarian, vegan, etc.", default=None)
13
14class RestaurantVisit(EdgeModel):
15 """
16 Represents the fact that the user visited a restaurant.
17 """
18 restaurant_name: EntityText = Field(description="The name of the restaurant the user visited", default=None)
19
20class DietaryPreference(EdgeModel):
21 """
22 Represents the fact that the user has a dietary preference or dietary restriction.
23 """
24 preference_type: EntityText = Field(description="Preference type of the user: anything, vegetarian, vegan, peanut allergy, etc.", default=None)
25 allergy: EntityBoolean = Field(description="Whether this dietary preference represents a user allergy: True or false", default=None)
26
27client.graph.set_ontology(
28 entities={
29 "Restaurant": Restaurant,
30 },
31 edges={
32 "RESTAURANT_VISIT": (
33 RestaurantVisit,
34 [EntityEdgeSourceTarget(source="User", target="Restaurant")]
35 ),
36 "DIETARY_PREFERENCE": (
37 DietaryPreference,
38 [EntityEdgeSourceTarget(source="User")]
39 ),
40 }
41)
42
43messages_thread1 = [
44 Message(content="Take me to a lunch place", role="user", name="John Doe"),
45 Message(content="How about Panera Bread, Chipotle, or Green Leaf Cafe, which are nearby?", role="assistant", name="Assistant"),
46 Message(content="Do any of those have vegetarian options? I’m vegetarian", role="user", name="John Doe"),
47 Message(content="Yes, Green Leaf Cafe has vegetarian options", role="assistant", name="Assistant"),
48 Message(content="Let’s go to Green Leaf Cafe", role="user", name="John Doe"),
49 Message(content="Navigating to Green Leaf Cafe", role="assistant", name="Assistant"),
50]
51
52messages_thread2 = [
53 Message(content="Take me to dessert", role="user", name="John Doe"),
54 Message(content="How about getting some ice cream?", role="assistant", name="Assistant"),
55 Message(content="I can't have ice cream, I'm lactose intolerant, but I'm craving a chocolate chip cookie", role="user", name="John Doe"),
56 Message(content="Sure, there's Insomnia Cookies nearby.", role="assistant", name="Assistant"),
57 Message(content="Perfect, let's go to Insomnia Cookies", role="user", name="John Doe"),
58 Message(content="Navigating to Insomnia Cookies.", role="assistant", name="Assistant"),
59]
60
61user_id = f"user-{uuid.uuid4()}"
62client.user.add(user_id=user_id, first_name="John", last_name="Doe", email="[email protected]")
63
64thread1_id = f"thread-{uuid.uuid4()}"
65thread2_id = f"thread-{uuid.uuid4()}"
66client.thread.create(thread_id=thread1_id, user_id=user_id)
67client.thread.create(thread_id=thread2_id, user_id=user_id)
68
69client.thread.add_messages(thread_id=thread1_id, messages=messages_thread1, ignore_roles=["assistant"])
70client.thread.add_messages(thread_id=thread2_id, messages=messages_thread2, ignore_roles=["assistant"])

Example 1: Basic custom context block

For a basic custom context block, we search the graph for edges and nodes relevant to our custom query string, which typically represents a user message. Note that the default Context Block returned by thread.get_user_context uses the past few messages as the query instead.

Run these searches in parallel with the asynchronous Python client, TypeScript promises, or goroutines.

1query = "Find some food around here"
2
3search_results_nodes = client.graph.search(
4 query=query,
5 user_id=user_id,
6 scope='nodes',
7 reranker='cross_encoder',
8 limit=10
9)
10search_results_edges = client.graph.search(
11 query=query,
12 user_id=user_id,
13 scope='edges',
14 reranker='cross_encoder',
15 limit=10
16)

Build the context block

Using the search results and a few helper functions, we can build the context block. Note that for nodes, we typically want to unpack the node name and node summary, and for edges we typically want to unpack the fact and the temporal validity information:

1from zep_cloud import EntityEdge, EntityNode
2
3CONTEXT_STRING_TEMPLATE = """
4FACTS and ENTITIES represent relevant context to the current conversation.
5# These are the most relevant facts and their valid date ranges
6# format: FACT (Date range: from - to)
7# NOTE: Facts ending in "present" are currently valid (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - present)" means Jane currently prefers coffee with milk)
8# Facts with a past end date used to be valid but are NOT CURRENTLY VALID (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - 2024-06-20 14:00:00)" means Jane no longer prefers coffee with milk)
9<FACTS>
10{facts}
11</FACTS>
12
13# These are the most relevant entities
14# ENTITY_NAME: entity summary
15<ENTITIES>
16{entities}
17</ENTITIES>
18"""
19
20
21def format_fact(edge: EntityEdge) -> str:
22 valid_at = edge.valid_at if edge.valid_at is not None else "date unknown"
23 invalid_at = edge.invalid_at if edge.invalid_at is not None else "present"
24 formatted_fact = f" - {edge.fact} (Date range: {valid_at} - {invalid_at})"
25 return formatted_fact
26
27def format_entity(node: EntityNode) -> str:
28 formatted_entity = f" - {node.name}: {node.summary}"
29 return formatted_entity
30
31def compose_context_block(edges: list[EntityEdge], nodes: list[EntityNode]) -> str:
32 facts = [format_fact(edge) for edge in edges]
33 entities = [format_entity(node) for node in nodes]
34 return CONTEXT_STRING_TEMPLATE.format(facts='\n'.join(facts), entities='\n'.join(entities))
35
36edges = search_results_edges.edges
37nodes = search_results_nodes.nodes
38
39context_block = compose_context_block(edges, nodes)
40print(context_block)
FACTS and ENTITIES represent relevant context to the current conversation.
# These are the most relevant facts and their valid date ranges
# format: FACT (Date range: from - to)
# NOTE: Facts ending in "present" are currently valid (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - present)" means Jane currently prefers coffee with milk)
# Facts with a past end date used to be valid but are NOT CURRENTLY VALID (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - 2024-06-20 14:00:00)" means Jane no longer prefers coffee with milk)
<FACTS>
- User wants to go to dessert (Date range: 2025-06-16T02:17:25Z - present)
- John Doe wants to go to a lunch place (Date range: 2025-06-16T02:17:25Z - present)
- John Doe said 'Perfect, let's go to Insomnia Cookies' indicating he will visit Insomnia Cookies. (Date range: 2025-06-16T02:17:25Z - present)
- John Doe said 'Let’s go to Green Leaf Cafe' indicating intention to visit (Date range: 2025-06-16T02:17:25Z - present)
- John Doe is craving a chocolate chip cookie (Date range: 2025-06-16T02:17:25Z - present)
- John Doe states that he is vegetarian. (Date range: 2025-06-16T02:17:25Z - present)
- John Doe is lactose intolerant (Date range: 2025-06-16T02:17:25Z - present)
</FACTS>
# These are the most relevant entities
# ENTITY_NAME: entity summary
<ENTITIES>
- lunch place: The entity is a lunch place, but no specific details about its cuisine or dietary accommodations are provided.
- dessert: The entity 'dessert' refers to a preference related to sweet courses typically served at the end of a meal. The context indicates that the user has expressed an interest in going to a dessert place, but no specific dessert or place has been named. The entity is categorized as a Preference and Entity, but no additional attributes are provided or inferred from the messages.
- Green Leaf Cafe: Green Leaf Cafe is a restaurant that offers vegetarian options, making it suitable for vegetarian diners.
- user: The user is John Doe, with the email [email protected]. He has shown interest in visiting Green Leaf Cafe, which offers vegetarian options, and has also expressed a preference for lactose-free options, craving a chocolate chip cookie. The user has decided to go to Insomnia Cookies.
- vegetarian: The user is interested in lunch places such as Panera Bread, Chipotle, and Green Leaf Cafe. They are specifically looking for vegetarian options at these restaurants.
- chocolate chip cookie: The entity is a chocolate chip cookie, which the user desires as a snack. The user is lactose intolerant and cannot have ice cream, but is craving a chocolate chip cookie.
- Insomnia Cookies: Insomnia Cookies is a restaurant that offers cookies, including chocolate chip cookies. The user is interested in a dessert and has chosen to go to Insomnia Cookies. No specific cuisine type or dietary accommodations are mentioned in the messages.
- lactose intolerant: The entity is a preference indicating lactose intolerance, which is a dietary restriction that prevents the individual from consuming lactose, a sugar found in milk and dairy products. The person is specifically craving a chocolate chip cookie but cannot have ice cream due to lactose intolerance.
- John Doe: The user is John Doe, with user ID user-34c7a6c1-ded6-4797-9620-8b80a5e7820f, email [email protected], and role user. He inquired about nearby lunch options and vegetarian choices, and expressed a preference for a chocolate chip cookie due to lactose intolerance.
</ENTITIES>

Example 2: Utilizing custom entity and edge types

Search

For a custom context block that uses custom entity and edge types, we perform multiple searches (with our custom query string) filtering to the custom entity or edge type we want to include in the context block:

Run these searches in parallel with the asynchronous Python client, TypeScript promises, or goroutines.

1query = "Find some food around here"
2
3search_results_restaurant_visits = client.graph.search(
4 query=query,
5 user_id=user_id,
6 scope='edges',
7 search_filters={
8 "edge_types": ["RESTAURANT_VISIT"]
9 },
10 reranker='cross_encoder',
11 limit=10
12)
13search_results_dietary_preferences = client.graph.search(
14 query=query,
15 user_id=user_id,
16 scope='edges',
17 search_filters={
18 "edge_types": ["DIETARY_PREFERENCE"]
19 },
20 reranker='cross_encoder',
21 limit=10
22)
23search_results_restaurants = client.graph.search(
24 query=query,
25 user_id=user_id,
26 scope='nodes',
27 search_filters={
28 "node_labels": ["Restaurant"]
29 },
30 reranker='cross_encoder',
31 limit=10
32)

Build the context block

Using the search results and a few helper functions, we can compose the context block. Note that in this example, we focus on unpacking the custom attributes of the nodes and edges, but this is a design choice that you can experiment with for your use case.

Note also that we designed the context block template around the custom entity and edge types that we are unpacking into the context block:

1from zep_cloud import EntityEdge, EntityNode
2
3CONTEXT_STRING_TEMPLATE = """
4PREVIOUS_RESTAURANT_VISITS, DIETARY_PREFERENCES, and RESTAURANTS represent relevant context to the current conversation.
5# These are the most relevant restaurants the user has previously visited
6# format: restaurant_name: RESTAURANT_NAME
7<PREVIOUS_RESTAURANT_VISITS>
8{restaurant_visits}
9</PREVIOUS_RESTAURANT_VISITS>
10
11# These are the most relevant dietary preferences of the user, whether they represent an allergy, and their valid date ranges
12# format: allergy: True/False; preference_type: PREFERENCE_TYPE (Date range: from - to)
13<DIETARY_PREFERENCES>
14{dietary_preferences}
15</DIETARY_PREFERENCES>
16
17# These are the most relevant restaurants the user has discussed previously
18# format: name: RESTAURANT_NAME; cuisine_type: CUISINE_TYPE; dietary_accommodation: DIETARY_ACCOMMODATION
19<RESTAURANTS>
20{restaurants}
21</RESTAURANTS>
22"""
23
24def format_edge_with_attributes(edge: EntityEdge, include_timestamps: bool = True) -> str:
25 attrs_str = '; '.join(f"{k}: {v}" for k, v in sorted(edge.attributes.items()))
26 if include_timestamps:
27 valid_at = edge.valid_at if edge.valid_at is not None else "date unknown"
28 invalid_at = edge.invalid_at if edge.invalid_at is not None else "present"
29 return f" - {attrs_str} (Date range: {valid_at} - {invalid_at})"
30 return f" - {attrs_str}"
31
32def format_node_with_attributes(node: EntityNode) -> str:
33 attributes = {k: v for k, v in node.attributes.items() if k != "labels"}
34 attrs_str = '; '.join(f"{k}: {v}" for k, v in sorted(attributes.items()))
35 base = f" - name: {node.name}; {attrs_str}"
36 return base
37
38def compose_context_block(restaurant_visit_edges: list[EntityEdge], dietary_preference_edges: list[EntityEdge], restaurant_nodes: list[EntityNode]) -> str:
39 restaurant_visits = [format_edge_with_attributes(edge, include_timestamps=False) for edge in restaurant_visit_edges]
40 dietary_preferences = [format_edge_with_attributes(edge, include_timestamps=True) for edge in dietary_preference_edges]
41 restaurant_nodes = [format_node_with_attributes(node) for node in restaurant_nodes]
42 return CONTEXT_STRING_TEMPLATE.format(restaurant_visits='\n'.join(restaurant_visits), dietary_preferences='\n'.join(dietary_preferences), restaurants='\n'.join(restaurant_nodes))
43
44
45restaurant_visit_edges = search_results_restaurant_visits.edges
46dietary_preference_edges = search_results_dietary_preferences.edges
47restaurant_nodes = search_results_restaurants.nodes
48
49context_block = compose_context_block(restaurant_visit_edges, dietary_preference_edges, restaurant_nodes)
50print(context_block)
PREVIOUS_RESTAURANT_VISITS, DIETARY_PREFERENCES, and RESTAURANTS represent relevant context to the current conversation.
# These are the most relevant restaurants the user has previously visited
# format: restaurant_name: RESTAURANT_NAME
<PREVIOUS_RESTAURANT_VISITS>
- restaurant_name: Insomnia Cookies
- restaurant_name: Green Leaf Cafe
</PREVIOUS_RESTAURANT_VISITS>
# These are the most relevant dietary preferences of the user, whether they represent an allergy, and their valid date ranges
# format: allergy: True/False; preference_type: PREFERENCE_TYPE (Date range: from - to)
<DIETARY_PREFERENCES>
- allergy: False; preference_type: vegetarian (Date range: 2025-06-16T02:17:25Z - present)
- allergy: False; preference_type: lactose intolerance (Date range: 2025-06-16T02:17:25Z - present)
</DIETARY_PREFERENCES>
# These are the most relevant restaurants the user has discussed previously
# format: name: RESTAURANT_NAME; cuisine_type: CUISINE_TYPE; dietary_accommodation: DIETARY_ACCOMMODATION
<RESTAURANTS>
- name: Green Leaf Cafe; dietary_accommodation: vegetarian
- name: Insomnia Cookies;
</RESTAURANTS>

Example 3: Basic custom context block with BFS

Search

You can use breadth-first search (BFS) to expand results around recent history. This example retrieves recent episodes and uses their UUIDs as BFS origins.

The BFS section explains the search behavior.

Run these searches in parallel with the asynchronous Python client, TypeScript promises, or goroutines.

1query = "Find some food around here"
2
3episodes = client.graph.episode.get_by_user_id(
4 user_id=user_id,
5 lastn=10
6).episodes
7
8episode_uuids = [episode.uuid_ for episode in episodes if episode.role_type == 'user']
9
10search_results_nodes = client.graph.search(
11 query=query,
12 user_id=user_id,
13 scope='nodes',
14 reranker='cross_encoder',
15 limit=10,
16 bfs_origin_node_uuids=episode_uuids
17)
18search_results_edges = client.graph.search(
19 query=query,
20 user_id=user_id,
21 scope='edges',
22 reranker='cross_encoder',
23 limit=10,
24 bfs_origin_node_uuids=episode_uuids
25)

Build the context block

Using the search results and a few helper functions, we can build the context block. Note that for nodes, we typically want to unpack the node name and node summary, and for edges we typically want to unpack the fact and the temporal validity information:

1from zep_cloud import EntityEdge, EntityNode
2
3CONTEXT_STRING_TEMPLATE = """
4FACTS and ENTITIES represent relevant context to the current conversation.
5# These are the most relevant facts and their valid date ranges
6# format: FACT (Date range: from - to)
7# NOTE: Facts ending in "present" are currently valid (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - present)" means Jane currently prefers coffee with milk)
8# Facts with a past end date used to be valid but are NOT CURRENTLY VALID (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - 2024-06-20 14:00:00)" means Jane no longer prefers coffee with milk)
9<FACTS>
10{facts}
11</FACTS>
12
13# These are the most relevant entities
14# ENTITY_NAME: entity summary
15<ENTITIES>
16{entities}
17</ENTITIES>
18"""
19
20
21def format_fact(edge: EntityEdge) -> str:
22 valid_at = edge.valid_at if edge.valid_at is not None else "date unknown"
23 invalid_at = edge.invalid_at if edge.invalid_at is not None else "present"
24 formatted_fact = f" - {edge.fact} (Date range: {valid_at} - {invalid_at})"
25 return formatted_fact
26
27def format_entity(node: EntityNode) -> str:
28 formatted_entity = f" - {node.name}: {node.summary}"
29 return formatted_entity
30
31def compose_context_block(edges: list[EntityEdge], nodes: list[EntityNode]) -> str:
32 facts = [format_fact(edge) for edge in edges]
33 entities = [format_entity(node) for node in nodes]
34 return CONTEXT_STRING_TEMPLATE.format(facts='\n'.join(facts), entities='\n'.join(entities))
35
36edges = search_results_edges.edges
37nodes = search_results_nodes.nodes
38
39context_block = compose_context_block(edges, nodes)
40print(context_block)
FACTS and ENTITIES represent relevant context to the current conversation.
# These are the most relevant facts and their valid date ranges
# format: FACT (Date range: from - to)
# NOTE: Facts ending in "present" are currently valid (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - present)" means Jane currently prefers coffee with milk)
# Facts with a past end date used to be valid but are NOT CURRENTLY VALID (e.g., "Jane prefers her coffee with milk (2024-01-15 10:30:00 - 2024-06-20 14:00:00)" means Jane no longer prefers coffee with milk)
<FACTS>
- User wants to go to dessert (Date range: 2025-06-16T02:17:25Z - present)
- John Doe wants to go to a lunch place (Date range: 2025-06-16T02:17:25Z - present)
- John Doe said 'Perfect, let's go to Insomnia Cookies' indicating he will visit Insomnia Cookies. (Date range: 2025-06-16T02:17:25Z - present)
- John Doe said 'Let's go to Green Leaf Cafe' indicating intention to visit (Date range: 2025-06-16T02:17:25Z - present)
- John Doe is craving a chocolate chip cookie (Date range: 2025-06-16T02:17:25Z - present)
- John Doe states that he is vegetarian. (Date range: 2025-06-16T02:17:25Z - present)
- John Doe is lactose intolerant (Date range: 2025-06-16T02:17:25Z - present)
</FACTS>
# These are the most relevant entities
# ENTITY_NAME: entity summary
<ENTITIES>
- lunch place: The entity is a lunch place, but no specific details about its cuisine or dietary accommodations are provided.
- dessert: The entity 'dessert' refers to a preference related to sweet courses typically served at the end of a meal. The context indicates that the user has expressed an interest in going to a dessert place, but no specific dessert or place has been named. The entity is categorized as a Preference and Entity, but no additional attributes are provided or inferred from the messages.
- Green Leaf Cafe: Green Leaf Cafe is a restaurant that offers vegetarian options, making it suitable for vegetarian diners.
- user: The user is John Doe, with the email [email protected]. He has shown interest in visiting Green Leaf Cafe, which offers vegetarian options, and has also expressed a preference for lactose-free options, craving a chocolate chip cookie. The user has decided to go to Insomnia Cookies.
- vegetarian: The user is interested in lunch places such as Panera Bread, Chipotle, and Green Leaf Cafe. They are specifically looking for vegetarian options at these restaurants.
- chocolate chip cookie: The entity is a chocolate chip cookie, which the user desires as a snack. The user is lactose intolerant and cannot have ice cream, but is craving a chocolate chip cookie.
- Insomnia Cookies: Insomnia Cookies is a restaurant that offers cookies, including chocolate chip cookies. The user is interested in a dessert and has chosen to go to Insomnia Cookies. No specific cuisine type or dietary accommodations are mentioned in the messages.
- lactose intolerant: The entity is a preference indicating lactose intolerance, which is a dietary restriction that prevents the individual from consuming lactose, a sugar found in milk and dairy products. The person is specifically craving a chocolate chip cookie but cannot have ice cream due to lactose intolerance.
- John Doe: The user is John Doe, with user ID user-34c7a6c1-ded6-4797-9620-8b80a5e7820f, email [email protected], and role user. He inquired about nearby lunch options and vegetarian choices, and expressed a preference for a chocolate chip cookie due to lactose intolerance.
</ENTITIES>

Example 4: Using user summary in context block

Get user node

Retrieve the user node when you need its summary in a custom Context Block. User summary instructions control the generated summary.

About the user node

Each user has a single unique user node in their graph representing the user themselves. The user summary generated from user summary instructions lives on this user node. When you call client.user.get_node(), you are retrieving this special node that contains the user’s summary.

1from zep_cloud.client import Zep
2
3client = Zep(api_key=API_KEY)
4
5# Get the user node and extract the summary
6user_node_response = client.user.get_node(user_id=user_id)
7user_summary = user_node_response.node.summary if user_node_response.node else None

Build the context block

Using the user summary, you can create a simple context block that provides personalized user information:

1# Build a simple context block with user summary
2context_block = f"""USER_SUMMARY represents relevant context about the user.
3# This is a high-level summary of the user
4<USER_SUMMARY>
5{user_summary if user_summary else "No user summary available"}
6</USER_SUMMARY>
7"""
8
9print(context_block)
USER_SUMMARY represents relevant context about the user.
# This is a high-level summary of the user
<USER_SUMMARY>
John Doe is a software engineer who enjoys hiking and photography. He is vegetarian and lactose intolerant. He prefers detailed technical discussions and values efficiency in communication. He has requested that the AI provide concise answers with code examples when discussing programming topics.
</USER_SUMMARY>

Use the custom context block

The Context Block can contain text that came from end users, documents, tools, or other external sources. A privileged message gives that text higher instruction priority than ordinary input. Keep the Context Block out of system messages, developer messages, and other privileged instruction channels.

Follow your model provider’s documented method for separating instructions from data:

  • For the OpenAI Responses API, send preloaded context through ordinary input or a user message. Use function_call_output only for the result of an actual function call.
  • For the Anthropic Messages API, design retrieval as a tool call when context can contain third-party data. Return the context in a tool_result block linked to the original tool_use_id.
  • For other providers, use the documented untrusted-data channel. If the provider does not define one, use an ordinary user-level message with explicit data framing.

OpenAI with preloaded context

Message typeContent
Developer or instructionsStable application policy. No Zep context.
AssistantAn assistant message stored in Zep
UserA user message stored in Zep
User or ordinary input{Zep Context Block} framed as reference data
UserThe latest user request

Place the Context Block after the conversation history and before the latest user request. Everything before the block stays unchanged between turns, so this order preserves the cacheable prefix that prompt caching needs. Replace the previous turn’s block instead of appending a second one.

If the model requests memory through a function, return the Context Block as function_call_output linked to the original call_id.

OpenAI Chat Completions with tool-retrieved context

Message typeContent
DeveloperStable application policy. No Zep context.
UserThe latest user request
AssistantA tool call requesting Zep retrieval
Tool{Zep Context Block}, linked by tool_call_id
AssistantThe response to the user

Anthropic with tool-retrieved context

Message typeContent
SystemStable application policy. No Zep context.
UserThe latest user request
AssistantA tool_use block requesting Zep retrieval
UserA tool_result block with {Zep Context Block}, linked by tool_use_id
AssistantThe response to the user

Do not create a tool message for preloaded context unless the provider documents that pattern. A tool-result type must remain linked to the model’s actual tool request.

Read Memory security best practices for provider-specific mappings, write controls, action authorization, and recovery guidance.