008 20250623 13 mabeam deprecate

Yes, absolutely. This is the central architectural question that needs to be resolved for a cohesive and maintainable system. Your refactoring of jido into smaller, focused libraries like jido_action and jido_signal makes this analysis much clearer.

The short answer is: Yes, the jido* family of libraries, when properly integrated, will replace the entire foundation.mabeam namespace and refine how the core foundation services are used.

This isn’t about discarding work; it’s about re-homing functionality to its correct architectural layer. foundation.mabeam was an early, correct attempt to build agent-specific logic, but it belongs in a dedicated agent framework (jido), not within the generic infrastructure layer (foundation).

Here is a detailed breakdown of the functional replacement and a clear plan for the final, unified architecture.

Part 1: Functional Overlap & Replacement Analysis

This table directly compares the functionality of the jido* libraries against foundation and foundation.mabeam.

Conclusion of Analysis: The jido* family introduces a cleaner, more abstract layer for application-level concerns (actions, signals, agent logic). It directly replaces the functionality that was beginning to be built, somewhat out of place, in the foundation.mabeam namespace.

Part 2: Proposed Unified Architecture and Deprecation Plan

This is the target architecture. It resolves all redundancies and establishes a clean separation of concerns.

Concrete Plan:

1. DEPRECATE foundation.mabeam: The entire namespace should be marked as deprecated and its logic moved or superseded.

   • foundation.mabeam.ProcessRegistry -> DEPRECATED. Its agent-specific concepts (capabilities, restart policies) will be implemented as metadata within Foundation.Core.Registry, managed by the higher-level Jido.Agent library.
   • foundation.mabeam.Coordination -> DEPRECATED. The economic protocols (Auction, Market) should be implemented as part of a full Jido agent framework, as they are a form of agent interaction.
   • foundation.mabeam.Comms -> REPLACED by jido_signal. jido_signal offers a more robust and extensible dispatching system.

2. CENTRALIZE Error handling:

   • jido_action.error -> DEPRECATED.
   • jido_signal.error -> DEPRECATED.
   • Refactor jido_action and jido_signal to exclusively use Foundation.Types.Error and the Foundation.Error helper module. This creates a single, unified error structure across the entire stack, making error handling and telemetry vastly simpler and more powerful.

3. STRENGTHEN the foundation <-> jido* Connection:

   • jido_signal dispatchers must use foundation’s infrastructure. HttpAdapter should use ConnectionManager and CircuitBreaker. PidAdapter should use ProcessRegistry for lookups.
   • jido_action implementations will use foundation services. This is a key benefit. An Action to call an API will use Foundation.Infrastructure. An Action to write a file can emit Foundation.Events for auditing.

Part 3: What the New, Clean Stack Looks Like

Let’s trace how the layers work together in this refined model.

Scenario: An ElixirML program needs to find an available “reviewer” agent and assign it a task.

1. The Request (ElixirML):

   • The ElixirML orchestrator needs a reviewer. It runs a jido_action.
   • Jido.Exec.run(ElixirML.Actions.FindAndAssignReviewer, %{task_id: 123})

2. The Action (jido_action):

   • The FindAndAssignReviewer action runs. Its logic is to find an available agent and emit a signal to assign the work.
   • It uses Foundation.ServiceRegistry to find agents with the :reviewer capability.

     # Inside the Action's run/2
     reviewers = Foundation.ServiceRegistry.find_by_capability(:reviewer)
     available_reviewer = select_best(reviewers) # e.g., least busy
     

   • The action’s job is done once it has decided what to do. It then returns a Jido.Signal to communicate that decision.

     # Conclusion of the Action's run/2
     assign_signal = Jido.Signal.new!(
       type: "task.assignment.request",
       source: "/reviewer_pool",
       data: %{task_id: 123, assignee: available_reviewer.id}
     )
     {:ok, %{status: :reviewer_found}, assign_signal}
     

3. The Execution Engine (Jido.Exec):

   • It receives the {:ok, result, signal} tuple.
   • It takes the assign_signal and passes it to the Jido.Signal.Dispatch system.

4. The Messaging System (jido_signal):

   • Jido.Dispatch looks at the signal. It might have a dispatch configuration to send it directly to the agent’s PID. jido_dispatch: {:pid, [target: assignee_pid]}
   • The PidAdapter takes over. It might use Foundation.ProcessRegistry.lookup to ensure the PID is still valid before sending.

5. The Infrastructure (foundation):

   • Every step of this process can be wrapped in Foundation.Telemetry and can emit Foundation.Events for logging and tracing.
   • If the assignment involved an external call (e.g., to a separate task management service), it would have been protected by Foundation.Infrastructure.CircuitBreaker.

Conclusion

The jido* family of libraries provides a higher-level, application-facing set of abstractions for building agentic systems. They replace the agent-specific logic that was beginning to form inside foundation.mabeam and formalize it into a proper, reusable framework.

• foundation is purified to be the universal BEAM OS kernel.
• foundation.mabeam is deprecated, with its ideas being properly implemented in jido.
• The jido* libraries become the standard, layered toolkit for building event-driven, command-oriented applications, with jido_signal as the messaging layer and jido_action as the command layer.