Can Kaimon ping claude? #30

Closed
opened 2026-04-22 16:50:56 -07:00 by haakon-e · 4 comments
haakon-e commented 2026-04-22 16:50:56 -07:00 (Migrated from github.com)

I'm experimenting with having claude help debug some heavy simulations of mine.

These simulations can take 5-10 minutes to set up (initialize all the relevant arrays), then 5 mins to many hours to run.

One thing I've found Claude not particularly good with, is pinging kaimon if the latest ex completed. If I don't watch closely, it may "forget" to do it altogether if the first N pings didn't return.

Questions:

  • Is there a way for Kaimon to send a ping to the agent?
  • Is there a way for Kaimon to send a message ("as if it's me") to the agent?
    • by this I mean having Kaimon do the equivalent of writing a message to the LM interface to say that it should check the eval.
  • Is there a way to inspect stdout as messages are printed? During a simulation run, I have regular @info statements with progress information. I see this in REPL, but it seems like the agent can't see the output to stdout until ex completed.

Some alternative workarounds, where these tools seems to have better support, include:

  • checking if a file is updated
    • I could get Kaimon to write to a file when the previous command finishes?

Any thoughts on this?

I'm experimenting with having claude help debug some heavy simulations of mine. These simulations can take 5-10 minutes to set up (initialize all the relevant arrays), then 5 mins to many hours to run. One thing I've found Claude not particularly good with, is pinging kaimon if the latest `ex` completed. If I don't watch closely, it may "forget" to do it altogether if the first N pings didn't return. Questions: - Is there a way for Kaimon to send a ping to the agent? - Is there a way for Kaimon to send a message ("as if it's me") to the agent? - by this I mean having Kaimon do the equivalent of writing a message to the LM interface to say that it should check the eval. - Is there a way to inspect `stdout` as messages are printed? During a simulation run, I have regular `@info` statements with progress information. I see this in REPL, but it seems like the agent can't see the output to `stdout` until `ex` completed. Some alternative workarounds, where these tools seems to have better support, include: - checking if a file is updated - I could get Kaimon to write to a file when the previous command finishes? Any thoughts on this?
kahliburke commented 2026-06-08 23:19:30 -07:00 (Migrated from github.com)

@haakon-e In general there has not been a method for that reverse communication. However, I'm working on some new functionality in 2.0.0 which will address this. Also recently there has been work on an Agent Control Protocol ACP as a sibling to MCP which addresses these use cases.

@haakon-e In general there has not been a method for that reverse communication. However, I'm working on some new functionality in 2.0.0 which will address this. Also recently there has been work on an Agent Control Protocol ACP as a sibling to MCP which addresses these use cases.
haakon-e commented 2026-06-09 09:13:42 -07:00 (Migrated from github.com)

Thank you! I'll hold my breath for v2!

Thank you! I'll hold my breath for v2!
kahliburke commented 2026-06-16 04:36:43 -07:00 (Migrated from github.com)

2.0 adds this by inverting the relationship: Kaimon can spawn and own an agent session and drive it programmatically.

  • agent_open — spawn a headless claude in a directory; returns an agent_id. Events stream on the gate bus channel agent:<id>.
  • agent_send / agent_run — send it a user turn (it arrives as if you typed it). agent_run blocks and returns the assistant text; agent_send is fire-and-forget.
  • agent_status / agent_list / agent_interrupt / agent_close — lifecycle.

For your long-sim workflow: open a Kaimon-owned agent in the project, and from your Julia code, when the computation finishes, call agent_send/agent_run to message the agent ("sim done, here are the results, continue"). That is Kaimon messaging the agent as if it were you — your second question.

The one thing this doesn't do is wake an external Claude Code/Desktop session that's driving Kaimon as an MCP client — MCP has no unsolicited server→client wake. (During a running ex that client does get progress notifications on the open stream, but once it stops waiting there's no way to ping it.) The Kaimon-owned agent above is the supported way to get the "notify me when it's done" loop.

More broadly, the agent layer is built on the ACP (Agent Client Protocol) data model, so it's vendor-neutral by design — every backend normalizes to it. A real ACP-client backend (any ACP-compliant agent, not just claude) is the natural next step; the event model is already in place, it just needs the wire transport.

See the AI Agent Sessions docs (docs/src/agents.md). Shipping in 2.0.

2.0 adds this by inverting the relationship: Kaimon can spawn and own an agent session and drive it programmatically. - `agent_open` — spawn a headless `claude` in a directory; returns an `agent_id`. Events stream on the gate bus channel `agent:<id>`. - `agent_send` / `agent_run` — send it a user turn (it arrives as if you typed it). `agent_run` blocks and returns the assistant text; `agent_send` is fire-and-forget. - `agent_status` / `agent_list` / `agent_interrupt` / `agent_close` — lifecycle. For your long-sim workflow: open a Kaimon-owned agent in the project, and from your Julia code, when the computation finishes, call `agent_send`/`agent_run` to message the agent ("sim done, here are the results, continue"). That is Kaimon messaging the agent as if it were you — your second question. The one thing this doesn't do is wake an *external* Claude Code/Desktop session that's driving Kaimon as an MCP client — MCP has no unsolicited server→client wake. (During a running `ex` that client does get progress notifications on the open stream, but once it stops waiting there's no way to ping it.) The Kaimon-owned agent above is the supported way to get the "notify me when it's done" loop. More broadly, the agent layer is built on the ACP (Agent Client Protocol) data model, so it's vendor-neutral by design — every backend normalizes to it. A real ACP-client backend (any ACP-compliant agent, not just `claude`) is the natural next step; the event model is already in place, it just needs the wire transport. See the AI Agent Sessions docs (`docs/src/agents.md`). Shipping in 2.0.
kahliburke commented 2026-07-08 22:15:18 -07:00 (Migrated from github.com)

@haakon-e It's out! Closing this issue.

@haakon-e It's out! Closing this issue.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kahliburke/Kaimon.jl#30
No description provided.