[flagged]
Handbook.md shows that long policy documents do not reliably govern agents
221–230 of 237 posts
Re: Handbook.md shows that long policy documents do not reliably govern agents
#222Earlier quoted context omitted.
Shorter is better. This can be applied to human communication too.
Not always. If an instruction is short and vague, then LLMs tend to fill in the blanks by guessing and the results are unpredictable. Semantic density is the key, prompts/instructions should be actionable and unambiguous over being terse and vague. So, it's more about being concise.
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.”
Re: Handbook.md shows that long policy documents do not reliably govern agents
#223Earlier quoted context omitted.
Ok so what is the correct way to tell it "I don't care what is happening, you must uphold these rules at all times"? If it's not any configuration of .md files?
You need to make the rule concrete somehow. I call it a "control". So for example, instead of instructing it "always run tests before committing", you (or you have it) make a git commit hook that always runs the tests first and that refuses the commit if they don't pass. In this case, it is an advisory control only, because the LLM can also unhook that hook. And of course, it could also just disable the failing test(…
[flagged]
Re: Handbook.md shows that long policy documents do not reliably govern agents
#224Earlier quoted context omitted.
I would call that a pipeline, which may be a type of graph, but might have communicated your point more concretely to begin with
I called it a graph because really its a DAG (Directed Acyclic Graph) , in my example I kept it simple so there was only one input to every node, but in more advanced use cases you might have a synthesis node that takes in 2 or more inputs making it more akin to an execution graph in Tensorflow for example
DAGs are used in scientific workflows like snakemake. I wonder if such pipeline engines are use in LLM space.
Re: Handbook.md shows that long policy documents do not reliably govern agents
#225For my own (rather idiosyncratic) harness I've been experimenting [0] with "compiling" long markdown specifications into small executable logic programs. It's too early to tell for sure, but I believe that this approach does have its merits when you want some guarantees about how your agents behave for longer tasks. [0] https://github.com/deepclause/deepclause-sdk
Interesting idea. I’ve been noodling about something similar myself for a few months, but I haven’t moved forward with testing it. What sort of outcomes are you seeing with it? IMO, we’re never going to get to AGI without fusing “soft” AI decision making with “hard” logic and symbolic algorithmic reasoning. Humans don’t realize this most of the time, but we routinely use them all.
Sorry, did not notice your comment until just now.
So far I am observing two things:
1. For smaller models, performance on Benchmarks such as DeepPlanning does increase significantly.
2. Context hygiene for sub agents becomes much simpler, since that can be expressed relatively concise and the mechanics are handled by the runtime automatically.
Still looking for a good test cases to study possible advantages, but running reliable benchmarks does take time and money...
Re: Handbook.md shows that long policy documents do not reliably govern agents
#226Earlier quoted context omitted.
Interesting idea. I’ve been noodling about something similar myself for a few months, but I haven’t moved forward with testing it. What sort of outcomes are you seeing with it? IMO, we’re never going to get to AGI without fusing “soft” AI decision making with “hard” logic and symbolic algorithmic reasoning. Humans don’t realize this most of the time, but we routinely use them all.
Sorry, did not notice your comment until just now. So far I am observing two things: 1. For smaller models, performance on Benchmarks such as DeepPlanning does increase significantly. 2. Context hygiene for sub agents becomes much simpler, since that can be expressed relatively concise and the mechanics are handled by the runtime automatically. Still looking for a good test cases to study possible advantages, but run…
Are you the Deepclause author? I tried it yesterday and my first reaction was that it was slow. Perhaps I’m doing something wrong, however. Running against the same model in Pi was lightspeed in comparison. Second reaction is the prompt editor needs to handle more than a single line of text and it needs Emacs editing key bindings like Pi. I’m happy to do some testing on it and provide further feedback. What’s the best way to submit that? GitHub issues?
Re: Handbook.md shows that long policy documents do not reliably govern agents
#227This is what spec driven development tries to solve. Multiple rounds of generating small contacts documents that grow from the original idea , trying to keep each slice small enough to process for a human to approve/disprove . Eventually it leads to a long list of tasks grouped by functionality. You start a new context and the orchestrator agent dispatches tasks to sub agents with a limited amount of information prov…
I have not seen any real life examples of successful application of SDD. I heard a lot of marketing BS, but nothing real. My own experiments with SDD produced very disappointing results even on very small projects.
I've had good results from SDD, and so have some of my teammates. The guidance I've heard over and over again is: the more you define, the better it does. I find that breaking things out into individual steps is helpful. However, your mileage may vary. Things like Gastown and GetShitDone, I have not found to be particularly useful.
Re: Handbook.md shows that long policy documents do not reliably govern agents
#228Earlier quoted context omitted.
Sorry, did not notice your comment until just now. So far I am observing two things: 1. For smaller models, performance on Benchmarks such as DeepPlanning does increase significantly. 2. Context hygiene for sub agents becomes much simpler, since that can be expressed relatively concise and the mechanics are handled by the runtime automatically. Still looking for a good test cases to study possible advantages, but run…
Are you the Deepclause author? I tried it yesterday and my first reaction was that it was slow. Perhaps I’m doing something wrong, however. Running against the same model in Pi was lightspeed in comparison. Second reaction is the prompt editor needs to handle more than a single line of text and it needs Emacs editing key bindings like Pi. I’m happy to do some testing on it and provide further feedback. What’s the bes…
Yes, I am the author and thanks so much for trying! Please do submit a github issue. My first suspicion about the speed is that maybe an inner loop is taking too many turns until the model finally realizes that a task is finished (so that in turn the runtime knows whether the predicate failed or not and can continue execution accordingly). Happy to take a closer look!
The point about multiline prompts is very valid obviously, that's on the todo list.
Re: Handbook.md shows that long policy documents do not reliably govern agents
#229The rules in main prompt and context is not working well in any times with LLM. The only way is to test results and let agent validate its own result against the rules.
It will be interesting to see such benchmark. How the different models behave.
If I want to be sure I'm using my own deterministic rules checkers as a tool, that has to AI run and update the result accordingly.
Re: Handbook.md shows that long policy documents do not reliably govern agents
#230This is a problem with long context models. To put it as simple and as bluntly as possible: just because they claim you can use 1M tokens in your context doesn't mean its true and you should do that. Due to extreme quantization of models and the context's KV cache, and also just really shitty samplers provided to the user (hell, most are just getting rid of sampler knobs altogether), this problem will absolutely cont…
Just need the hardware industry to catch up with consumer demand. 200kUSD+ on a computer capable of local inference is simply a non-starter.