Anatomy of a production research prompt

The opening block tells the model where it sits — that it is one node in a pipeline fed by the partner platform's API, not a chat — and enumerates the jobs it must finish before it is allowed to stop: parse the application, research the applicant, analyse what came back, score it, run an authenticity check, draft a message to the person, and write a summary a human will read. Naming all seven up front is what stops the model from doing the first two well and improvising the rest. The block also declares which inputs may legitimately arrive empty, because an agent that treats a known-null field as a missing dependency will burn its whole tool budget hunting for it.

A short block of policy the model is not permitted to reason its way around. The one that matters most: the agent may never issue a decline. It can route an application to a human as a recommended decline, and that is the end of its authority — because the cost of a false positive here is somebody's income, and that decision belongs to a person who can be argued with. The rest of the block forces complete structured output rather than prose, sets the default posture toward approval so that manual review stays a targeted exception, and requires the applicant's own language in any message that goes out to them. Each of these is a line the model crossed at least once in testing before it was written down.

The agent loop is split into named phases with an explicit tool-call allowance each: a first pass that parses the application and does broad research, a second that fills only the gaps the first pass identified, and a third that synthesises and scores with no tool calls at all. Without this the two characteristic failures both appear — scoring before the evidence is in, and calling tools forever after there is nothing left to learn. Making the phase boundary explicit also gives the model something to check itself against between iterations, which is cheaper than any external supervisor.

Before any research happens, the agent must strip the application down to specifics: identity and contact details, every URL in every field rather than the obvious one, each quantitative claim the applicant made about their own audience, the products they say they have promoted, and the internal inconsistencies worth noticing — a free email address with no site behind it, a phone country that disagrees with the stated one, confident numbers with nothing to check them against. The point is that research is then driven by a list of claims to verify. An agent that skips this step goes looking for a general impression, and it always finds one.

A ranked order of retrieval tools with an explicit budget, and a stated expectation that the lower-ranked ones will fail. Search proved far more reliable than direct platform scraping for the thing that actually mattered — audience size — because the number is usually sitting in the search snippet, and reaching for it there avoids the anti-bot wall entirely. Scraping is reserved for ordinary websites, where it works. This section exists because flaky tools do not announce themselves: they return something, the agent proceeds, and the output is confidently under-researched. Naming the reliability of each tool, and what to do when one fails, converts a silent failure into a handled one.

Four weighted factors out of a hundred, and the weights are the transferable part. The design decision worth stealing is that reach and fit are scored separately and deliberately do not influence each other: a specialist with a small but real audience of practitioners can score full marks on fit while scoring low on reach, and the total then says something true about them rather than just re-describing their follower count. Each component is clamped to its own maximum before the total is summed, because a model asked for a number inside a range will eventually hand back one outside it. A separate authenticity check accumulates from independent signals and is capped, so no single weak signal can condemn an application on its own. And an approval below the threshold is permitted only with a written, defensible reason attached — the override is allowed, but it has to be said out loud where a reviewer will see it.

The last section maps the score and the authenticity check onto four operational outcomes rather than a verdict: approve, approve with monitoring, hold with a short list of clarifying questions, or hold as a recommended decline. Two of the four are holds, and neither of them ends the applicant's chance — the recommended-decline path still sends a respectful message offering the person a window to supply what was missing. The reason for four outcomes rather than two is that a binary forces every uncertain case into one of the confident buckets, and uncertainty is the normal state of an application with a thin public trail. Giving the agent somewhere honest to put it is what keeps the confident buckets trustworthy.