Roadmap and plans

Everything in this module is a plan. These pages describe systems that are proposed, partially built, or superseded. They are not a description of what runs today.

For what is actually deployed, read System architecture, Business logic, and Lambda functions. Where a plan and a reference page disagree, the reference page is right.

These documents were written to think through a channel before building it. They are kept because the reasoning is still useful — the segmentation logic, the message sequencing, the handoff rules — even where the implementation went a different way.

Documents

Plan	Status	Contents
Target system architecture	Partly built	The intended end-state: a multi-agent estate across email, voice, LinkedIn, and content, coordinated over shared contact state.
Enrichment agent	Built	Discovery, contact enrichment, and scoring. Shipped as enrichment-scraper and enrichment-scorer.
Email agent	Partly built	Sequence generation, sending, and reply handling. Only reply classification shipped — see email-agent.
Voice agent	Not built as designed	An autonomous outbound caller on Retell AI. The deployed system instead supports human reps through daily call lists and a Five9 dialer.
LinkedIn agent	Not built	Connection requests, InMail, and engagement-based sequencing.
Content agent	Not built	Inbound content generation and distribution.
Paid ads	Not built	Paid acquisition alongside outbound.
Re-engagement reporting	Not built	A catalogue of reports to measure whether the five re-engagement segments produce calls, connections, and pipeline — plus the enrolment-log gap that blocks most of them.
BDR playbook	Operational	How three BDRs work a Five9 parallel dialer. Process documentation rather than a system design, and the closest of these to current reality.

Plan

Status

Contents

Target system architecture

Partly built

The intended end-state: a multi-agent estate across email, voice, LinkedIn, and content, coordinated over shared contact state.

Enrichment agent

Built

Discovery, contact enrichment, and scoring. Shipped as enrichment-scraper and enrichment-scorer.

Email agent

Partly built

Sequence generation, sending, and reply handling. Only reply classification shipped — see email-agent.

Voice agent

Not built as designed

An autonomous outbound caller on Retell AI. The deployed system instead supports human reps through daily call lists and a Five9 dialer.

LinkedIn agent

Not built

Connection requests, InMail, and engagement-based sequencing.

Content agent

Not built

Inbound content generation and distribution.

Paid ads

Not built

Paid acquisition alongside outbound.

Re-engagement reporting

Not built

A catalogue of reports to measure whether the five re-engagement segments produce calls, connections, and pipeline — plus the enrolment-log gap that blocks most of them.

BDR playbook

Operational

How three BDRs work a Five9 parallel dialer. Process documentation rather than a system design, and the closest of these to current reality.

What shipped, and what changed on the way

Three differences between these plans and the deployed system are worth stating plainly, because they explain most of the divergence.

The voice agent became a human enablement system: The plan describes an AI agent making outbound calls autonomously. What was built assumes a human on the phone and spends its effort on deciding who they should call and why — BigQuery segmentation, priority scoring, round-robin assignment, task creation, and escalation. The AI in the deployed calling path is confined to enrichment, scoring, and line intelligence.
The email agent shrank to a classifier: The plan covers generation, sending, warm-up, and reply handling. The deployed email-agent does one thing: classify an inbound reply into an EmailTargetCategory using Bedrock structured output. Sending is handled by the web application; this repository only reacts to what comes back.
The enrichment agent shipped close to plan: It is the one design that survived largely intact — SmartScout discovery into a FIFO queue, Claude with Tavily and HubSpot MCP tools for contact enrichment, then a second pass for the payout-pain score.

Using these pages

Read them for intent and for the domain reasoning, not for interfaces. Payload shapes, model ids, table names, and function names in these documents are frequently out of date — the authoritative versions are in Event catalog, morpheus-llm, and Data.

When a plan is implemented, the durable content belongs in business, lambdas, and events. Leave the plan in place, and mark what changed rather than editing the plan to match the outcome — the gap between the two is often the most informative thing on the page.