Hacker News Reader

Comment by mikepurvis | Hacker News Reader

I've recently gotten religion on the workflow that is many (relatively) short-lived agent sessions passing planning/handoff docs between themselves. It's better for my own task tracking, better for handling "oh btw I noticed XXXX", and better as a clear review point. Overall it just feels like it takes a lot of the formerly implicit context that was whatever we happened to have talked about and turns it into a much more explicit "this is what you need to know, now go".

Currently looking for a framework for managing this in a more formal way, and I think it's probably beads, but interested to hear from others.

View on HN

Spent the past 1,5 years building a tool that might be relevant, helping keep durable task state between agent sessions. It is an issue tracker persisting state as immutable event logs, allows you to inspect workflows after the fact, lets you inspect diffs inline in the tickets and it is much more lightweight than Jira/Linear. There is no central service to integrate with, as it is Git-backed and lives with your code in your repo.

https://ljtn.github.io/epiq/

Might be worth a look if you’re evaluating alternatives to Beads.

This looks really nice and I'm definitely going to give it a go. I been relying on Jira so this will be a breath of fresh air. Beads was great in principle and I haven't given it a look in a while but this looks much cleaner.

Curious to hear how you find it after trying it!

Not OP but will definitely have a look.

I have some older projects that use beads (I still run an old version without dolt that's imho pretty good overall) but lately with Fable also have a few newer projects where I just have the agent write docs and keep a worklog with the what/why/decisions etc. (I think I read it here on HN somewhere and figured I'd give that a try.)

The latter seems to work pretty well for now (slightly better than beads) but I'm always looking for ways to improve it. This could be an interesting replacement.

I think it works well for tracking intent. I tell my agents to use a "human-input-needed" tag when there is a high stakes decision fork, and then I just filter on that tag, immediately highlighting blocked workflows. I think you can get a long way with clever tagging, filtering + time travel.

Wow. It's like beads++

Great work man.

Checking this out, the skill it wants me to add to my project seems to reference issues that wouldn't make sense in the context of my project. IE: `QPPR7PE` and `MBB6WY5` ?

You are totally right in that it makes no sense. It seems like the skill.md had regressed as I had updated it via agent proxy. Thanks for pointing it out, the skill has been brushed up.

I’ve been trying it out on a personal project. It’s been going well. The only difficulty I’ve had is getting it to work with cloud sessions on Claude.

Got it! I am not up to speed on Claude cloud sessions yet. Interested to hear how that works out for you. Let me know if you figure out what's getting in the way, I'd be happy to look into it.

Oh shit, this looks incredible. Thanks!

> 13:37 - 13:49

“ayy lmao”

I have a lot of little projects and I also prefer this way of working with agents. Sometimes I would start to interrogate on a specific portion or ask questions to better understand a concept, and the session would get poisoned and the agent would fixate on that topic for all the remaining turns.

I asked fable to look at my interaction patterns and clearly stated my frustrations and the problems I wanted solved, and it designed a simple process to track things in git and built a couple simple session hook skills. It’s pretty lightweight and I’ve been very happy with it for a couple months.

The power of this mode of work is that after you deconstruct the task into smaller subtasks, it's a lot easier to use cheaper models to implement that task.

I get a long way using models like Opus to make a plan of action and a bunch of tasks, and then using Deepseek to implement that plan of action. Saves a bunch of money and is fast.

Yep! The other big advantages for me:

- I have a record of work done and work to be done that helps _me_ when I come back to the project after several months. It’s committed and lives with the code.

- when a task inevitably ends up more complicated than I thought, I can in that session break it up

- I initiate sessions from multiple computers, so things stay in sync (through git)

- I also have a “tooling” repo that builds out some views of the work and hosts it for me to see when I’m on my phone.

- The hooks let the agent manage all of the workflow/task management, so there’s very little management overhead for me.

I rejected beads and JIRA. I wanted something more lightweight.

What do the session hooks do?

- start: invokes `work brief` skill to put the current tasks into context

- pre-compact: does the same so work state survives compaction

- stop: lints the work-tracking yaml files to make sure that updates mid session don't break

Nice. I found myself doing a lot of repetitive stuff handing off between agents, time to fix that. I think I agree with your approach of keeping it lean.

I also sometimes rewind the conversation after going off on a tangent, sometimes not if I want the agent to have the sorts of things I’m thinking about in context. I probably justify keeping too much crud in context than I should

I've been on this kick since I realized the primacy of the initial part of the session context. I created a python app that reads a phased plan and kicks off a new session for each phase. There is a standard prompt and handoff mechanism to determine if we encountered any unforeseen issues that we need to address in chat, but otherwise it will just grind with a clean session with appropriate context for each phase.

Just kicking off a subagent does this automatically...?

My main conversation is usually with an orchestrator that hands off work to various (usually cheaper) subagents to plan / review / etc. It has instructions to find the correct model for each task and not to do too much itself so a multi-phase plan automatically gets a fresh subagent for each phase.

i disable subagents. it also helps that i work in microservice size repos, so a single agent can keep the full relevant context. subagents waste alot of unnecessary tokens doing code exploration that the main agent is going to end up duplicating, i think they make more sense for monorepos.

anecdotally I've tried the same plan on different branches with both approaches (single agent with subagents implement the full plan vs. my little session per phase app) and then had agents judge the code quality and my approach worked better and saves tokens. horses for courses.

That sounds very similar to just manually compacting after every message. Is there a difference I'm not seeing?

I used taskwarrior for myself and agents, but felt it was insufficient for agentic era in many ways, so I started building my own a while back:

https://aventasks.dev/

I use Jobs [0] to manage this—it's an agent-first CLI to track issues and tasks. A single `job orient` command gives the agent the current task in the context of the larger plan. It's a replacement for Plan Mode and issue trackers, and it has allowed me to execute massive plans in parallel with minimal oversight. There's a web UI, but it's a work in progress.

[0]: https://github.com/bensyverson/jobs

Look into beads/dolt then - it does this pretty much with a cli - Jira for agents :)

https://recursive-mode.dev

httpd://recursive-mode.dev

Reply on news.ycombinator.com