Hacker News Reader

Comment by brainless | Hacker News Reader

It is not blasphemy if langgraph is trying to do that. As I understand langgraph manages orchestration in custom built agents. I usually stay away from systems which already make it seem as if building agents is a ritual.

What I am saying is the opposite - use Claude Code or whatever else - generate actual "programs". Basically scripts. We have tons of ways for "programs" to interact with each other. Then have clearly defined edge case handlers - think "try/catch". How far do you want to go down the rabbit hole in the "catch"? Do you want to re-write a new version of the "program" itself? I do not know, but this type of a system is what Unix already is, with the addition of programs themselves reaching out to LLMs in well defined edge case handlers.

View on HN

You can drive agents via ACP these days, which I think is the layer you would want for what you’re talking about.

The API is basically what you see as a user of Claude Code or Pi or whatever. You can make new sessions, send messages to sessions, configure which MCPs get started, etc.

I’ve been poking at something similar to what you’re talking about via that route. My client prompts the agent to do a thing, and then afterwards launches deterministic things to check it which can either re-prompt the original session or start a new session.

Eg it automatically runs the tests afterwards, and will send a new prompt in the original chat to fix them if they fail. I also briefly poked at a security analyzer that gets changed files via git and makes a new session to check whether there are security issues and propose a fix that then gets sent to the original session.

If you want a circular loop where the LLM can adjust its own workflow while keeping it deterministic, you can let the agent modify the ACP client that drives it.

I think it all comes down to tight, context efficient, deterministic feedback loops. Pre commit hooks work well for this type of thing. Ideally I think a set of those hooks should run on every file edit, however I haven't gotten around to testing something like that yet.

YMMV but I wouldn’t personally reach for either. They’re both out of band so you have to deal with pulling input back into the context and what to do if one side won’t communicate right.

File edits are just tool calls under the hood. If you’re using a decent agent then you should be able to override or extend the filesystem tools. If you’re on ACP, file reads/writes get proxied to your ACP client and you can inject your hooks there.

It’s pretty trivial to implement, this is well within the bounds of things most agents implement (for open source agents anyways, no idea how to extend Claude Code or Codex these days).

I get what your saying, however we don't need to be stuck with the Claude code harness. You may find this interesting.

https://www.langchain.com/blog/tuning-the-harness-not-the-mo...

Reply on news.ycombinator.com