I kind of have a different idea of agents. I totally believe in a deterministic scaffold but I really think that an agent should be as deterministic as possible - the more code, the better.
Think of a typical loop we may ask of Claude Code today (assume we are not using TDD): run some test suite with fail fast mode, diagnose if the failure is due to recent feature changes (pass reference to backend/frontend, github issues, PRD,...). Ask CC to decide if test failed due to feature change and then update the test. Perhaps ask CC to use sub-agent to investigate and fix (if deemed so). Commit each fix, move on to next.
I know, this has so many ways to make blunder but I am talking about the agent here, not our error-prone test maintenance. What if we had an agent that had context of your codebase, deterministically ran test suite, linter, hooks, etc. The "English" prompt would become a code loop with the LLM only brought in to decide if a test has failed because of feature change. Also, we can extract git log, JIRA and what not.
Each tool here is real code. Executable code that calls others and only prompts when they meet edge cases. Edge cases are defined but we can now accelerate the maintenance of these tools using agents themselves. But the system is built on "programs that do one thing and do it well" and then reach out to an LLM for its specific edge case. The agent is how these executables work with each other.
100% agree that the more deterministic code the better up to the limit where you need the LLM's ability to be non-deterministic to kick in.
There is this ACM blog post called "Manual Work is a Bug" [0] that was originally written to help humans automate processes using code. I find it just as applicable today as when it was written. You and the LLM look at what has to be done and then figure out the scripts/tools to make it happen. You then tie those tools into a system.
The more I use the above the more it makes sense and the worse the whole "just commit the prompt" seems like nonsense.
I was unsuccessful in area of automation because of different issue.
By trade I am a .Net software developer so as a lot of people would imagine — I was not able to accept a script that wouldn’t be reusable and flexible, basically over engineered.
I do quite some devops so I finally had to accept the fact that I can write simple script with hardcoded values that will live on a server (where I can copy paste and change values to meet other server) and most likely I will not have to look at that script for years as it will be running with cron doing its job without an issue.
Over engineered scripts designed from get go always required debugging from time to time so lots of time I was just doing stuff manually to make it quicker.
So I started winning when I accepted first script can be really simple and when needed I can move it to be parametrized but if not it will just keep doing it's job there on the server.
There is an idea I have been enjoying called WET, Write Everything Twice. Basic idea is you should only make things more general and parameterized if you need to write it a third time.
The upshot of this is you actually have a much better understanding of the different way your script needs to work if you're adapting it for a third use instance.
This is an interesting share, thanks. Yes, that is my mental model. Use coding agents to generate more "programs" (scripts) to automate everything. Have edge case handlers - and these handlers can develop/update the original scripts.
You could even have a decision tree in code where the leaf nodes are primarily "run this script with these params" but some of the leaves are "ask the LLM"
I’m definitely on the deterministic code train as well. All of my success for long running tasks has been around wrapping the agentic harness (cc, codex-cli, etc.) in a deterministic workflow with deterministic gates. We need a name for this outer layer. In my mind that is the true harness because it constrains the agents failure mode. I think flow engineering has been proposed. Maybe it’s the agentic exoskeleton?
I propose Channel Engineering, and will be releasing a paper with the full reasoning soon. The TLDR is that it is a communication channel between a Human and AI, mediated by a deterministic agent loop process. That loop is in control of the channel and needs to own it completely to solve for the reliability of the delivered outcomes in ways that can be concretely measured.
I call it tool-response engineering -- the tool-response JSON object itself and any content supplied, plus the available mechanisms after an initial tool call has been made.
From harness? Because people expect a squishy set of things from a harness that is different from what I end up building. I end up with a rigid internal structure that the harness uses in-turn (tests with clear error messages, tools, etc.) and a matched rigid external structure that drives the turn tracking progress and deterministically handles the overall progress. You could call that whole thing a harness but that makes the definition muddy and hard to talk about. So scaffold or skeleton seems more appropriate. The harness constrains the agent. The matched endoskeleton and exoskeleton gives it structure.
What you are describing is precisely my goal with my agent framework.
One of the meta-processes designed in is pushing automated processes, both defined and discovered, down as far as possible. "Down" here means as far towards the metal as reasonable. So automate the automatable stuff, and leave the LLMs to do stuff LLMs are actually good at.
A trivial example is 'handle this bugfix ticket'. Many actions in a bugfix are pre-defined, for example a git commit at the end of the ticket. So Maelstrom will, at the end of a bugfix workflow, will force a git commit from the LLM that did the implementation. The LLM never even sees the git command, it just fills in a JSON field with a commit summary, and the workflow handles the commit.
I believe there should be easy ways to move logic between prompts and code in a smooth ways. Moving from prompts to code is for getting deterministic, fast, well defined and cheap execution - the other way is when you want to quickly extend your system or when you want to relax a pre-condition (which is extending if you look into it deeply).
There are some inroads into this vision - but I haven't seen anything build directly for this (beside my own experiment).
I am not sure if this is sarcasm - but just in case - https://github.com/sshwarts/skillscript does not offer a unified namespace for functions and prompts (agents) like https://github.com/zby/llm-do (currently in suspended development).
There are now also the 'dynamic workflows' in Claude Code that are pretty interesting approach - they are like a compiled prompt in many aspects.
In the age of agents, I feel like BDD is more important than ever since it describes the behavior, and if it does so well it’ll make it much easier for these tools to pick up correct behavior.
The best part about LLMs is that, if you write gherkin style tests, you don't even need to automate them yet to get value, the AI can "manually" validate initially and then only codify them into deterministic execution after they've been nailed down. That way you have a bulk set of tests that run automatically, and a few candidate tests that are not automatically run yet, and the boundaries expand over time.
One of my policies for agentic coding is to spend much effort in developing tests, coded tests not LLM based vibes. My projects have around 1:1 LOC between code and tests. Tests are like skin, when the skin is pricked it hurts, agents need to feel pain too.
OP's idea "everything is a text file" is good and I use it too. My plans are saved as task.md files, numbered and named. Work items are checkboxes inside the file, closed work items are checked and a comment is added on the same line to provide feedback about the implementation.
I also keep a current-state-of-the-world document, it should be <20KB of text, keep the essential decisions and intents. Loading it allows resuming in <30s.
Something I never saw anyone else do - I save all user messages in a chat_log.md file which is referenced for intent alignment and state recovery. I consider the chat log on the one hand, and coded tests on the other hand as the two walls, the agent works in the mid section between them.
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.
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.
I don't think we're necessarily in disagreement here: I agree that determinism should be taken as far as possible, but once we zoom out of the software engineering world I think things tend to get a lot less easy to automate if that makes sense.
Not necessarily. I have been building client projects for the last few months only using coding agents. I use way more existing tools to handle a lot more of our digital footprint than I used to before: pdf, images, excel, ocr and many more.
As coding agents have accelerated my work, I just build tons of tooling around existing software. Or in rare cases build new ones. If we zoom out of software engineering, we will still be in the realm of files - text or binary. That does not change.
The question is - do we let agents run the tools or the "programs" call the LLMs. The OS is the new agent, but not the same sense of "agent". I want LLMs to be lightly sprinkled in a future "agent" OS, not the other way around.
This post is chock-full of soft ideas. They make no meaningful steps toward "a harness that can do anything". The suggestion is to replace a small node application with specific tooling, with a vm "to give it more capabilities". This is what Agent sandboxes are, already. Making the sandbox the harness, doesn't achieve a concrete goal.
I disagree with the idea that file is a good metaphor for LLM. Files have seek and byte streams, which is just an unneeded abstraction for LLM. The LLM doesn't need to seek or jump to the middle of a file, if you store and organize your data properly.
Why force the LLM to use files over vector database or key-value stores, just because it's a design principal for UNIX (which is designed for human users, not LLMs.)
Love the Unix philosophy and the buffs mentioned of the Linux FS. Lean, transparent, and auditability-first is exactly the direction harness' should continue in.
Something I am convinced of though, there probably isn't a single `best` harness for all tasks. Different workloads will likely perform better with certain combinations of model + harness, especially when we are talking about token budgeting and cost tracking.
Ambiance feels like a great base “kernel” to build those variants on top of, rather than the one true harness.
What has been the most helpful when developing harnesses:
> When in doubt, simplify. Remove, trim and minimize. Reproduce issues in as small cases as possible, understand the full design completely, there is no shortcuts for this.
I think tools have to be flexible enough to accommodate a range of expected inputs. Even assuming models are trained to supply a particular schema, they are stochastic and randomly output variants regularly. My experience has been that it's better to try to auto-normalize the range of anticipated outputs and make tools as forgiving as possible rather than force an overly strict schema that might not match training data on the model.
I really like this idea and the way you mapped the concepts to unix primitives. Indeed llms are already "unix native". I've been experimenting with similar event driven workflows using k8s primitives but that's one level up the stack. This makes a whole lot of sense to me in terms of organizing a shared mental model. Will definitely check it out. Thanks for the good work.
Actually I was initially going to put this on my Arch machine because utilizing FUSE made a lot of sense to me, but I realized that I use my mac a lot more often so I suppose that's what caused that choice.
I think domain specific harnesses are already surpassing generic harnesses. I also think software development is its own domain.
My harness is a Claude Code plugin with its own brainstorming, adr, and planning skills with associated review and interview skills. Behavioral testing related to acceptance criteria is built in. Everything in my harness is gated to prevent ratholes.
I recently inflated a docker container to execute a set of work with Claude in unsafe mode and immediately saw problems with everything it was doing…and then I realized I had not installed my harness.
Running Claude without an engineering harness is like driving a car without brakes or a steering wheel.
Mapping agent concepts to the Unix environment sounds like a great idea in general, but I get off the train at adopting the FHS, which is an ancient relic that has no place in a green-field system. I don't know exactly what shape it should take, but something along the lines of Nix seems more appropriate. Or maybe Plan 9.
One of the ideas I had (and I'm still tinkering with) is 'agent as a linux user'. All of the perms/groups/access rights are already built in, so it would make sense to leverage these for agents running on the same host. Heck, there's even mail built in for async comms between agents.
Feel like there's now a lot of modern software that can do particular things well but there is new promise in finding universal abstractions that can ideally run recursively / safely run any software at their leaves. (Unix + tooling is most of the way there ofc)
I feel like Docker Compose / K8S / VM / Dagger.io layers are close but can't quite always recurse flexibly and aren't always simple to run with. Networking / devices / auth are often awkward choke points
>I've been thinking about how to free LLMs from the chat pane for a few years now.
LLM's are language models, you can absolutely control them with bash scripts and deterministic code, there are plenty of frameworks that already do that, and a great engineer will use them, but LLMS are at their most powerful when a user can give the agent an input and the model can run its ReAct loop. Wanting to free an LLM from a chat pane is like wanting to free email from the thread model, or closer, removing the chat window to DM a friend or colleague.
>what can we learn from the before-fore times, when people used to actually write code?
Treat an agent like a human writing code. Give them the best context, give them the best tools. This is why harnesses are overly complicated, because they need to guide the model through the context and tools it has available in a way that is efficient. A good harness is not incompatible with the Unix philosphy, it can do one thing well (interfacing with LLMs and giving them access to filesystems and compute), it will heavily use bash, stringing commands together with the cli tools that it knows (it's context) that it has, and and LLM will naturally handle text streams because that is what it does best.
>Everything is a File
If you want things to be deterministic why resort to plaintext? Wouldn't we want as much as possible to be typed? A computer can parse json which is what you want if you are trying to make your harness as deterministic as possible.
>It watches our FS for changes with cursors on textfiles,
Wow. What is your monthly token bill? I don't know how that would use less tokens than a 30 minute heartbeat, which as you mention will already use a lot of tokens. Why not have it notify your agent after a certain amount of files have been changed, or certain files you deem important?
It seems like this user works at a 12 week programmer retreat and seems to post their cohort's blog posts about the projects they work on.
I'm kind of in the same boat and it's been pestering me for months. Every agent is simply a less capable Claude Code.
If it had a lossless, massive context window (100m-1b tokens), then it will squash everything. Give it bash + r/w and it can in theory /goal anything.
I think there's something to be gained in a production environment be siloing agents for reproducebility/auditability, but I suspect that will go away in the future.
There's that video of a silly demo someone made of an OS that was just nested copilot instances that generated the HTML of each window, which allowed you to do whatever you could imagine. It was seen as silly because it was, but that seems truly transformative.
i think the point is less about what agent you should or should not do and more about what is the natural harness for an agent to succeed in. And agents are often autonomously doing things right now, why would you want claude code doing such stuff for you?
I kind of have a different idea of agents. I totally believe in a deterministic scaffold but I really think that an agent should be as deterministic as possible - the more code, the better.
Think of a typical loop we may ask of Claude Code today (assume we are not using TDD): run some test suite with fail fast mode, diagnose if the failure is due to recent feature changes (pass reference to backend/frontend, github issues, PRD,...). Ask CC to decide if test failed due to feature change and then update the test. Perhaps ask CC to use sub-agent to investigate and fix (if deemed so). Commit each fix, move on to next.
I know, this has so many ways to make blunder but I am talking about the agent here, not our error-prone test maintenance. What if we had an agent that had context of your codebase, deterministically ran test suite, linter, hooks, etc. The "English" prompt would become a code loop with the LLM only brought in to decide if a test has failed because of feature change. Also, we can extract git log, JIRA and what not.
Each tool here is real code. Executable code that calls others and only prompts when they meet edge cases. Edge cases are defined but we can now accelerate the maintenance of these tools using agents themselves. But the system is built on "programs that do one thing and do it well" and then reach out to an LLM for its specific edge case. The agent is how these executables work with each other.
100% agree that the more deterministic code the better up to the limit where you need the LLM's ability to be non-deterministic to kick in.
There is this ACM blog post called "Manual Work is a Bug" [0] that was originally written to help humans automate processes using code. I find it just as applicable today as when it was written. You and the LLM look at what has to be done and then figure out the scripts/tools to make it happen. You then tie those tools into a system.
The more I use the above the more it makes sense and the worse the whole "just commit the prompt" seems like nonsense.
0 - https://queue.acm.org/detail.cfm?id=3197520
I was unsuccessful in area of automation because of different issue.
By trade I am a .Net software developer so as a lot of people would imagine — I was not able to accept a script that wouldn’t be reusable and flexible, basically over engineered.
I do quite some devops so I finally had to accept the fact that I can write simple script with hardcoded values that will live on a server (where I can copy paste and change values to meet other server) and most likely I will not have to look at that script for years as it will be running with cron doing its job without an issue.
Over engineered scripts designed from get go always required debugging from time to time so lots of time I was just doing stuff manually to make it quicker.
So I started winning when I accepted first script can be really simple and when needed I can move it to be parametrized but if not it will just keep doing it's job there on the server.
There is an idea I have been enjoying called WET, Write Everything Twice. Basic idea is you should only make things more general and parameterized if you need to write it a third time.
The upshot of this is you actually have a much better understanding of the different way your script needs to work if you're adapting it for a third use instance.
This is an interesting share, thanks. Yes, that is my mental model. Use coding agents to generate more "programs" (scripts) to automate everything. Have edge case handlers - and these handlers can develop/update the original scripts.
You could even have a decision tree in code where the leaf nodes are primarily "run this script with these params" but some of the leaves are "ask the LLM"
I’m definitely on the deterministic code train as well. All of my success for long running tasks has been around wrapping the agentic harness (cc, codex-cli, etc.) in a deterministic workflow with deterministic gates. We need a name for this outer layer. In my mind that is the true harness because it constrains the agents failure mode. I think flow engineering has been proposed. Maybe it’s the agentic exoskeleton?
I propose Channel Engineering, and will be releasing a paper with the full reasoning soon. The TLDR is that it is a communication channel between a Human and AI, mediated by a deterministic agent loop process. That loop is in control of the channel and needs to own it completely to solve for the reliability of the delivered outcomes in ways that can be concretely measured.
I call it tool-response engineering -- the tool-response JSON object itself and any content supplied, plus the available mechanisms after an initial tool call has been made.
Why do you need a different name?
From harness? Because people expect a squishy set of things from a harness that is different from what I end up building. I end up with a rigid internal structure that the harness uses in-turn (tests with clear error messages, tools, etc.) and a matched rigid external structure that drives the turn tracking progress and deterministically handles the overall progress. You could call that whole thing a harness but that makes the definition muddy and hard to talk about. So scaffold or skeleton seems more appropriate. The harness constrains the agent. The matched endoskeleton and exoskeleton gives it structure.
I believe they call it "loop engineering"
What you are describing is precisely my goal with my agent framework.
One of the meta-processes designed in is pushing automated processes, both defined and discovered, down as far as possible. "Down" here means as far towards the metal as reasonable. So automate the automatable stuff, and leave the LLMs to do stuff LLMs are actually good at.
A trivial example is 'handle this bugfix ticket'. Many actions in a bugfix are pre-defined, for example a git commit at the end of the ticket. So Maelstrom will, at the end of a bugfix workflow, will force a git commit from the LLM that did the implementation. The LLM never even sees the git command, it just fills in a JSON field with a commit summary, and the workflow handles the commit.
I believe there should be easy ways to move logic between prompts and code in a smooth ways. Moving from prompts to code is for getting deterministic, fast, well defined and cheap execution - the other way is when you want to quickly extend your system or when you want to relax a pre-condition (which is extending if you look into it deeply).
There are some inroads into this vision - but I haven't seen anything build directly for this (beside my own experiment).
I have some 'vibe noted' notes on this: https://zby.github.io/commonplace/notes/unified-calling-conv..., https://zby.github.io/commonplace/notes/rlm-tendril-and-llm-...
The idea of morphing prompts to code and back is revolutionary.
You may want to read earlier discussions https://news.ycombinator.com/item?id=48881112 And https://news.ycombinator.com/item?id=48051562
I
awww for a second I thought you were maybe talking about something like this: https://news.ycombinator.com/item?id=48905887
I am not sure if this is sarcasm - but just in case - https://github.com/sshwarts/skillscript does not offer a unified namespace for functions and prompts (agents) like https://github.com/zby/llm-do (currently in suspended development). There are now also the 'dynamic workflows' in Claude Code that are pretty interesting approach - they are like a compiled prompt in many aspects.
In the age of agents, I feel like BDD is more important than ever since it describes the behavior, and if it does so well it’ll make it much easier for these tools to pick up correct behavior.
Gherkin style tests also come to mind
The best part about LLMs is that, if you write gherkin style tests, you don't even need to automate them yet to get value, the AI can "manually" validate initially and then only codify them into deterministic execution after they've been nailed down. That way you have a bulk set of tests that run automatically, and a few candidate tests that are not automatically run yet, and the boundaries expand over time.
One of my policies for agentic coding is to spend much effort in developing tests, coded tests not LLM based vibes. My projects have around 1:1 LOC between code and tests. Tests are like skin, when the skin is pricked it hurts, agents need to feel pain too.
OP's idea "everything is a text file" is good and I use it too. My plans are saved as task.md files, numbered and named. Work items are checkboxes inside the file, closed work items are checked and a comment is added on the same line to provide feedback about the implementation.
I also keep a current-state-of-the-world document, it should be <20KB of text, keep the essential decisions and intents. Loading it allows resuming in <30s.
Something I never saw anyone else do - I save all user messages in a chat_log.md file which is referenced for intent alignment and state recovery. I consider the chat log on the one hand, and coded tests on the other hand as the two walls, the agent works in the mid section between them.
https://horiacristescu.github.io/claude-playbook-plugin/docs...
Thanks for the link. I need to evolve my own system in this direction.
Yes, I agree with this. I am not focusing on tests as much and I think that is a big mistake. Agents need to immediately understand something is off.
I know it's a type of blasphemy here, but deterministic workflows such as what you describe is where langgraph really shines imo.
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.
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.
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...
I don't think we're necessarily in disagreement here: I agree that determinism should be taken as far as possible, but once we zoom out of the software engineering world I think things tend to get a lot less easy to automate if that makes sense.
Not necessarily. I have been building client projects for the last few months only using coding agents. I use way more existing tools to handle a lot more of our digital footprint than I used to before: pdf, images, excel, ocr and many more.
As coding agents have accelerated my work, I just build tons of tooling around existing software. Or in rare cases build new ones. If we zoom out of software engineering, we will still be in the realm of files - text or binary. That does not change.
The question is - do we let agents run the tools or the "programs" call the LLMs. The OS is the new agent, but not the same sense of "agent". I want LLMs to be lightly sprinkled in a future "agent" OS, not the other way around.
This post is chock-full of soft ideas. They make no meaningful steps toward "a harness that can do anything". The suggestion is to replace a small node application with specific tooling, with a vm "to give it more capabilities". This is what Agent sandboxes are, already. Making the sandbox the harness, doesn't achieve a concrete goal.
I find it refreshing to read a blog of someone just noodling on an idea rather than pitching a new product.
It’s a pitch for their product ambience
I disagree with the idea that file is a good metaphor for LLM. Files have seek and byte streams, which is just an unneeded abstraction for LLM. The LLM doesn't need to seek or jump to the middle of a file, if you store and organize your data properly.
Why force the LLM to use files over vector database or key-value stores, just because it's a design principal for UNIX (which is designed for human users, not LLMs.)
Love the Unix philosophy and the buffs mentioned of the Linux FS. Lean, transparent, and auditability-first is exactly the direction harness' should continue in.
Something I am convinced of though, there probably isn't a single `best` harness for all tasks. Different workloads will likely perform better with certain combinations of model + harness, especially when we are talking about token budgeting and cost tracking.
Ambiance feels like a great base “kernel” to build those variants on top of, rather than the one true harness.
What has been the most helpful when developing harnesses:
> When in doubt, simplify. Remove, trim and minimize. Reproduce issues in as small cases as possible, understand the full design completely, there is no shortcuts for this.
How much do the labs post-train on the harness inputs & outputs? That's a critical piece to understand if a "generic" harness is at all possible
https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/ says already too much to use foreign tools.
I think tools have to be flexible enough to accommodate a range of expected inputs. Even assuming models are trained to supply a particular schema, they are stochastic and randomly output variants regularly. My experience has been that it's better to try to auto-normalize the range of anticipated outputs and make tools as forgiving as possible rather than force an overly strict schema that might not match training data on the model.
I really like this idea and the way you mapped the concepts to unix primitives. Indeed llms are already "unix native". I've been experimenting with similar event driven workflows using k8s primitives but that's one level up the stack. This makes a whole lot of sense to me in terms of organizing a shared mental model. Will definitely check it out. Thanks for the good work.
thanks a lot! let me know what you think -- i'd love to share ideas with people doing similar stuff!
I do have a gripe already... The readme says macos, however as of yet I don't see the actual dependency. Sort of defeats the *nix spirit as well, no?
Actually I was initially going to put this on my Arch machine because utilizing FUSE made a lot of sense to me, but I realized that I use my mac a lot more often so I suppose that's what caused that choice.
Yeah, a little... I was mostly building this for myself so I didn't really think about other platforms but I'll get to it asap :)
good news. now you have a feature request.
Or an incoming PR ;)
I think domain specific harnesses are already surpassing generic harnesses. I also think software development is its own domain.
My harness is a Claude Code plugin with its own brainstorming, adr, and planning skills with associated review and interview skills. Behavioral testing related to acceptance criteria is built in. Everything in my harness is gated to prevent ratholes.
I recently inflated a docker container to execute a set of work with Claude in unsafe mode and immediately saw problems with everything it was doing…and then I realized I had not installed my harness.
Running Claude without an engineering harness is like driving a car without brakes or a steering wheel.
Thank you for framing my laziness as being a daredevil
Mapping agent concepts to the Unix environment sounds like a great idea in general, but I get off the train at adopting the FHS, which is an ancient relic that has no place in a green-field system. I don't know exactly what shape it should take, but something along the lines of Nix seems more appropriate. Or maybe Plan 9.
One of the ideas I had (and I'm still tinkering with) is 'agent as a linux user'. All of the perms/groups/access rights are already built in, so it would make sense to leverage these for agents running on the same host. Heck, there's even mail built in for async comms between agents.
“That can do anything” gives me Zombo.com vibes. I would be more interested if it seemed to do particular things well.
Feel like there's now a lot of modern software that can do particular things well but there is new promise in finding universal abstractions that can ideally run recursively / safely run any software at their leaves. (Unix + tooling is most of the way there ofc)
I feel like Docker Compose / K8S / VM / Dagger.io layers are close but can't quite always recurse flexibly and aren't always simple to run with. Networking / devices / auth are often awkward choke points
Or if it had any kind of measurement across a range of tasks
What's with this "harness" word people have been trying to adopt lately? Are we all going rock climbing?
A harness is just a piece of software that exposes APIs for reading files, connecting to the internet, etc.
It parses the LLM output for tool calls, executes the command, and puts the output back into the LLM input. That's all there is to it.
The awesome power of the AI must be somehow contained by us mere mortals.
I think a better term would be bridle, but most people don't know it. But they do put harnesses on their kids and pets.
We're taming a beast.
framework is too 90s
Buzzword bullshit bingo is a must for anyone who wants to ride the hype.
>I've been thinking about how to free LLMs from the chat pane for a few years now.
LLM's are language models, you can absolutely control them with bash scripts and deterministic code, there are plenty of frameworks that already do that, and a great engineer will use them, but LLMS are at their most powerful when a user can give the agent an input and the model can run its ReAct loop. Wanting to free an LLM from a chat pane is like wanting to free email from the thread model, or closer, removing the chat window to DM a friend or colleague.
>what can we learn from the before-fore times, when people used to actually write code?
Treat an agent like a human writing code. Give them the best context, give them the best tools. This is why harnesses are overly complicated, because they need to guide the model through the context and tools it has available in a way that is efficient. A good harness is not incompatible with the Unix philosphy, it can do one thing well (interfacing with LLMs and giving them access to filesystems and compute), it will heavily use bash, stringing commands together with the cli tools that it knows (it's context) that it has, and and LLM will naturally handle text streams because that is what it does best.
>Everything is a File
If you want things to be deterministic why resort to plaintext? Wouldn't we want as much as possible to be typed? A computer can parse json which is what you want if you are trying to make your harness as deterministic as possible.
>It watches our FS for changes with cursors on textfiles,
Wow. What is your monthly token bill? I don't know how that would use less tokens than a 30 minute heartbeat, which as you mention will already use a lot of tokens. Why not have it notify your agent after a certain amount of files have been changed, or certain files you deem important?
It seems like this user works at a 12 week programmer retreat and seems to post their cohort's blog posts about the projects they work on.
I use AI all the time
But
I don't want the AI to summarize my email for me.
I don't want the AI to summarize my calendar for me.
I don't want the AI to summarize my Zoom call for me.
Thanks
I was hoping this was a climbing harness that could service other trades too
Why are we not just using Claude Code or Codex on our machine and using this thing? Real question...
I'm kind of in the same boat and it's been pestering me for months. Every agent is simply a less capable Claude Code.
If it had a lossless, massive context window (100m-1b tokens), then it will squash everything. Give it bash + r/w and it can in theory /goal anything.
I think there's something to be gained in a production environment be siloing agents for reproducebility/auditability, but I suspect that will go away in the future.
There's that video of a silly demo someone made of an OS that was just nested copilot instances that generated the HTML of each window, which allowed you to do whatever you could imagine. It was seen as silly because it was, but that seems truly transformative.
i think the point is less about what agent you should or should not do and more about what is the natural harness for an agent to succeed in. And agents are often autonomously doing things right now, why would you want claude code doing such stuff for you?
This one is open source, and potentially better, since it responds to (file system) events instead of polling.
Just one more harness bro, one more harness I swear one more harness and we will have solved AGI bro