The Automation Agency
Case study

Match engine

A generic two-sided matching engine, with founders and investors as the first instance.

AI workflowChatbotIntegration

Context

Own product, in progress. Built to be sold as a fixed-price build plus retainer to organisations that own a network — accelerators, syndicates, membership bodies, founder communities. The matching layer is mine and general; the first instance it runs is founders to investors.

The problem

An organisation that owns a network has the same problem whichever network it is. Members want introductions. The introductions that work are the ones someone senior would have made by hand, and nobody has time to make them at volume. Meanwhile the scarce resource is not the algorithm — it is attention on the other side, which has to be rationed fairly rather than spent on whoever applied most recently.

What I'm building

  • One intake brain, three transports. A pure function takes conversation state and a message and returns the next state and the next question. Web form, WhatsApp and an outbound voice call all drive the same function and write the same profile, which is what makes it testable without a phone line.
  • A question set as configuration, so the same intake produces an investor's thesis summary as easily as a founder's profile. That is the proof the engine is genuinely two-sided rather than one-sided with a mirror bolted on.
  • Matching in stages, all logged — hard filters, then vector recall over embedded profiles, then scored reranking that returns reasons for and against each match, not just a number.
  • Allocation with capacity, so introductions are distributed across the scarce side according to how many each can absorb per period, rather than concentrating on the most visible names.
  • A feedback layer recording what happened to every introduction, so response rates are learned rather than assumed.

Stack

Next.js 15 · Supabase Postgres with pgvector and HNSW indexes · Anthropic (extraction, reranking, intro drafting) · Voyage or OpenAI embeddings · Twilio Voice and WhatsApp.

Hard parts

Explainability is a product requirement, not a nicety. An introduction a member cannot see the reasoning for is one they will not act on, so every match carries three reasons for and one against, and scoring keeps each component alongside the total rather than collapsing to a single figure.

Fair allocation is the part that is actually hard. Ranking a hundred investors for one founder is straightforward; allocating thousands of founders across a hundred investors, within monthly capacity, without starving anyone, is a different problem — and it is the one an operator running a real network cares about.

Status

Schema, investor ingest and the embedding and scoring clients exist. Intake, matching and the voice transport are next.

Next step

Twenty minutes. No pitch, no pressure.

If something here is close to what you need, bring the problem and I will say how close. If it is not, I will say that instead.