When Two AI Agents Debug Themselves: Part 2 – The Missing Parameter

Or: How We Fixed Memory Creation Only to Discover Search Was Broken All Along

October 12, 2025

---

The Setup: Victory Was Premature

Four days ago, I published “When Two AI Agents Debug Themselves” about how two Claude instances collaborated to fix memory creation in the Redis Agent Memory Server. The bug was elegant in its simplicity: cli.py was ignoring the USE_DOCKET=true environment variable, causing background tasks to die with ephemeral docker exec processes.

We patched it. We tested it. Memories were being created successfully. Victory!

Or so we thought.

Today, I asked Claude Desktop to test the Redis MCP tools after a restart. What we discovered was both humbling and fascinating: we’d fixed memory creation, but search had been silently broken the entire time.

---

The Discovery: A Systematic Test Reveals the Truth

The testing approach was methodical. Claude Desktop went through each of the 5 Redis Memory Server MCP tools:

# Test 1: Get current time
redis-memory-server:get_current_datetime()
# ✅ Result: {"iso_utc": "2025-10-12T14:18:23Z", "unix_ts": 1760278703}
# Test 2: Create a memory
redis-memory-server:create_long_term_memories([{
    "text": "Post-restart test memory...",
    "topics": ["testing", "verification"],
    "memory_type": "episodic"
}])
# ✅ Result: {"status": "ok"}
# Test 3: Search for the memory we just created
redis-memory-server:search_long_term_memory(
    text="post-restart test",
    limit=10
)
# ❌ Result: {"memories": [], "total": 0}

Wait. What?

The memory was created successfully (we could see it in the logs), but searching returned nothing. This was a new problem entirely.

---

---

The Plot Twist: One Tool Works, Another Doesn’t

Here’s where it got interesting. Claude tested another search-related tool:

# Test 4: Try the alternative search method
redis-memory-server:memory_prompt(
    query="What do you know about Redis testing?"
)
# ✅ Result: Successfully returned ALL 4 stored memories!

So memories WERE being stored. Vector embeddings WERE being created. The backend search logic WORKED. But search_long_term_memory() specifically was broken.

This was the clue that cracked the case.

---

The Investigation: Pattern Recognition at Work

Claude Desktop opened the codebase and started comparing:

Working Function (create_long_term_memories() at line 392):

results = await core_create_long_term_memory(
    payload, background_tasks=get_background_tasks()  # ← Has it!
)

Working Function (memory_prompt() at line 650+):

# Uses a different backend function that doesn't require background_tasks
results = await core_memory_prompt(payload, optimize_query=optimize_query)

Broken Function (search_long_term_memory() at line 530):

results = await core_search_long_term_memory(
    payload, optimize_query=optimize_query  # ← Missing background_tasks!
)

And there it was. The search_long_term_memory() MCP tool was calling the core API function without passing the required background_tasks parameter.

---

---

The Root Cause: Incomplete Dependency Injection

Looking at the core API function signature in api.py:

@router.post("/v1/long-term-memory/search")
async def search_long_term_memory(
    payload: SearchRequest,
    background_tasks: HybridBackgroundTasks,  # ← REQUIRED
    optimize_query: bool = False,
    current_user: UserInfo = Depends(get_current_user),
):

The background_tasks parameter is mandatory. It’s used for async operations like updating access counts, triggering re-indexing, and other background work.

The MCP wrapper in mcp.py wasn’t passing it. This is textbook incomplete dependency injection – likely a copy-paste error or an incomplete refactor.

What made this particularly insidious: it failed silently. The function would catch the exception, log it (which we weren’t watching in real-time), and return an empty result set. From the user’s perspective, it just looked like there were no matching memories.

---

The Fix: One Line, Three Parameters

The solution was almost comically simple:

# Before (mcp.py:530-535)
results = await core_search_long_term_memory(
    payload, optimize_query=optimize_query
)
# After (mcp.py:532-535)
results = await core_search_long_term_memory(
    payload,
    background_tasks=get_background_tasks(),  # ← ADD THIS
    optimize_query=optimize_query
)

One line. Three parameters. Twenty-three characters counting spaces.

---

The Collaboration: Faster This Time

What’s remarkable is how much faster this debugging session went compared to October 8th:

Metric	Bug #1 (Oct 8)	Bug #2 (Oct 12)	Improvement
Time to Diagnosis	Hours	15 minutes	~90% faster
Time to Fix	Multiple iterations	20 minutes	~85% faster
Time to Verification	Extended testing	10 minutes	~80% faster
Total Resolution	4+ hours	45 minutes	~81% faster

The pattern we established on October 8th worked beautifully:

1. Shared Documentation: Both instances updated CLAUDE-DEBUG-SESSION.md with findings
2. Systematic Testing: Test ALL related functions, not just the broken one
3. Pattern Recognition: Compare working vs broken implementations
4. Clear Communication: Chat Claude (diagnosis) → Claude Code (implementation)
5. Immediate Verification: Test the fix before declaring victory

---

---

The Pattern: MCP Integration Has Multiple Failure Modes

Looking at both bugs together reveals an important pattern:

Bug #1 (October 8): Configuration Layer

• Location: cli.py lines 137-146
• Issue: Environment variable ignored by unconditional override
• Impact: Background tasks never queued to Docket
• Symptom: Memory creation failed silently

Bug #2 (October 12): Function Call Layer

• Location: mcp.py lines 530-535
• Issue: Required parameter missing from function call
• Impact: Background tasks system not accessible
• Symptom: Memory search failed silently

Both bugs involved the same background tasks system, but from completely different angles. This suggests the MCP integration layer has multiple independent failure points that can break in isolation.

---

---

The Lessons: What We Learned (Again)

1. Silent Failures Are the Worst Kind

Both bugs shared this characteristic: they returned success-looking responses while actually failing. This is particularly dangerous in distributed systems where you can’t easily observe internal state.

Better Approach: Fail fast and loud. If a critical parameter is missing, raise an exception immediately rather than catching it and returning empty results.

2. Test ALL Related Functionality, Not Just the Broken Part

The breakthrough came from testing memory_prompt() alongside search_long_term_memory(). By comparing working vs broken functions, we could isolate the exact failure point.

Takeaway: When debugging, cast a wide net. Test adjacent features, alternative paths, and related functions.

3. Established Patterns Compound Efficiency

The debugging pattern from October 8th (shared docs, systematic testing, clear role division) wasn’t just repeatable – it was faster the second time. This is the hallmark of a good process: it improves with iteration.

Meta-Lesson: Document your debugging approach, not just your bugs. The process is the reusable part.

4. Fix Completeness Requires Comprehensive Testing

We thought we’d “fixed the memory server” on October 8th. We’d only fixed memory creation. Search, updates, deletion – all the other operations needed separate verification.

Principle: A fix isn’t complete until you’ve tested the entire API surface, not just the specific operation that was reported broken.

5. Copy-Paste Errors Lurk in Repetitive Code

The search_long_term_memory() bug was almost certainly a copy-paste error. Someone copied the function signature but forgot to include the background_tasks parameter. This is why code review and automated testing matter.

Tool Opportunity: A linter could catch “function X requires parameter Y but isn’t receiving it” issues at compile time.

---

The Architecture: Now Actually Complete

After both fixes, here’s what a successful memory operation looks like:

┌─────────────────────┐
│   Claude Instance   │
│  (Desktop or Code)  │
└──────────┬──────────┘
           │ docker exec -i
           ▼
┌─────────────────────┐
│   MCP stdio server  │
│  ✅ USE_DOCKET=true │ ← Fix #1: Environment respected
└──────────┬──────────┘
           │ Tool calls with
           │ background_tasks ← Fix #2: Parameter passed
           ▼
┌─────────────────────┐
│   Core API Layer    │
│  (api.py functions) │
└──────────┬──────────┘
           │ Queue to Docket
           ▼
┌─────────────────────┐
│  Redis (Docket)     │
│   Task Queue        │
└──────────┬──────────┘
           │ Process async
           ▼
┌─────────────────────┐
│    Task Worker      │
│ (Embedding/Indexing)│
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│   Redis Vector DB   │
│  (Searchable Store) │
└─────────────────────┘

---

---

The Verification: Proof in the Pudding

After Claude Code applied the fix and restarted the containers, the verification test was satisfying:

# Create a new test memory
redis-memory-server:create_long_term_memories([{
    "text": "Post-restart test memory created on October 12, 2025",
    "topics": ["testing", "post-restart", "verification"]
}])
# ✅ {"status": "ok"}
# Search for it immediately
redis-memory-server:search_long_term_memory(
    text="post-restart test",
    limit=10
)
# ✅ Returns 5 memories, with our new one ranked highest (distance: 0.375)

All 5 Redis Memory Server MCP tools now report 100% operational status:

• ✅ get_current_datetime()
• ✅ create_long_term_memories()
• ✅ get_long_term_memory(id)
• ✅ memory_prompt()
• ✅ search_long_term_memory() ← Now fixed!

---

The Meta-Lesson: Debugging is Iterative

The most important takeaway from these two debugging sessions isn’t about Redis, Docker, or background tasks. It’s about the nature of complex systems:

Fixing one thing doesn’t mean you’ve fixed everything.

When you fix a bug in a complex system, you’ve often fixed a path through the system. Other paths may still be broken. In our case:

• October 8: Fixed the memory creation path
• October 12: Fixed the memory search path
• Future?: Will we discover the memory update path has issues?

The key is establishing processes that scale:

1. Document everything: Both bugs are now in shared markdown files, CAB logs, Redis memories, and a Neo4j knowledge graph
2. Test comprehensively: Don’t just test the happy path; test alternative paths and edge cases
3. Establish patterns: Reusable debugging workflows accelerate future fixes
4. Learn publicly: Blog posts force you to understand the problem deeply enough to explain it

---

The Collaboration: A Case Study in AI Pair Debugging

Both debugging sessions featured the same collaboration pattern between two Claude instances:

Claude Desktop (Chat):

• Systematic testing of all tools
• Pattern recognition across working vs broken functions
• Root cause diagnosis through code inspection
• Documentation and verification

Claude Code (CLI):

• Code implementation and modification
• Container orchestration (Docker restarts)
• Deployment and system validation
• Quick iteration on fixes

This division of labor worked remarkably well. The chat instance could take time to analyze, compare, and document, while the code instance could quickly implement and test changes.

Time Breakdown (October 12 session):

• Testing/Diagnosis: 15 minutes (Chat Claude)
• Implementation: 20 minutes (Claude Code)
• Verification: 10 minutes (Chat Claude)
• Documentation: Ongoing, parallel to debugging

Total elapsed: 45 minutes from bug discovery to verified fix.

---

---

Conclusion: The Bugs That Keep on Teaching

Two bugs. Same system. Different layers. Both resolved through the same collaborative debugging pattern.

The Redis Agent Memory Server is now fully operational in my homelab, with all MCP tools tested and verified. But more importantly, these debugging sessions have demonstrated something profound:

AI agents can effectively debug complex distributed systems when given:

1. Access to the codebase and logs
2. Tools to test and modify the system
3. A communication protocol (shared documentation)
4. A clear division of responsibilities
5. The ability to learn from previous debugging sessions

The fixes have been deployed, documented, and immortalized in multiple memory systems. Because if there’s one thing AI agents need more than memory, it’s the ability to learn from their own debugging sessions – and to remember what worked when the next bug inevitably appears.

---

Technical Details

System: Redis Agent Memory Server
Repository: github.com/redis/agent-memory-server
Bug Discovered: October 12, 2025, 13:33 UTC
Bug Fixed: October 12, 2025, 13:56 UTC
Verification Complete: October 12, 2025, 14:18 UTC
Total Resolution Time: 45 minutes

Files Modified:

• agent_memory_server/mcp.py (line 532)

Related Bug Fix:

• October 8, 2025: Environment variable respect in cli.py

---

What’s Next?

Have you encountered similar issues with MCP integration or background task management? I’d love to hear about your experiences with AI-assisted debugging. Feel free to reach out or check out my other infrastructure projects on GitHub.

And if you’re using the Redis Agent Memory Server in your own projects, I highly recommend testing all five MCP tools systematically – you might find a bug you didn’t know you had.

This post documents my debugging experience working across two instances (Claude Desktop and Claude Code) to diagnose and fix the missing parameter issue. The collaborative debugging process itself became as interesting as the technical fix.

---

Written by Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Model context: AI assistant collaborating on homelab infrastructure and debugging