A prospecting engine where the model writes the query, never the data

The challenge

The firm had built an internal tool to find and qualify prospective clients. It produced convincing output: named companies, named people, plausible contact details, a relevance score and a short rationale for each.

The problem surfaced during use. Some of the contacts did not exist. The model had been asked to produce prospects, and producing prospects is exactly what it did — including when it had nothing to work from.

This is a failure mode worth naming precisely, because it is not a bug that can be patched. A system that fabricates convincingly is more dangerous than one that fails visibly, because the failure is discovered by the person on the other end of the outreach.

The engineering problem

The architecture had given the model the wrong job. It was being used as a data source, when what it is actually good at is interpretation — turning a vague human description of an ideal customer into a precise, structured query.

The redesign question was therefore not "which model" or "what prompt", but where the boundary between generation and retrieval should sit, and how to make it impossible for that boundary to move by accident.

The approach

We inverted the responsibilities.

The model's only job became producing a search specification: an explicit, inspectable structure describing what to look for — sector, size, geography, signals, exclusions. That specification is shown to the user and can be edited. It is a hypothesis, and it is treated as one.

Every row of actual data comes from a verified source through its own API. Records carry provenance: which source, retrieved when. The model is then allowed to score and explain results — but scoring is a judgement about a record that already exists, and every record can be traced back to where it came from.

The invariant is simple enough to state in one line, and it is enforced in the pipeline rather than in a prompt: the model may describe what to look for and may comment on what was found, and it may never be the origin of a row.

The solution

The platform is multi-tenant, with each tenant's specifications, sources and results isolated. That was decided at the data model stage rather than retrofitted, because tenancy in a product that stores prospect data is a security boundary, not a filter.

Specifications are reusable and versioned, so a definition of an ideal customer becomes an asset the team refines rather than a prompt someone rewrites each time. Runs are reproducible: the same specification against the same sources returns a comparable result set, which is what makes it possible to tell whether a change improved anything.

Technology

• LLM-generated search specifications, surfaced to the user as editable structured data
• Retrieval exclusively from verified third-party sources, with per-record provenance
• Structural separation of the generation path from the data path
• Multi-tenant isolation designed into the data model
• Reproducible runs with versioned specifications

Business value

The output became something the team could act on without verifying each row first — which is the only state in which a tool like this saves time rather than moving it around.

The secondary benefit was unexpected and larger: because specifications are explicit and editable, the definition of a good prospect stopped being tacit knowledge held by one person and became something the team could argue about, refine and reuse.

Key learnings

Give the model the job it is good at. Interpretation, structuring and explanation — not being a source of truth.

Guardrails belong in the architecture, not the prompt. If the only thing preventing a failure is an instruction, the failure will happen and you will not have a log of it.

Decide tenancy before the schema. It was the cheapest decision in the project at the point we made it, and it would have been among the most expensive six months later.