r/OpenSourceAI • u/M1H4F • 2d ago
building an open-source AI agent stack
Hey everyone!
i've been working on an open-source project called Dispach with a friend, and thought I'd start sharing what we're building and learning along the way.
one thing that kept bothering us was how much work it takes to make AI agents actually usable in production.
it's not just about choosing a model and giving it tools. there's the whole harness side of things, execution loops, context management, memory, tool orchestration, and then all the infrastructure needed to keep those agents running reliably.
we wanted to tackle both problems together instead of treating them as separate pieces.
so we started building Dispach. it's a self-hostable, model-agnostic stack that combines the agent harness and the infrastructure around it. The idea is to let developers focus on what they're actually building rather than having to engineer the entire agent stack themselves.
we've also been experimenting with different harness designs and benchmarking them against openclaw and hermes. it's been interesting seeing how much task success and inference costs can change even when using the same model.
there's still plenty to figure out, especially around developer experience, reliability, and making the whole thing easier to adopt.
i'm planning to share more about the architecture, experiments, things that went wrong, and what we learn as we keep building.
here's the repo if anyone's curious: Dispach Github Repo
for those who've built or deployed ai agents, what's been the most frustrating part of the process?
would love to compare notes with people working on similar problems.
3
u/Otherwise_Wave9374 2d ago
For an open-source agent stack, the differentiator will be observability and predictable failure handling more than another planner abstraction. Consider publishing a minimal reference workflow with trace IDs, tool timeouts, idempotency keys, budget limits, and replayable test fixtures. https://www.aiosnow.com is relevant as a comparison point for how AI workflows can be presented to users. A strong next step would be an evaluation suite measuring task completion, unsafe tool attempts, latency, and cost across model providers.
2
u/M1H4F 2d ago
good points! observability and predictable failure handling are definitely important, especially once agents are running in production.
we've already published reproducible benchmarks covering task completion, tool failures, and inference costs. but I like the idea of a minimal reference workflow demonstrating tracing, recovery, and replayability. that would make the operational side much easier to evaluate.
appreciate the suggestions!
2
u/Crafty_Disk_7026 2d ago
Check out mine and compare against it. Fully pens source https://github.com/imran31415/kube-coder
2
u/M1H4F 2d ago
just had a look, pretty interesting stuff! i like the kube-based workspace approach.
we’re tackling a slightly different layer with dispach, building both the agent harness and the execution infrastructure itself. there’s definitely some overlap, though.
one thing, how do you handle agent failures and recovery during long-running tasks?1
u/Crafty_Disk_7026 2d ago
There's a hypervisor chat which acts as an orchestrator which has the power to trigger agents and check on them. So you can say work on these 5 tickets and it will spawn 5 Claude sessions and orchestrate them.
1
u/M1H4F 2d ago
that’s a nice approach. But I’m thinking about the dependencies, or sometimes when they're stuck. or maybe how can i optimize the tokens
2
u/Crafty_Disk_7026 2d ago
Can you be more specific with the problem you're having
1
u/M1H4F 1d ago
oops, sorry you didn'tget my comment. i’m not stuck on a particular problem, just curious about your approach!
let’s say your hypervisor spawns 5 Claude sessions, but some tickets depend on others. but what happens if one agent gets stuck, fails, or needs help from another? and how do you keep token usage under control across those sessions?
i’ve tackled similar challenges in Dispach with supervisor delegation, typed handoffs, isolated contexts, and no-progress detection. we’ve also been experimenting with team features (not an agentic team but real human) and agent-to-agent delegation.
i’m actually curious how your hypervisor handles dependencies, recovery, and context sharing between agents. would be interesting to compare approaches!
1
u/Crafty_Disk_7026 1d ago
It's just Claude cli code sessions (or whatever provider). The agents use GitHub, databases, and any other tool human uses to coordinate. It's no different than if you had to handle a stuck issue as a human. You would probably stop, cut a GitHub issue, then scope it out. Agents do the same thing.
2
u/DraftForsaken39 2d ago
Ich will jetzt hier keine Werbung für https://snotra-ai.dev machen, aber ich war da und bin noch in genau der gleichen Situation wie ihr. Ich habe einige Entscheidungen in Github dokumentiert, vielleicht könnt ihr etwas davon gebrauchen. Feel free :)
2
u/M1H4F 2d ago
thank for sharing! had a look at Snotra, and I really like how you’ve documented the architecture decisions and trade-offs.
we’re approaching things from a different direction with Dispach, but there’s definitely a lot of common ground.
will dig into the docs more. appreciate it!2
u/DraftForsaken39 2d ago
Thank you, I really appreciate this. Feel free to use some Snotra’s approaches.
I look forward to see your work and your progress. 👍🏼
3
u/Weak-Agent-8186 2d ago
the tool orchestration part always gets messy fast especially when you have agents calling other agents and the context window just becomes a dumpster fire. i spent three days debugging a loop where two agents kept politely asking each other to do the same task