How to Store and Recall Past Tool Outcomes
Before You Start
You need a working tool execution loop and a persistent memory system. The memory system can be a custom implementation using a vector database, or a managed service like Adaptive Recall that provides storage, retrieval, and lifecycle management through a standard API. You also need clarity on which tool outcomes are worth remembering and which are too transient to store, because storing everything creates noise that degrades retrieval quality.
Step-by-Step Implementation
Not every tool result is worth remembering. A weather lookup for right now is stale in an hour. A customer's subscription tier is stable for months. A product recommendation that the user rejected is valuable negative signal. Decide for each tool category what constitutes a meaningful outcome that will be useful in future interactions.
The general rule is: store outcomes that inform future decisions, skip outcomes that are purely ephemeral. A customer's order history, the resolution of a support ticket, the result of a diagnostic check, a user's stated preferences, and the outcome of a configuration change are all worth storing. A timestamp, a random number, or a real-time metric that changes every second is not. When in doubt, store a concise summary rather than the raw result, because summaries are more useful for retrieval and consume less storage.
# After a successful tool call, extract the meaningful outcome
def extract_outcome(tool_name, tool_input, tool_result, context):
if tool_name == "get_order_status":
return {
"summary": f"Order {tool_input['order_id']} status: {tool_result['status']}. "
f"Shipped via {tool_result.get('carrier', 'unknown')}, "
f"ETA {tool_result.get('estimated_delivery', 'unknown')}.",
"entities": [tool_input['order_id'], context.get('customer_id')],
"category": "order_status",
"ttl": "24h" # order status changes, so this memory has a short useful life
}
elif tool_name == "update_customer_preferences":
return {
"summary": f"Updated preferences for customer {tool_input['customer_id']}: "
f"{tool_input['preferences']}.",
"entities": [tool_input['customer_id']],
"category": "customer_preference",
"ttl": "permanent" # preferences are long-lived
}After extracting the meaningful outcome, persist it to your memory system with enough metadata for effective retrieval. The memory should include the outcome summary (what happened), the tool name (what was called), the entities involved (who or what was affected), the timestamp (when it happened), and optionally a confidence or TTL indicator (how long this information is likely to remain valid).
With Adaptive Recall, storing a tool outcome is a single API call through the store tool. The service automatically extracts entities from the summary text, builds knowledge graph connections to related memories, assigns initial confidence scores, and indexes the memory for cognitive retrieval. This means tool outcomes are immediately connected to the broader knowledge about the user, their projects, their preferences, and their history, without any additional integration work.
# Using Adaptive Recall's store tool
memory_store({
"content": "Checked order #A6789 for customer jane@example.com. "
"Status: shipped via FedEx, tracking 7891234, "
"estimated delivery May 15. Customer asked about this "
"because the tracking page showed no updates for 3 days.",
"metadata": {
"source": "tool_outcome",
"tool": "get_order_status",
"entities": ["order_A6789", "customer_jane"]
}
})Before the model makes a tool call (or as part of context assembly at the start of a conversation), query memory for past outcomes that are relevant to the current interaction. If the user asks about order #A6789 and you stored the outcome from yesterday's lookup, retrieving it can save a redundant API call and provide immediate context.
The retrieval strategy depends on what information is available at query time. If you know the specific entity (order ID, customer ID), query memory for outcomes involving that entity. If the user's question is more general, use semantic search on the question text to find relevant past outcomes. Adaptive Recall's cognitive scoring handles both cases: entity-based retrieval works through the knowledge graph (spreading activation from the entity to connected memories), and semantic retrieval works through vector similarity enhanced by recency and frequency weighting.
Inject retrieved tool outcomes into the model's context so it can learn from past interactions. If the model sees "Last time this customer asked about shipping, the issue was a FedEx delay and we offered a 10% discount code," it can proactively check for shipping issues and have the discount code ready without the user needing to explain the whole situation again.
Outcome history also helps the model avoid failed approaches. If memory contains "Attempted to process refund for this customer but the refund tool returned 'order not eligible, still in transit,'" the model knows not to attempt the same refund until the order status changes. Without this memory, the model would try the refund again, hit the same error, and waste the user's time.
Tool outcome memories have varying lifespans. An order status is current for hours or days. A customer preference is current for months. A product feature that was unavailable last week might be available now. Without lifecycle management, stale tool memories provide outdated information that the model presents as current fact.
Adaptive Recall's consolidation process handles lifecycle management automatically. Memories that are corroborated by newer tool outcomes receive confidence boosts and remain accessible. Memories that are contradicted by newer outcomes (the order that was "in transit" is now "delivered") are updated or superseded. Memories that are never accessed and have not been corroborated gradually fade through the decay mechanism, keeping the memory store focused on knowledge that is both current and useful.
For custom implementations, assign TTL values to tool outcome memories based on the expected validity period of each tool's data. Run a periodic job that checks memories against their TTL and either refreshes them (by re-calling the tool) or marks them as stale. Stale memories should still be retrievable but should include a staleness indicator so the model knows to verify before presenting the information as current.
What Not to Store
Avoid storing raw tool responses verbatim. A 200-line JSON response from an API call is not useful as a memory; a two-sentence summary of the meaningful outcome is. Avoid storing tool calls that returned no useful information (empty search results, "not found" responses) unless the absence of data is itself meaningful. Avoid storing highly ephemeral data (current time, real-time prices, live stock quotes) that will be stale within minutes. The goal is to build a curated knowledge base of tool outcomes, not a log of every API call the agent has ever made.
Give your agent memory that learns from every tool interaction. Adaptive Recall stores, scores, and retrieves tool outcomes using cognitive models that prioritize recent, relevant, and well-corroborated knowledge.
Get Started Free