Clojurians Log v2

Interesting! Will definitely have a look later 👍 .Did you consider offering non-mcp (just some cli + skill) flavor? Or it wouldn't make sense here and mcp is the only legit way?

Different trade-offs, MCP offers some things that are good for the use case. To give a few examples: • MCP Tasks (as of June this year): perfect shape for this. They are built for expressing long-running things, and expose exactly the client-side API that I need for this, including a TaskStop verb exposed to the agent. I don’t have to teach this to the agent, the harness already contains the right stuff. • Mangling: even the smartest agents occasionally would go “whops, I forgot to escape the…, so zsh swallowed…”, etc. I don’t want to see that anymore. • When I update the lib, I don’t have to tell everyone in our org to “please git pull the latest skills file, the API has changed slightly”. MCP negotiates this automatically (mid-convo, if needed). But overall, by using MCP, there’s a lot of things that the server plus the harness negotiates that I would otherwise have to write as text and hope that the agent understands/does correctly.

Interesting! I'm searching for a comparative description of how using remontoire feels different to the other known ways of working (directly on the code, and/or using a skill to tell the agent to connect directly to a REPL). I guess your previous answer already provides half of the answer to this question: agents learn quickly/better to not forget about using a REPL. Do you use it in such a way to develop a system that the agent is not even using any bash or direct file access to edit a project's code?

Also, I had forgotten about your quiescent lib. Seems to bring the "easy" to a subset of missionary and core.async use cases.

I had some instances of the agent going “whops, I wedged the system/REPL by launching this thing that I can’t terminate”. Didn’t happen often, but super annoying when it did: I had to reboot the app, more or less. That prompted me to design something that the agent can’t wedge. I also wanted ~no API, the agent can learn how to use it by progressive disclosure as it uses the REPL itself. The way information is conveyed supports this, with a fairly exhaustive (but still small) overall picture up-front, and then hints and cues in responses, with most of the tooling just being ordinary Clojure functions rather than MCP tools. Quiescent brings the structured concurrency here. The agent doesn’t have to write async stuff, but it sits in an async container. If it does write async stuff, it just works. And the entire entry is inspectable “from the side” while running, and can be cancelled later if needed. It can queue up work that will reactively start when another long-running thing completes. It opens up the possibility for it to eg. mount polling loops, then “tail” the output of that loop as it goes along, and then retiring it when it’s done. It turns the “wedge” into a feature. It also does other things under the hood that you arguably don’t have to care about: it’s strongly incentivised to create scratch namespaces and require the system namespaces into them when working with them, rather than evaluating directly in the system namespaces. It can then discard/clean up those scratch namespaces, which maintains hygiene in the running app. It teaches itself these things, I don’t have to worry about it. And yes, Remontoire is deployed into our dev/staging/qa servers etc., available to us over a tailnet. We just connect to the server we wish to interact with, and the agent can inspect the running code using the tooling that Remontoire brings along, rather than make assumptions from the code as it reads on disk. This has proven very useful indeed when debugging or solving problems in running systems.

Btw, re: Quiescent, Missionary has structured concurrency, core.async (to my knowledge) does not, fairly different models. Quiescent is inspired by Missionary for that part, and then mostly looks like CompletableFuture API-wise.

Controlled concurrency = structured concurrency. My brain is a bit fried. Adjusted above.

> I had some instances of “whops, I wedged the system/REPL by launching this thing that I can’t terminate”. Didn’t happen often, but super annoying when it did: I had to reboot the app, more or less. That prompted me to design something that the agent can’t wedge. Oh, I hadn't realized that, nice!! (Not sure if the README would gain from a mention like that or if it's just because I read too quickly the paragraph about it.) > And the entire entry is inspectable “from the side” while running, and can be cancelled later if needed. It can queue up work that will reactively start when another long-running thing completes. > > It opens up the possibility for it to eg. mount polling loops, then “tail” the output of that loop as it goes along, and then retiring it when it’s done. It turns the “wedge” into a feature. Very interesting. I'm sure agents can profit from this. (If not mentioned as clearly in the README, I suggest you do!) > it’s strongly incentivised to create scratch namespaces and require the system namespaces into them when working with them, rather than evaluating directly in the system namespaces. It can then discard/clean up those scratch namespaces, which maintains hygiene in the running app. It teaches itself these things, I don’t have to worry about it. Idem! > into our dev/staging/qa servers etc., available to us over a tailnet. We just connect to the server we wish to interact with, and the agent can inspect the running code using the tooling that Remontoire brings along, rather than make assumptions from the code as it reads on disk. This has proven very useful indeed when debugging or solving problems in running systems Hmm, safer impact on prod. I would have used it for sure! (I don't anymore work at a clojure company, but we did have a REPL into prod and I was sometimes making it safer to use.) Your response also strongly suggests you let the agent spew out code the normal way when you develop the system (posix and bash tools, etc.), you don't force it to use only Remontoire to edit and write new code. Thanks a lot for the detailed response! I still use Clojure for side projects and Remontoire will surely be part of my next experiments. My brain is a bit fried too right now, I wrote Premontoire and had to correct to Remontoire. 😂

Oh, I hadn’t realized that, nice!! (Not sure if the README would gain from a mention like that or if it’s just because I read too quickly the paragraph about it.)