Context switching, not coding, became my bottleneck. So I built an agent manager for Claude Code.
Coding wasn't our bottleneck. Context switching was.
We're a small team building a product, and writing code is only part of the job.
While Claude Code or Codex is implementing something, I'm switching to marketing, design, or customer calls. When I come back an hour later, it's usually one of two things: I've completely lost the implementation context, or I never really let go of it and nothing else got done.
Coding stopped being our bottleneck a while ago. Context switching is the bottleneck now.
What we built
Galda. You queue up 10 tasks, walk away, and come back to tested, review-ready PRs.
What you want to know when you come back is fairly predictable: what changed, why, what was tested, and where to start looking. Galda puts that on one page per task. The PR and the local environment details are on the same page, so you're not rebuilding the state from the Git log.
No extra model API required. It runs on the Claude Code or Codex subscription you already have, your skills keep working, and it schedules the work so you're less likely to run into the 5-hour or weekly usage limits.
The design decision we spent the most time on
We started out trying to make the orchestration layer smart. Decomposing tasks, reshaping instructions before handing them off. Each addition looked reasonable on its own, and each one broke workflows that had been working ten minutes earlier. The frustrating part was the failure mode: the agent was doing exactly what it had been told, just not what we thought we had written.
So we went the other way. Galda doesn't rewrite your prompts and doesn't ask you to write tasks in a Galda-specific way. What's configurable is Galda's own behavior, not the agent's.
That decision made the product simpler and more reliable at the same time. If someone tells us to make this layer smarter, it's the one thing we'd push back on.
What we'd like to hear
There are certainly workflows this doesn't handle well yet. If you're using Claude Code or Codex in real work, we'd like to know where a layer like this would break for you.
Free to try: https://galda.app
What stood out to me is that you're treating context as something worth preserving, not something users should have to reconstruct.
That changes the product from helping with execution to helping maintain continuity, which feels like a much deeper shift than simply managing multiple agents.
we started out optimizing for execution speed, but the thing actually eating my time wasn't waiting for the agent to finish. it was picking the thread back up afterwards.
have you run into the same thing?
I have, which is why your comment stood out to me in the first place.
I'd rather not reduce my perspective to a few comments, though. I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
thanks! x is the easiest place to reach me, so if you follow me there (@Leonbuild) we can just talk in DMs. happy to share my email instead if that's easier for you.
Thanks, I appreciate that.
I don't really use X for conversations like this. If it's easier, I'd be happy to continue by email instead. What's the best email to reach you on?
thanks!
i'd love to hear from you. just send an email to [email protected]
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The decision not to rewrite prompts is exactly right. Context switching cost doesn't come from the agent - it comes from YOU rebuilding your mental model. Every smart orchestration layer that "helps" by rewriting tasks actually creates a second problem: now you have to debug why your task turned into something different. Keeping the agent's behavior predictable and moving the configurability to the orchestration layer (when to run, batching, retry logic) is the cleaner architecture. Most teams overfit to agent optimization when they should be optimizing for human context preservation instead.
The paradox was that the more we tried to help by summarizing the task or cleaning up how it was worded, the more painful the context switch became when I came back to it.
Which makes me want to ask you something. Do you think the sections in the review doc should be user-defined as well, rather than fixed?
Right now we ship a fixed set meant to be generic and easy to scan (Summary, Open it, What to check, and so on) and honestly it hasn't caused any real friction yet. But if I follow your reasoning all the way, fully configurable seems like the more consistent answer.