altairprime
a day ago
For former ICs who aren’t used to watching out for overwork and burnout as new managers of agents, there’s decades of research studying why people overwork once they’re responsible for (and occasional blockers for) workers that remains just as applicable whether they’re human or bot. Start with this HBR article and explore their Overwork keyword in more depth, perhaps: https://hbr.org/2024/01/want-to-be-a-better-leader-stop-thin...
gosen
a day ago
it's actually very valid these days - we can take any book about team leadership / management and apply it to managing AI agents, it will work most of the times
cyanydeez
a day ago
I just implemented a task queue in my hard fork of paseo; so when I got all the ideas but need to wait for implementation on local models, I just set them all up in the queue and the agents go to work. They start in a single agent and work synchonously because thats how most tasks are, and if the agent has a question, the next item gets shunted to a new session and it continues. Just tested it out on a walk and it's surprisingly effective. Then once it's exhausted, it notifies me (TBD) and I can go in and resolve the remaining issues.
It's definitely an issue of how people feel obligated to feed the beast, but some of it is just how the tools are setup. They can definitely be improved so you don't feel as if youre slowing down because it's idling an figment of a feature or whatever.
But then, I'm just working a small niche non-software driven org and my goal is a "total awareness" kit that will be the hub for anyone who comes after me to carry on the required engineering and science of my company.
noahjk
a day ago
Would be interested to hear more about how you have this set up logically
cyanydeez
14 hours ago
well, I spent a few months wandering the desert of offerings.
Once Qwen3.8-Flash-Next demonstrated it could consistently implement Test Driven Development, I decided to hard fork the "best" work flow that made sense to me, which was paseo.
Then once opencode decided they wanted to rewrite opencode2, I've also started a hard fork of opencode 1.
I pulled in the opencode plugin from: https://github.com/Tarquinen/opencode-dynamic-context-prunin...
Who also abandoned that for some other larger goal.
I've also installed openviking to test out some of the memory stuff.
But to the point: local modals & hardware (all hardware in fact) has a sweet spot of performace. The longer the context grows, the slower they get. Both with restarting any session and just getting pre-fill and token gen.
So, dynamic context prun compresses the context and it's typically compressing it at the top of the stack. So to preserve KV cache, it's putting compressed tools+messages on top. But that eventually is exceeded. There's only so much compressed infomation you can get to; and those sessions eventually acrue too much.
So then I added an eviction command for the agent or I to trigger. Eviction gates at a ratio, 5:1 on my setup, so when the context get to the max limit, the agent is instructed to start eviction. This obviously differents from compression, as we're now digging deeper into the stack. But what it's doing is adding waypoints instead of compression.
A waypoint allows the coherence of the context to remain without all the context pollution that comes from the compression command.
So zooming out, we set a min/max context of say 64k/128k. The model moves through min/max space doing regular compression. Find things, summarize things, progress. But eventually it hits >128k, so the system tells it to evict, and evict is at the bottom of the kv cache, so there is a cost at that point. But that cost is paid for in the speed. The evict's goal is to hit a good ratio 5:1, and to get beneath the 64k. So the agent is aware of what I call context pollution, as context grows, pollution grows.
It took awhile to get all the language together, the agent's prompt is very thin compared to what opencode provides. We treat the agent prompt as a starting point and not some swiss army knife of anything. We provide some skills, but not much. Most is tools.
Anyway, eventually the hard fork of paseo will directly have all this codified; but the rolling window of context is what's valuable and allows us to create implementation plans and ocmplete them. I know this works because I wouldn't hard fork active libraries if I couldn't keep this ball moving.
And I hate react, but that's what paseo's rendering is doing and it's quite capable of adding ui features.
user
a day ago