Updated Jido Integration Analysis - July 11, 2025
Executive Summary
The Foundation’s integration with Jido is broken due to fundamental signature mismatches between the updated Jido type system and our Foundation integration layer. The errors indicate that the new Jido architecture has changed the callback function signatures, but our Foundation agents are still using the old interface.
Root Cause Analysis
1. Mount Callback Signature Mismatch
Location: /agentjido/jido/lib/jido/agent/server_callback.ex:27
Current Jido Code:
# Line 27 in server_callback.ex
case agent.__struct__.mount(agent, []) do
Our Foundation Integration:
# lib/jido_system/agents/foundation_agent.ex:69
@impl true
def mount(server_state, opts) do
Logger.info("FoundationAgent mount called for agent #{server_state.agent.id}")
agent = server_state.agent
# ... rest of implementation
end
The Problem: Jido is calling mount(agent, [])
but our Foundation agents expect mount(server_state, opts)
where server_state
is a struct containing the agent.
2. KeyError: :agent
The error %KeyError{key: :agent, term: %JidoSystem.Agents.TaskAgent{...}}
occurs because:
- Jido passes the agent struct directly as the first parameter
- Foundation tries to access
server_state.agent
expecting a server state wrapper - The agent struct itself doesn’t have an
:agent
key, causing the KeyError
New Jido Type System Changes
Based on the code analysis, the new Jido system has evolved:
Before (What Foundation Expects):
# Mount receives server_state containing agent
def mount(%ServerState{agent: agent} = server_state, opts) do
# Work with server_state.agent
end
After (What Jido Now Calls):
# Mount receives agent directly
def mount(agent, opts) do
# Work with agent directly
end
Impact Assessment
Affected Components:
- JidoSystem.Agents.FoundationAgent - Base integration layer
- JidoSystem.Agents.TaskAgent - Task processing agent
- All Foundation agents that inherit from FoundationAgent
- 32 failing tests across task agent functionality
Error Pattern:
All errors follow the same pattern:
** (EXIT from #PID<...>) {:mount_failed, %KeyError{key: :agent, term: %AgentStruct{...}}}
Technical Analysis
1. Jido Server Architecture Evolution
The Jido team has refactored their server architecture:
- Agent callbacks now receive the agent directly instead of wrapped server state
- Server state management is handled internally by Jido
- Callback signatures have been simplified
2. Foundation Integration Layer
Our integration was built assuming:
- Agents would receive
server_state
wrapper structs - We could access
server_state.agent
to get the actual agent - Server state would be mutable through callbacks
3. Compatibility Break
This is a major breaking change that requires updating our integration approach.
Solution Strategy
Option A: Update Foundation to Match New Jido Signatures (Recommended)
Update our Foundation integration to work with the new Jido callback signatures:
# OLD - Foundation expects server_state
def mount(server_state, opts) do
agent = server_state.agent
# ...
end
# NEW - Match Jido's direct agent passing
def mount(agent, opts) do
# Work directly with agent
# ...
end
Pros:
- ✅ Aligns with Jido’s evolution
- ✅ Simpler callback interface
- ✅ Future-proof against Jido changes
Cons:
- ❌ Requires updating all Foundation agents
- ❌ May lose some server state access
Option B: Create Adapter Layer
Create a compatibility layer that translates between interfaces:
defmacro __using__(opts) do
quote do
# Override mount to handle both signatures
def mount(agent_or_state, opts) do
agent = case agent_or_state do
%{agent: agent} -> agent # Old server_state format
agent -> agent # New direct agent format
end
foundation_mount(agent, opts)
end
# Foundation agents implement this instead
def foundation_mount(agent, opts) do
# Foundation-specific logic here
end
end
end
Pros:
- ✅ Maintains backward compatibility
- ✅ Less immediate refactoring needed
Cons:
- ❌ Technical debt and complexity
- ❌ May break again with future Jido changes
Option C: Fork/Pin Jido Version
Pin to a compatible Jido version until we can properly update:
Pros:
- ✅ Immediate stability
- ✅ No urgent refactoring needed
Cons:
- ❌ Misses Jido improvements and fixes
- ❌ Creates long-term technical debt
- ❌ May have security vulnerabilities
Recommended Action Plan
Phase 1: Immediate Fix (1-2 days)
- Update Foundation agent mount signatures to match new Jido interface
- Fix the agent vs server_state confusion in our codebase
- Verify all callback signatures align with new Jido expectations
- Run tests to ensure basic functionality restored
Phase 2: Complete Integration Update (3-5 days)
- Update all Foundation agents to use new signatures
- Review other callback methods that might have changed
- Update documentation to reflect new integration patterns
- Test comprehensive integration scenarios
Phase 3: Enhancement (1 week)
- Leverage new Jido features that the type system updates enable
- Optimize Foundation integration for the new architecture
- Add comprehensive test coverage for the integration
- Document migration guide for other teams
Files Requiring Updates
Primary Integration Files:
lib/jido_system/agents/foundation_agent.ex
- Core integration layerlib/jido_system/agents/task_agent.ex
- Task processing agentlib/jido_system/agents/coordinator_agent.ex
- Coordination agentlib/jido_system/agents/monitor_agent.ex
- Monitoring agent
Test Files:
test/jido_system/agents/foundation_agent_test.exs
test/jido_system/agents/task_agent_test.exs
- All integration tests that use Foundation agents
Supporting Files:
- Any other Foundation services that interact with agent mounting
- Documentation and examples
Code Fix Preview
Here’s what the immediate fix would look like:
# lib/jido_system/agents/foundation_agent.ex
defmacro __using__(opts) do
quote location: :keep do
use Jido.Agent, unquote(opts)
# OLD SIGNATURE - BROKEN
# @impl true
# def mount(server_state, opts) do
# agent = server_state.agent
# NEW SIGNATURE - FIXED
@impl true
def mount(agent, opts) do
Logger.info("FoundationAgent mount called for agent #{agent.id}")
# Work directly with agent instead of server_state.agent
capabilities = get_default_capabilities(agent.__struct__)
# ... rest of implementation remains mostly the same
# Just replace server_state.agent with agent
end
end
end
Risk Assessment
High Risk ⚠️
- All Foundation agents are currently broken - production impact
- 32 failing tests indicate widespread integration issues
- May be other callback signature changes we haven’t discovered yet
Medium Risk ⚠️
- Breaking changes might continue as Jido evolves
- Documentation gap between Jido changes and our integration
- Potential performance implications of new architecture
Low Risk ✅
- Fix appears straightforward - mainly signature updates
- Core Foundation infrastructure is independent of Jido agent callbacks
- Test coverage will catch regressions quickly
Next Steps
- Immediate: Fix the mount signature in FoundationAgent
- Short-term: Update all agent implementations and run tests
- Medium-term: Review all callback signatures for other potential mismatches
- Long-term: Consider closer collaboration with Jido team on future changes
Conclusion
This is a breaking change compatibility issue that requires updating our Foundation integration to match Jido’s evolved callback interface. The fix is straightforward but requires careful attention to all callback signatures. We should prioritize this as high urgency since it affects all Foundation agent functionality.
The root cause is that Jido simplified their callback interface by passing agents directly instead of wrapped server state, but our Foundation integration still expects the old wrapper format. This is a common issue when integrating with rapidly evolving libraries.
Recommendation: Fix immediately with Option A (update signatures) and add integration tests to catch future compatibility breaks early.