How the mesh thinks.
A request enters the mesh, gets decomposed into typed subtasks, is routed to specialist experts, executes in parallel where possible, and is aggregated into a single coherent response.
One mesh. Every modality. Infinite composition.
Our research direction: a routing core that composes specialist models, blends their outputs, and reasons across modalities. This is the architecture we are building toward — not a deployed system.
preview
Six stages, end-to-end.
1 · Decomposition
The router parses the incoming request, identifies modalities, and breaks it into a directed graph of typed subtasks with explicit dependencies.
2 · Routing
Each subtask is matched to the most appropriate expert model based on capability, cost, latency, and the confidence of the routing classifier.
3 · Expert Communication
Experts read from and write to a shared context store. Outputs from one stage become typed inputs for the next, mediated by the router.
4 · Parallel Execution
Independent branches of the subtask graph are dispatched concurrently. Dependent branches wait on their predecessors before executing.
5 · Aggregation
Partial outputs are validated, reconciled, and merged. The aggregator produces one coherent multimodal response — and a full execution trace.
6 · Workflow Loop
For long-horizon agentic tasks, the aggregated state is fed back into the router, enabling planning, self-correction, and tool use over many turns.
What this architecture buys us.
A monolithic LLM treats every request as one forward pass. SutraMesh treats a request as a graph of subtasks over a pool of specialists. That shift produces three properties we care about:
- Efficiency. Small subtasks never reach the biggest model. Most tokens route to cheap, fast specialists.
- Capability. Domain experts outperform generalist models on their narrow tasks. Composition surfaces those gains system-wide.
- Interpretability. The execution trace is a real artifact. Every routing decision, expert call, and aggregation step is inspectable.
Open research questions remain everywhere — calibration of router confidence, scheduling of dependent branches, sharing of context across experts, failure modes under distribution shift. The architecture is a frame; the work is in filling it in.
Read the router design notes.
The lightweight router is the centerpiece of the architecture. We have a dedicated page on what we think it should and should not do.