I much prefer giving the LLM a REPL loop, and injecting all the tools as functions inside the REPL loop.
That means that the LLM isn't constrained to writing a DAG, it can write code that loops, exits early, etc.
1. Hierarchical skills, workflow, skill learning 2. Meta Harness, self-learning harnesses 3. Trace/trajectory representation 4. Common agentic benchmarks
But first more basic things like 5. Blog posts form anthropic 6. How Claude Code/PI/ Hermes!! agent works 7. Agent sessions/ Forking/ Hooks
The idea is cool, but from own experience in harness engineering, lots of cool sounding ideas can have a negative impact on performance due to emergent and confounding effects.
So I'm a bit skeptical!
dominotw•1h ago
champagnepapi•1h ago
shostack•28m ago
But there is another aspect which I do enjoy which is closer to the feeling of dialing in key bindings in vim or getting a really good rhythm going with your vscode extensions or zhs plugins. It is that level of "I want my system to do exactly this thing in exactly this way" customization that a lot of technical people crave.
And you can do it with harness and context engineering in many cases. In other cases it introduces friction because it will be like "cool, I will only output 15 words max unless told otherwise" and then in the next turn completely disregards it with an "oops, you did tell me to do that didn't you."
And that frustration compounds when older model versions may have done a better job of that but new models are like "thank you for your suggestion, your opinion, while appreciated, is irrelevant. Now let me get back to overspending on your token budget. "
lobo_tuerto•26m ago
See what some guys like Linus Torvalds, or Eric S. Raymond are saying about. It's not so much about "vibes" but using the tool (yes the AI tool) in a certain way that can propel yourself towards your goal at unprecedented speeds.
alansaber•16m ago
floatrock•22m ago
The example listed in the article -- fanning out a few simple get-population, get-timezone, and make-summary calls -- is, in fact, useless overengineering. This is a basic promise chain with extra steps (priced with tokens).
But as with all software pattern learning, we learn the concepts with simple toy examples that generalize into something bigger. It's the generalization that matters here.
This is talking about a few methods and tricks for spawning effective subagents (collectively, that's the "harness"). Those tips and tricks are nice, but to not be considered useless, we need to make sure we understand why spawning subagents is useful in the first place. Yes parallelism is nice for some tasks, but that's not really what this is about.
The real reason is protecting your context. Yeah, we have 1M context windows that can fit all of LotR in it, but these machines work better when they're narrowly focused. Large context windows run into attention issues and forgetfulness ("Yes, you're right, it was stated I should/n't do X but I ignored it, my bad."). So subagents come into play when you don't want all the tokens associated with a subtask to pollute your main/primary context window and degrade task attention. Split that off to a subagent, let that context navigate the details, and just make sure your main one gets just the input/output blackbox results.
The trick is getting a sense for when the complexity of the task warrants that kind of context protection, vs when a single agent is good-enough. Your toy example will never have enough complexity to warrant the setup, but you might one day find a generalization that may.
hagen8•21m ago
alansaber•18m ago