You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been using herdr for a while now and have started integrating the Atomic agent into my workflow, it is a project which, I think, has great potential. It would be awesome if we could bring a full integration under herdr.
Atomic is a coding-agent CLI — a maintained fork of pi's coding agent with the same extension system, session format, and TUI, extended with built-in multi-stage workflow execution (DAG-driven runs that continue in the background while the chat session is idle), subagent orchestration, and cross-session coordination. Developed by @lavaman131
Atomic inside a Herdr pane is invisible to it today. Herdr falls back to screen scraping, which gets the worst case exactly wrong: a backgrounded workflow run can work for hours — or sit blocked on a human prompt — while the pane reads idle. The moment the user most needs to be told a pane is waiting on them is the moment the pane claims nothing is happening. (Related: #1419 approaches background-waiting misreads from the pane side; this solves it from the agent side for Atomic.)
Unlike the existing integrations, the reporter ships inside Atomic — no herdr integration install step, no file for Herdr to maintain. It speaks the pane socket protocol: working/idle/blocked for chat turns, blocked-with-label for every dialog or prompt that parks the agent on a human, and — beyond what existing integrations report — the lifecycle of background workflow runs. It reports as source: herdr:atomic, agent: atomic, uses monotonic seq, releases on quit, and stands down if Herdr's own file-based pi integration is loaded in the same agent directory, so a pane never has two writers.
Reading the Herdr source, semantic reports from an unrecognized source are stored and displayed, but pausing the scraping fallback and retaining the reported session reference are reserved for the recognized agents. So without recognition, Atomic's reports can be overridden by the scraper they replace, and its session identity is discarded.
requested change
Three additions to the recognized-agent lists — no protocol changes, no integration asset to ship:
Add atomic to the agent detection table (src/detect/mod.rs) so the pane's running process can anchor the reports. We tested against a live server and saw that full-lifecycle reports are (rightly) accepted only when the detected process matches the reported agent, so recognition needs this entry too — a good spoofing guard, incidentally.
Add the ("herdr:atomic", "atomic") pair to the full-lifecycle authority set (src/detect/mod.rs), alongside pi/omp/mastracode/opencode/kilo/kimi, so an accepted report pauses screen/process fallback for the pane.
Optionally, if you think it belongs: add the same pair to the official session sources (src/agent_resume.rs) so Herdr retains the reported session reference for restore — Atomic reports an absolute session path with id fallback, pi/omp-style. (Verified live: today the reference is accepted on the wire and discarded, while claude panes retain theirs.)
If you'd rather scope, name, or version this differently — including a status representation for builtin (fileless) reporters — we'll align the Atomic side with whatever you want. Happy to submit it as a PR under your supervision if invited; otherwise everything needed from Atomic's side will be shipped and documented for your own agents to build against.
why you want this
I have been using herdr for a while now and have started integrating the Atomic agent into my workflow, it is a project which, I think, has great potential. It would be awesome if we could bring a full integration under herdr.
Herdr is the runtime our Atomic sessions live on, and long-running background workflows are Atomic's normal mode — panes that read idle for hours while work runs (or worse, while a prompt waits on the user) undercut exactly what Herdr's semantic states, waits, notifications, and rollups are for.
Compatibility is additive both ways: older Atomic versions never report, so recognition goes unused; newer Atomic against older Herdr degrades to display-only semantic state. Atomic also honors PI_CODING_AGENT_DIR, so existing herdr integration install pi payloads keep working in an Atomic agent directory — the builtin defers to them.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
idea / problem
I have been using herdr for a while now and have started integrating the Atomic agent into my workflow, it is a project which, I think, has great potential. It would be awesome if we could bring a full integration under herdr.
Atomic is a coding-agent CLI — a maintained fork of pi's coding agent with the same extension system, session format, and TUI, extended with built-in multi-stage workflow execution (DAG-driven runs that continue in the background while the chat session is idle), subagent orchestration, and cross-session coordination. Developed by @lavaman131
Atomic inside a Herdr pane is invisible to it today. Herdr falls back to screen scraping, which gets the worst case exactly wrong: a backgrounded workflow run can work for hours — or sit blocked on a human prompt — while the pane reads idle. The moment the user most needs to be told a pane is waiting on them is the moment the pane claims nothing is happening. (Related: #1419 approaches background-waiting misreads from the pane side; this solves it from the agent side for Atomic.)
Unlike the existing integrations, the reporter ships inside Atomic — no
herdr integration installstep, no file for Herdr to maintain. It speaks the pane socket protocol:working/idle/blockedfor chat turns, blocked-with-label for every dialog or prompt that parks the agent on a human, and — beyond what existing integrations report — the lifecycle of background workflow runs. It reports assource: herdr:atomic,agent: atomic, uses monotonicseq, releases on quit, and stands down if Herdr's own file-based pi integration is loaded in the same agent directory, so a pane never has two writers.Reading the Herdr source, semantic reports from an unrecognized source are stored and displayed, but pausing the scraping fallback and retaining the reported session reference are reserved for the recognized agents. So without recognition, Atomic's reports can be overridden by the scraper they replace, and its session identity is discarded.
requested change
Three additions to the recognized-agent lists — no protocol changes, no integration asset to ship:
atomicto the agent detection table (src/detect/mod.rs) so the pane's running process can anchor the reports. We tested against a live server and saw that full-lifecycle reports are (rightly) accepted only when the detected process matches the reported agent, so recognition needs this entry too — a good spoofing guard, incidentally.("herdr:atomic", "atomic")pair to the full-lifecycle authority set (src/detect/mod.rs), alongside pi/omp/mastracode/opencode/kilo/kimi, so an accepted report pauses screen/process fallback for the pane.src/agent_resume.rs) so Herdr retains the reported session reference for restore — Atomic reports an absolute session path with id fallback, pi/omp-style. (Verified live: today the reference is accepted on the wire and discarded, whileclaudepanes retain theirs.)If you'd rather scope, name, or version this differently — including a status representation for builtin (fileless) reporters — we'll align the Atomic side with whatever you want. Happy to submit it as a PR under your supervision if invited; otherwise everything needed from Atomic's side will be shipped and documented for your own agents to build against.
why you want this
I have been using herdr for a while now and have started integrating the Atomic agent into my workflow, it is a project which, I think, has great potential. It would be awesome if we could bring a full integration under herdr.
Herdr is the runtime our Atomic sessions live on, and long-running background workflows are Atomic's normal mode — panes that read idle for hours while work runs (or worse, while a prompt waits on the user) undercut exactly what Herdr's semantic states, waits, notifications, and rollups are for.
Compatibility is additive both ways: older Atomic versions never report, so recognition goes unused; newer Atomic against older Herdr degrades to display-only semantic state. Atomic also honors
PI_CODING_AGENT_DIR, so existingherdr integration install pipayloads keep working in an Atomic agent directory — the builtin defers to them.All reactions