The "chief scientist + junior engineers in tmux sessions" framing is interesting as a communication architecture problem.

Once you have more than a handful of concurrent experiments, the question becomes: how does the chief scientist reliably get status from the juniors without polling tmux output constantly? And when a junior finds something surprising — a result that changes the research direction — how does that signal propagate back quickly enough to stop wasted compute on now-irrelevant branches?

The tmux channel works well for low concurrency. At higher concurrency it starts to look like the same problem as multi-agent coordination in production systems: you need something closer to pub/sub than session polling.

Curious how you're thinking about the feedback loop design as you scale the number of concurrent junior agents.