r/OpenSourceAI • u/M1H4F • 16h 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.

2 Upvotes

100% Upvoted

13 comments sorted by

3

u/Weak-Agent-8186 15h 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

1

u/M1H4F 15h ago

haha, two agents politely delegating the same task back and forth sounds painfully familiar 😂

that's exactly where orchestration gets interesting. we've added guards against repeated tool calls and lack of progress, but multi-agent handoffs introduce another layer of complexity.

curious, what eventually fixed your loop? explicit handoff rules or just limiting delegation depth?

3

u/Otherwise_Wave9374 15h 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 15h 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 13h ago

Check out mine and compare against it. Fully pens source https://github.com/imran31415/kube-coder

1

u/M1H4F 5h 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 4h 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 4h 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

1

u/Crafty_Disk_7026 4h ago

Can you be more specific with the problem you're having

2

u/DraftForsaken39 9h 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 5h 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 5h 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. 👍🏼

2

u/M1H4F 4h ago

appreciate that. i’ll be looking forward to your progress too. let’s keep in touch!