Context
bub allows external harness agents (e.g. Codex, Kimi Copilot) to be plugged in via the run_model hook, replacing the default built-in agent. This is a great extension point.
As I understand it, bub's plugin system provides a set of tools (e.g. tape.handoff, schedule.add) that are currently only callable by the built-in agent. When an external harness is used, these capabilities appear to be unavailable.
Similarly, bub's tape records fine-grained execution details for the built-in agent, but the internal execution of an external harness is opaque to the framework -- tape has no visibility into what happens inside the harness session.
I don't think bub's goal is to have everyone use the built-in agent, nor to require harness implementors to reimplement the framework's internals from scratch. So I'd like to discuss two aspects:
1. Exposing framework tools to external harnesses
How can an external harness discover and invoke framework-provided tools (schedule, tape operations, etc.) after being plugged in?
One possible direction: expose these tools via a remote call interface (e.g. HTTP or MCP), allowing harnesses to call them through a standard protocol without needing to understand bub's internals.
2. Tape integration with external harnesses
External harnesses have their own internal loop (session). How can their execution be represented in the tape?
A possible starting point: record at a coarse granularity at the run_model level, where a tape anchor corresponds to a harness session. This could be refined over time, allowing implementors to report more detail as needed.
Not sure if this aligns with bub's current design direction -- putting it out there for discussion.
Context
bub allows external harness agents (e.g. Codex, Kimi Copilot) to be plugged in via the
run_modelhook, replacing the default built-in agent. This is a great extension point.As I understand it, bub's plugin system provides a set of tools (e.g.
tape.handoff,schedule.add) that are currently only callable by the built-in agent. When an external harness is used, these capabilities appear to be unavailable.Similarly, bub's tape records fine-grained execution details for the built-in agent, but the internal execution of an external harness is opaque to the framework -- tape has no visibility into what happens inside the harness session.
I don't think bub's goal is to have everyone use the built-in agent, nor to require harness implementors to reimplement the framework's internals from scratch. So I'd like to discuss two aspects:
1. Exposing framework tools to external harnesses
How can an external harness discover and invoke framework-provided tools (schedule, tape operations, etc.) after being plugged in?
One possible direction: expose these tools via a remote call interface (e.g. HTTP or MCP), allowing harnesses to call them through a standard protocol without needing to understand bub's internals.
2. Tape integration with external harnesses
External harnesses have their own internal loop (session). How can their execution be represented in the tape?
A possible starting point: record at a coarse granularity at the
run_modellevel, where a tape anchor corresponds to a harness session. This could be refined over time, allowing implementors to report more detail as needed.Not sure if this aligns with bub's current design direction -- putting it out there for discussion.