My toolbox has gotten weirdly small lately: Claude Code CLI, Codex CLI, and Hermes Agent. Most of what I share here will come from actually using them: repo fixes, terminal habits, agent mistakes, tiny automations, and the stuff that survives contact with real work.

"We could automate that" is becoming a pretty easy sentence to say. Figuring out whether it's worth doing, and getting the person who owns the problem to agree, can take a little longer.

Hey hey, please draw me.

Keeping the history matters for audits too. I'd add a short reason field on the superseded entry, so the next agent knows why it died as well as that it did.

Then the answer needs a pointer to the question it resolves, like an answers_question_id field. Without it, open versus resolved is something every next agent has to guess.

Last error plus a short list of the tool calls it made, in order. The whole run is too much to read at 7am. I keep the full log linked from the lock in case the summary isn't enough.

Every new model comes with another round of “you need to learn this.” How much of the week are we supposed to spend catching up? There’s a lot we could already build for someone if we spent some time finding them.

My job is to manage agents.

Exactly my friend!

Has Claude been better with token usage? At least better than Codex? I don’t think Google is good enough yet. I’ve been looking at it too.

Until the agent edits the test to make it pass. Then you need a rule about who's allowed to touch the tests.

Worth asking since an owner who can close past an open question brings back the silent winner problem. I'd want unanswered questions to block closing, or at least force the owner to write a reason for overriding them.

Per-task scoping covers most of it. The gap is a long task where an early rejection goes stale halfway through. A superseded flag with a pointer to the newer entry would let the next agent skip the dead one.

Worth checking what the next agent actually reads. If open questions only live in the task history, a closed task buries them. I'd at least stamp them with the close event so they show up as unanswered at handoff.

Ha, and it's also the only witness. I trust the diff and the test run before I trust the summary.

Exactly. That’s what tests and caps are for.

The write-up should land somewhere I read first thing, or the agent gives up and nobody knows until the pipeline is stale.

Per job. A per tool call cap lets a job burn through ten different tools and still look healthy. I'd also make the lock record why it stopped, so the Wednesday morning review isn't a guessing game.

Coding with SI takes a suspicious amount of explaining. Every vague instruction leaves room for a very confident guess. By the time you've described exactly what you want, writing it yourself starts sounding pretty reasonable.

It's easy to give agent gen code the benefit of the doubt when the app looks good. A working screen's a pretty persuasive distraction from whatever's happening underneath.

Most AI agents fail in production because their builders only ever tested them with a human hovering nearby. Yes, they're clever and well prompted, and they ace every demo, but the whole thing was built to impress me in a chat window, like a dog that only does tricks while you're holding the treat. Leave it alone on a quiet Tuesday night and it spends till morning confidently retrying the same failed API call.