Flagship · 2024 – present · SynergyBoat Solutions

SynergyBoat agent platform SDK

A US EV startup scaled to 150+ B2B clients with ~40% lower dev cost and extended runway on a $2M seed.

Planner and workers diagram A central planner node surrounded by six worker nodes connected by spokes — a visual metaphor for multi-agent orchestration. Workers are labeled with primitives from the author's work: scraper, ast-edit, sandbox, text-to-sql, mcp, and eval. scraper ast-edit sandbox text→sql mcp eval planner

§ 01 The problem

A US EV startup needed to onboard 150+ B2B clients without scaling linearly in engineering headcount. The manual parts of client onboarding, catalog ingestion, and daily operations were eating every new hire. Not an AI problem — an orchestration problem. The question was whether a single platform could handle the variable work of 150 clients without one integration at a time.

The constraint the team named: stay on a $2M seed budget, avoid vendor lock-in, and produce something a non-founding engineer could extend in a year.

§ 02 What shipped

An agent platform SDK (TypeScript) with MCP protocol support, pluggable state stores (Redis and PostgreSQL), sandboxed code execution via isolated-vm and Deno subprocesses, and inter-agent communication with circuit breakers. Client workflows now run as planner-and-worker compositions on top of the SDK.

Outcomes over twelve months: 150+ B2B clients live, ~40% reduction in per-client engineering cost, runway extended on the $2M seed, and the team positioned for Series A.

§ 03 How it works

The SDK centers on three primitives: planners (LLM-backed decision nodes), workers (pure functions or sandboxed routines), and channels (the communication surface, with circuit breakers on every wire). Planners never execute untrusted code directly — they dispatch to workers. Workers are sandboxed so a misbehaving plugin can’t take down the process.

State is pluggable. Redis for hot state, PostgreSQL for durable audit trails. Clients can swap either without rewriting the planner graph. MCP support means the same workers are reachable from external AI agents without writing a new adapter each time.

Model-tier routing sits in the planner: cheap calls default to smaller models, escalation to frontier models happens only when a plan exceeds a cost-or-quality budget. This is where the ~40% cost reduction comes from.

§ 04 What I’d do differently

The first version of the planner logged too much and explained too little. Observability was noise, not signal. Second version kept only the events that would reproduce a bad decision; that made the hard debugging tractable. I should have designed for that from day one.

The MCP layer was also bolted on late. If I were to rebuild, MCP shape would be the first thing the planner spoke natively — it unlocks too many use cases to treat as an adapter.