← Back to Foundation

20250711 UPDATED JIDO APPROACH

Documentation for 20250711_UPDATED_JIDO_APPROACH from the Foundation repository.

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:

  1. Jido passes the agent struct directly as the first parameter
  2. Foundation tries to access server_state.agent expecting a server state wrapper
  3. 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:

  1. JidoSystem.Agents.FoundationAgent - Base integration layer
  2. JidoSystem.Agents.TaskAgent - Task processing agent
  3. All Foundation agents that inherit from FoundationAgent
  4. 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

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

Phase 1: Immediate Fix (1-2 days)

  1. Update Foundation agent mount signatures to match new Jido interface
  2. Fix the agent vs server_state confusion in our codebase
  3. Verify all callback signatures align with new Jido expectations
  4. Run tests to ensure basic functionality restored

Phase 2: Complete Integration Update (3-5 days)

  1. Update all Foundation agents to use new signatures
  2. Review other callback methods that might have changed
  3. Update documentation to reflect new integration patterns
  4. Test comprehensive integration scenarios

Phase 3: Enhancement (1 week)

  1. Leverage new Jido features that the type system updates enable
  2. Optimize Foundation integration for the new architecture
  3. Add comprehensive test coverage for the integration
  4. Document migration guide for other teams

Files Requiring Updates

Primary Integration Files:

  • lib/jido_system/agents/foundation_agent.ex - Core integration layer
  • lib/jido_system/agents/task_agent.ex - Task processing agent
  • lib/jido_system/agents/coordinator_agent.ex - Coordination agent
  • lib/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

  1. Immediate: Fix the mount signature in FoundationAgent
  2. Short-term: Update all agent implementations and run tests
  3. Medium-term: Review all callback signatures for other potential mismatches
  4. 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.