VDS smart consulting

What it does

Before a small company changes course, it needs market research and a financial case, and usually it can't afford either. You give our system a company profile: products, financials, goals and risk appetite. A Planner agent turns that profile into a scored list of research topics. A swarm of research agents (scout, collector, analyst, verifier) works through those topics on the live web using Tavily. An analysis pipeline then turns the findings into a costed business plan: scenarios that always include a "do nothing" baseline, investment ranges, a build-vs-buy verdict and a risk register. The plan appears on one dashboard. Every claim links to a source. The LLM never does arithmetic: it picks the assumptions, and tested TypeScript computes every number from them.

How the agents run concurrently

- Who runs at the same time: after a human approves the topic list, worker slots run in parallel. For example: 2 scouts, 1 collector, 2 analysts and 1 verifier. The slot counts can be changed. Different slots can work on different topics at once, and a "deep" topic gets a collector, an analyst and a verifier working on it together. Alongside them run code-only participants that react to events without an LLM: the Allocator, the Meter (turns token usage into money spent), the Cartographer (streams events to the dashboard) and the Operator (human approval checkpoints). - Shared state: there is one Mozaik runtime with one shared RunState: topics, findings, sources, assumptions, scenarios, slots and spend. Each collection has exactly one writer. Only the Allocator writes slots and spend, only research writes findings and sources, and only analysis writes assumptions and scenarios. Everything that crosses between teams is checked against JSON Schema contracts. - Coordination: agents coordinate through events, with no central loop calling them. For example, a scout emits topic.scored, and the Allocator then promotes the topic to deep or shallow research, or drops it if relevance falls below 0.3. A dropped topic reopens only if it is re-scored clearly above that line, so topics don't flip back and forth. Workers report topic.progress, task.finished, research.gap and reassignment.requested. The Allocator answers with task.assigned for a slot, choosing the highest-priority topic that still needs that role. Each assignment creates a fresh agent with a clean context and a short handoff note, and the old agent leaves. Slots are stable; agents are disposable. A minimum time on a topic and a cap on reassignments stop agents from jumping around too much.