LeadsON: automation with a clear chain of responsibility.

B2B prospecting is a long-running process wearing the costume of a series of tasks. Research feeds qualification. Qualification feeds outreach. Outreach produces replies that arrive out of order, at inconvenient times, from people who remember nothing of the context. Replies change what should happen next. Meetings need to be booked, prepared for, recovered when they fail. A system that cannot carry state across all of that is a demo, not a tool.

The interesting engineering question was never "can a model write a good email." It was whether a multi-agent system could run the whole arc, research, scoring, outreach, response handling, scheduling, operator oversight, while remaining predictable enough that a person could trust what it had done and see what it would do next.

I built LeadsON to answer that question at a scale where the answer would mean something. It was an independent project and the broadest test I could give the agentic-AI engineering practices I had been developing.

The platform is a four-application TypeScript monorepo: a Next.js operator console, a Fastify API, a worker, and a CLI. Between them sit 16 specialized agents and more than 25 BullMQ queues driving an 18-state deterministic workflow: the conversation lifecycle made explicit as states a person can name, inspect, and interrupt.

The division of labor is the design. Models handle generation and classification: the bounded judgment tasks where flexible reasoning earns its variance. Application code retains state transitions, scheduling, approval points, retries, and authoritative writes. An agent can draft, score, or classify. It cannot promote its own output to truth.

Underneath, the platform uses hexagonal architecture with more than 25 typed port interfaces and dependency injection, so providers and infrastructure are swappable at the boundary rather than threaded through the domain. A live schema reference from January 2026 records 49 tables and 566 columns across multi-tenant Postgres with row-level security and pgvector retrieval.

Multi-provider routing across OpenAI, Anthropic, Gemini, and local inference added integration surface, but it bought independence from any single vendor's behavior and pricing, and forced a discipline that turned out to matter more: structured output parsing, prompt versioning, fallback handling, and per-call cost and latency tracing. When the provider layer is abstracted early, evaluation and observability become natural rather than bolted on.

The harder trade-off was scope. A narrower tool would have shipped sooner and demonstrated less. I chose the harder path, building the whole conversation workflow rather than one polished slice, because the thing I wanted to prove was the operating pattern: that agentic systems can be engineered to enterprise standards of control, auditability, and review. That choice cost months and produced a system validated across 1,700+ tests and 196 requirements.

Human approval is configurable rather than universal, because the right amount of oversight depends on the tenant, the campaign, and the risk of the action. A blanket gate would have been simpler to build and wrong for the domain.

LeadsON demonstrates sustained system design and implementation at production-oriented scope: multi-tenant architecture, agentic orchestration, retrieval grounding, resilience controls, observability, and a validation harness across nearly two hundred requirements.

It does not demonstrate external enterprise deployment; no customer ran this system. The figures above describe engineering scope and validation, not commercial traction. CaseFlow is the published companion built to the same control philosophy, for anyone who wants public source.

Active development ended in May 2026. It is the largest single piece of work behind the engineering foundation. I am now focused full-time on joining a team that wants enterprise delivery owned end to end.

The architecture proved its thesis, and it also taught me where the weight sits. Approval policy should have been a first-class tenant capability from the start rather than earned through iteration. And the gap between a production-oriented system and a production system is real: deployment automation, tenant operations, and live-traffic hardening are a different discipline than the build itself. That gap is what CaseFlow's published production boundary is about.