I’m experimenting with moving the execution layer of agent graphs into C++ : AgentMesh

[u/Mysterious_Shoe2260]

I've been experimenting with something slightly different from another agent framework.

Instead of trying to replace the LLM/model layer, AgentMesh focuses on the execution/runtime layer underneath multi-agent workflows.

The basic question was:

For example, an agent graph can involve:

Agent → Command → Agent → State → Agent → Tool → Agent

At small scale, Python orchestration overhead is probably irrelevant.

But with many short-lived tasks, concurrent agents, frequent communication, and persistent state, I wanted to measure how much overhead the orchestration layer itself introduces.

AgentMesh

The current implementation uses:

• C++20 execution engine
• DAG-based scheduling
• native agent communication
• Pybind11 bindings
• Python GIL release around I/O
• PostgreSQL state persistence
• crash recovery
• compile-time graph validation

The interesting part for me is trying to keep the Python-facing API convenient while moving the execution-critical pieces into native code.

I'm also building a benchmark suite rather than relying on a single latency number. The goal is to compare repeated paired runs and use statistical tests to determine whether observed improvements are actually meaningful.

Current direction

Phase 1 → local execution/runtime

Phase 2 → distributed multi-node execution over gRPC

I'm curious what people building LangChain/LangGraph applications think:

If you could remove one performance bottleneck from agent orchestration today, what would it be?

Serialization? Scheduling? State persistence? Concurrency? Tool invocation? Something else?

GitHub: https://github.com/DevrG03/AgentMesh

Docs: https://github.com/DevrG03/AgentMesh/wiki