upvote
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.

reply
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.
reply
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.

reply
Wow. It's like beads++

Great work man.

reply
Oh shit, this looks incredible. Thanks!
reply
> 13:37 - 13:49

“ayy lmao”

reply
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.

reply
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.

reply
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.

reply
What do the session hooks do?
reply
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

reply
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.
reply
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.

reply
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/

reply
That sounds very similar to just manually compacting after every message. Is there a difference I'm not seeing?
reply
Look into beads/dolt then - it does this pretty much with a cli - Jira for agents :)
reply
httpd://recursive-mode.dev
reply
[dead]
reply
[flagged]
reply