I've seen a few posts in the last week that talk about engineer's loosing their time to think because they're too busy watching what their LLM agents are doing.
Anthropic's models, even under GasTown, have decide to spontaneously fork and find other ways to farm work out to subagents, occasionally causing agent storms on my project in the last week, so I can sympathize a bit more now that I did at the start of the week.
There are a few solutions I'd like to propose for this issue. Here goes.
How to Get Your Thinking Time Back
- First, if you're agents are doing marginally what you want, this is pretty simple. Stand up, back away from your desk, and leave. If it makes you feel better, setup a notification so the agent messages you when it's done. Perhaps, something like this
- If you don't trust your agents for the moment, still don't watch them. Come up with metrics to know if they worked or not and control your agents or modify their activities AUTOMATICALLY. Once again, walk away. For example, my next task will be to either have the GasTown mayor pole my agents to make sure they're not creating two many subagents. Since GasTown is actually constructed for exactly this kind of thing, I can ask the mayor to control the agents by nudging, or in extreme cases nuking them.
- You don't want to have the mayor doing this forever, so the next step is to document what went wrong. Yes, in an issue database.
- Set up an eval space where you can try different prompts or control structures until the bad behavoir stops. Good experimental method says to change one thing at a time, measure resultts, and iterate. Agents are chatty though, so you'll want to use an isolation strategy like this one.
- Once you've got a fix, document it and revision control it. Do not complain. You can have the LLM do most of this for you.
- Setup a timed analysis run to repeat the experiment with your fix. Run it perhaps once a day to start, and then maybe thin out to once a week or month when the test case keeps passing. The point here is that models create somewhat random rsults. When models are changed they can definitely relapse to old behaviors. You need a way to automatically detect that that has happened and deal with it. Thing of the reruns (erm regressions) like a retry exponential fallback timing loop.
And that's that! Ahem... Yeah, it's some work. It is, however, work that I'll be doing with you this week, so I'll keep you posted on my findings and progress as I go.
Comments
Post a Comment
Please leave your comments on this topic: