Prospect Intelligence & GTM Architecture
A layered prospecting architecture that turns a single business URL into a researched dossier, a client-ready brief, and an approved outreach decision — with a human gate before anything reaches a prospect and outcomes fed back into the record.
01Overview
A prospecting system built as an agentic workflow with a human decision at its centre. It moves from market radar through signal detection, fit analysis, dossier creation, and a professional brief, stops at an owner approval console, and then records the outcome of whatever happened next against the prospect.
02Problem
Automated prospecting fails in two directions. Generated at volume without judgment, it produces confident, wrong, occasionally embarrassing outreach sent under a real person's name. Done manually with care, it does not scale past a few prospects a week. The research is genuinely automatable; the decision to contact a specific business, in a specific way, is not — and most tools blur that line because blurring it is what makes the demo impressive.
03David's role
- Designed the layered pipeline and the workflow state machine that carries a prospect through it.
- Built the command contract, identity and matching rules, assessment model, and dossier and report generation.
- Made the command core transport-free so the agent skill, the HTTP route, and the test suite all execute the same function.
- Built the operator surfaces — prospect dashboard, evidence detail, internal dossier, client-facing report, and approval console — desktop and mobile.
- Wrote the skill specification and deliberately staged it rather than installing it on the live runtime.
04Architecture
A staged pipeline where each stage adds evidence to a prospect record rather than transforming it in place: market radar, signal detection, fit analysis, dossier, opportunity brief, human approval, outreach, and closed-loop recording. A workflow state machine governs the legal progressions, and identity rules decide whether an incoming URL is a new prospect or a match against an existing one.
05How it works
- 01Market radar
- 02Signal detection
- 03Fit analysis
- 04Prospect dossier
- 05Opportunity brief
- 06Human approval
- 07Outreach
- 08Closed loop
- 01
Market radar
A market segment is defined and scanned for candidate businesses worth assessing.
- 02
Signal detection
Observable signals are gathered from each candidate's public surface — the things that suggest a real, addressable operational problem.
- 03
Fit analysis
Signals are assessed against fit criteria, producing findings and recommendations with the evidence that supports them attached.
- 04
Prospect dossier
An internal dossier assembles the evidence, the assessment, and the reasoning — written for the operator, including what is uncertain.
- 05
Opportunity brief
A separate client-facing report is generated: presentable, printable, and free of internal notes.
- 06
Human approval
Everything stops at the owner approval console. Nothing reaches a prospect without an explicit decision on this specific prospect.
- 07
Outreach
Approved outreach proceeds with the brief as its basis.
- 08
Closed loop
The outcome is recorded against the prospect record, so the history reflects what actually happened rather than what was intended.
06AI & technology
- Agentic research workflow driven through a Hermes skill invoking a single command surface
- Identity resolution with URL normalisation and advisory secondary matching signals
- Explicit workflow state machine governing legal stage transitions
- Structured assessment producing findings, recommendations, and linked evidence
- Separate internal and client-facing document generation from one assessment
07Integrations
- Runs inside the AIBYS Command Center, sharing its authentication, event log, and approval infrastructure
- HTTP command surface behind an operator session for programmatic submission
- Hermes skill specification staged for later installation on the runtime host
- Workspace scoping and external source-system provenance preserved verbatim on the record
08Human control & governance
- Human approval is mandatory before outreach — the pipeline is built so there is no path around it.
- Internal dossiers and client-facing reports are separate artifacts, so operator notes cannot leak into client documents.
- Provenance fields record where a record came from and never imply a working sync that does not exist.
- Assessment findings carry the evidence they rest on, so a recommendation can be audited rather than trusted.
- The agent skill is specified but deliberately not installed — staging is documented as a separate decision requiring explicit go-ahead.
09Key design decisions
The decision, the alternative it was chosen over, and why.
- 01
Decision
Make the command core transport-free: a plain function taking and returning plain objects, called identically by the skill, the API route, and the tests.
Instead of
An HTTP endpoint that the agent skill calls over the network, tested through that endpoint.
Why
It removes a whole category of failure. When the agent path and the tested path are the same function, the skill cannot drift away from the behaviour that is actually verified — the usual way agent tools rot is that the tool's real behaviour and its tested behaviour diverge quietly over months.
- 02
Decision
Generate the internal dossier and the client-facing report as two separate artifacts.
Instead of
One document with sections filtered by audience at render time.
Why
Filtering is one bug away from sending a prospect the internal reasoning about them, including the parts about why they might not be worth pursuing. Two artifacts from one assessment makes that leak structurally impossible rather than conditionally unlikely.
- 03
Decision
Put the approval gate before outreach and give it no bypass.
Instead of
Confidence thresholds that auto-send when the assessment scores highly enough.
Why
The cost of a bad outreach is asymmetric — a wasted send is cheap, a damaged reputation with a real business is not, and the assessments most likely to score highly are exactly the ones built on the most plausible-looking wrong evidence. The approval is not friction in the workflow; it is the workflow.
- 04
Decision
Specify the Hermes skill fully but stage it rather than installing it.
Instead of
Installing it on the live runtime once the repository side passed its tests.
Why
Repository-side complete and safe-to-install on a running host are different claims. Writing the specification and stopping keeps the boundary explicit, and means the installation is a decision someone makes rather than a side effect of a merge.
10Tradeoffs
- Mandatory approval caps throughput at the operator's attention. That ceiling is intentional, and it is a real constraint on volume.
- A transport-free core means the command surface cannot use request context directly; everything it needs must be passed explicitly, which is more verbose and much easier to test.
- Two generated artifacts mean two things to maintain when the assessment model changes.
- The skill being staged rather than installed means the end-to-end agent-invoked path is specified and tested at the repository boundary, not exercised on a live runtime.
11Outcome
The repository-side implementation is complete and tested: command contract, identity and matching rules, workflow state machine, dossier and report generation, and the full operator surface. A sixteen-step scripted verification pass drives the whole path — empty dashboard, command submission, evidence detail, assessment findings, approval console, outcome recording, populated dashboard — and repeats the critical screens on mobile. The Hermes skill is specified and staged; installing it on the runtime host remains a deliberate, separate step.
12Evidence
- Verification pass
- 16 captured verification screens covering the full golden path plus four mobile screens for dashboard, detail, client report, and printable report.
- Test suites
- Golden-path, domain, and synchronisation test suites executing against the same command function the agent skill calls.
- Skill specification
- A written command specification that states in its own header that it is staged and not installed, and that no live runtime host was inspected or modified.