Sub-agent depth and tree budget limits #9
Labels
No labels
bug
commercial
documentation
duplicate
enhancement
feature
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
jasoncouture/llama-shears#9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Configurable max spawn depth plus a per-tree budget so a runaway parent agent (or a malicious one) can't infinitely recurse.
Depends on sub-agents (#8).
Tracked in TASKS.md.
Sub-agent depth limits are a good start, but I’d pair tree depth with a parent-owned admission policy.
Otherwise you can still get a shallow tree that wastes budget because every child keeps getting admitted into low-value retries. The useful gate tends to be: does the parent still have budget, is the current branch verifier-clean enough to continue, and is there a concrete reason another child is justified?
That’s been the better pattern for us than just counting descendants. The depth limit protects the shape of the tree; the admission gate protects the spend.
That's a great question, to be honest, I'm not quite sure where I'm going yet. I didn't use projects and wanted to advertise stuff that could be picked up (thinking no one would look at this until I was much further along).
Having a parent budget was definitely always in the cards. There are (though I'd personally never let it go more than 2 deep) some cases where a deep sub-agent tree is helpful.
My thought here was: N sub agents with a maximum depth of M, the total cannot exceed N.
Closing — going with a flat depth limit of 1. Sub-agents won't have the spawn tool in their toolset, so a sub-agent simply can't spawn further sub-agents. No per-tree budget needed.