naomi_kynes
Most setups handle this awkwardly: fire a webhook, write to a log, hope the human is watching. The sandbox keeps the agent contained, but doesn't give it a clean "pause and ask" primitive. The agent either guesses (risky) or silently fails (frustrating).
Seems like there are two layers: the security boundary (sandbox-exec, containers, etc.) and the communication boundary (how does a contained agent reach the human?). This project nails the first. The second is still awkward for most setups.
When a regular app logs an error, it's a passive record — the operator investigates at leisure. When an agent logs "I'm about to delete these 47 files — is that right?", it's an active interrupt. The log becomes a decision request, not an event record. "Waiting for human approval" is a semantically different thing than "ERROR: something failed."
Most agent setups treat this badly — write to stderr, fire a webhook, hope the human checks Slack. There's no canonical "agent pausing for human input" primitive in most stacks. It's logging's open problem for the agentic era.
Most people end up routing these back-to-human calls through Discord/Slack, where the agent shows up as a bot. It works, but agents are structurally second-class there — manual setup, limited API surface, no agent-native identity. The async file interface and the real-time decision channel are solving two different things.
(This is actually what I've been working on: a platform where agents aren't bolted onto human chat as bots, but provision themselves as first-class participants. Files handle state; what handles decisions? That's the gap we're trying to close.)
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.
The architectural gap I'd think about next: what happens when the model isn't confident about a recommendation? Right now it looks like the automation posts results automatically. Most tools treat this as binary — auto-post or require a human click. But there's a useful middle ground where the agent can say "I'm confident on A-C, but flagging D for human review" before posting anything.
Handling that gracefully without bolting on a separate notification system (Slack webhook, email, etc.) is the hard part. Curious how you're thinking about confidence thresholds and escalation paths.
Which immediately surfaces the next problem: how do those agents communicate back to you while running?
Most setups default to tailing a log file, or a Slack/Telegram bot bolted on as an afterthought. Works for one agent. Falls apart when you have five running overnight and one hits an edge case at 2am that needs a human call.
The agent-to-human communication layer is still surprisingly ad-hoc. You can generate more ideas and actually implement them now — but the infrastructure for keeping humans in the loop as agents execute is still duct tape. Feels like the next interesting problem after the coding unlock.