I recently saw DeepSeek’s SuperAgent and found myself talking again about what we’d been building. The discussion of coordinating work, dividing tasks and keeping them running felt close to some of what we’d been doing locally.
We already use a dedicated Codex conversation to coordinate work. It takes requests, breaks them down and hands them to other conversations. We built a local way to manage project context, set rules for collaboration, and gradually added events and scheduled triggers.
That comparison made me want to look back at how our setup took shape, what it has solved in practice and what problems are still with us.
Starting with local context
I’ve been experimenting with personal agents since the first half of this year, starting with OpenClaw. I later tried Hermes and other products, and explored memory, retrieval and ways to connect local tools like Obsidian.
I’d been thinking about context management for a while. At first, I kept one folder per project and stored progress, current status and supporting material in plain Markdown. If I moved to a new conversation, I could still see what had happened and where the project stood.
Many of those projects had a natural stopping point. I might spend a stretch exploring an open-source product, then wrap it up without needing to work on it intensively every day.
But I was also using several agents at once: Codex, Claude, Hermes and others. Different models suited different jobs, and I had subscriptions and compute limits to consider. A project I worked on in one tool today might continue in another tomorrow.
Even within one product, there were different sessions and agents. Project context had to travel between them.
We built FLG to handle that. Think of it as a local record of project context and a set of rules for keeping that record up to date. Agents in different tools and conversations can pick up from the same project state.
There’s a practical wrinkle here. Much of my work is in operations, marketing and moving projects forward. The facts and the situation change quickly. One piece of information can make yesterday’s judgment worth revisiting.
So it wasn’t enough to record what we planned to do. In FLG, we put a lot of weight on decision logs: why a judgment made sense, which options we had already considered and what would make us reopen the question.
Otherwise, a new agent might suggest an option we had already discussed and dropped. The reason we dropped it is exactly the context we need to make the next decision.
By July or August, we had most of this in place. Projects could continue across tools and conversations, but I was starting to notice another problem.
I needed one conversation to come back to
The longer a project ran, the more conversations accumulated in the sidebar. Seven, eight, nine, then more. I started to lose track of what mattered.
The context was already on disk, and the agents could organize it well. I still didn’t always know which conversation to open. Should I continue this discussion where it started? Should I split it off? If so, how?
I also had to remember what we had worked on recently, what had finished and what deserved a closer look. Managing the conversations was becoming work in itself.
In August, we designated one Codex conversation to coordinate the whole project. My reasoning was simple: I needed a specific conversation to go to. I could start there without deciding where the request belonged.
Earlier in the year, we had already used subagents in OpenClaw to hand work to other agents. In Codex, we made that division of labor part of a project entry point we kept using.
The coordinating conversation takes what I say in ordinary language, works out how to handle it and decides whether to resume an existing conversation or start a separate conversation for it. The work goes out, and the result comes back.
When something takes a single round, we can archive it once it’s finished and keep the sidebar clear. When it needs several rounds, I sometimes switch straight to the conversation handling the task and stay involved. That conversation reports progress and results back to the coordinator.
I have expectations for these tasks: how far they should go, how much I should be involved and whether I can review and accept the result. We work those expectations out as we go.
That’s where FLG fits. Conversations can split and tools can change, while confirmed project state and decisions carry forward. The coordinating conversation organizes the work in front of us. FLG helps preserve the context we’ll need later.
We went on to add events, hooks and scheduled triggers. People still initiate most work, but some tasks can now resume when information changes or when a scheduled time arrives.
That’s how the setup evolved, one change at a time, through use.
Once the tasks were running
So when I saw SuperAgent, a lot of it felt familiar. Taking in work, distributing it and collecting the results are things we’ve been doing in our day-to-day work for a while.
Looking at the implementation, there are differences too. DeepSeek’s prototype puts task state, event triggers and recovery after interruptions into the runtime. We’ve mostly built on top of existing agent products, connecting our work through protocols, local records and some automation.
We can make those parts more robust. In practice, though, the problems that bother me most often show up when a person needs to get involved.
My work involves complex projects, relationships, resources and trade-offs. A change in one place can affect several others. You have to keep making judgments about what to do next.
Meanwhile, agents can start a lot of work very quickly. One is doing research, another is developing a proposal and a third has come back with a result. They’re all moving forward, and something else can arrive without warning.
After a while, I sometimes lose track of what I’m doing, what we’ve actually moved forward recently and which thing deserves more time.
The point of a coordinating conversation was to cut through the clutter and help me focus. It did improve how work comes in and gets assigned. As more work arrives at once, I still run into limits on how much I can pay attention to and how easily I can switch contexts.
Say I’m building a prototype that still needs exploration and debugging, and I’m also writing a proposal. Those two things alone are already hard for me to work on deeply at the same time.
The frequency of feedback may have something to do with it. When an AI task takes longer, the gaps give me some room to switch to something else. But if six or ten tasks are running and results keep arriving for review, along with decisions I need to make, switching gets much harder.
The work I can turn into a defined process and leave AI to carry through tends to be relatively predictable. A lot of my work still needs repeated adjustments as the situation changes, with a person involved throughout.
Someone might say we should define clearer rules about what to do when a condition changes. That kind of engineering helps, and we already do it.
Once a person is in the loop, other things affect how the work proceeds. Can they keep up with the feedback? Do they have the energy to think it through? Is their attention already tied up somewhere else?
Plenty of outside factors affect how I’m doing. The system can keep running as configured. I can’t always bring the same focus or energy to it.
In this workflow, I think the person can sometimes be the biggest bottleneck, even the one holding things up.
Choosing breadth or depth for the stage you’re in
With AI, it can feel as though we can handle a huge amount of work in parallel. When I’m dealing with a particular piece of work at a particular stage, I still think I have to choose between breadth and depth.
Suppose I have an important presentation that afternoon. The materials aren’t good enough yet, and new information means I have to make changes quickly. I’m probably going to put my attention on that one thing.
Other tasks might keep running, but I can’t afford to keep putting attention into them.
That choice is for the stage I’m in. A person can do different things at different times, and can be good both at coordinating work and at going deep. If I need to think through one difficult thing properly right now, I have to accept that I can’t go deep on several other things at the same time.
Memory, project boards and proactive reminders can tell me where things stand. To get into a proposal, understand its trade-offs and revise it to a standard I’m comfortable with, I still need a stretch of largely uninterrupted attention.
It reminds me of a situation at work: one person sets the acceptance standard and is also responsible for keeping all the work moving. Once that person is accountable for progress, they may start lowering their own standard without noticing it.
Setting the standard takes depth. Keeping work moving means looking across a wider area. Give both jobs to the same person at the same stage, and each starts to affect the other.
For me, coordination and the engineering around it already have practical value. Different agents can pick up the same project, and I no longer have to manage the division of work across every conversation myself.
As we keep designing this workflow, I need to account for what a person can handle. How much work should I start now? Which task deserves a closer look? What kind of attention do I need to give it? Those are still judgments I have to make.