Before you start: you don't have to do any of this by hand.

Everything in this article is a skill Eva already has. She can write a new Research Agent with you, rewrite an existing one to this standard, review whether the Effort level is right, find agents that overlap and merge them, and retire the ones that no longer earn their run.

What she needs from you is scope. Tell her which ecosystem, which verticals, and what you're trying to achieve, and she'll work through it with you step by step, confirming before she changes anything.

This article is for when you want to understand why the guidance is what it is, so you can judge her output rather than just accept it.

A Research Agent is a question you're paying to have answered on every Account or Contact it runs against.

When it's written well, it comes back with a named programme, a date, and a source, and your rep opens the record already knowing what to lead with.

When it's written badly, one of two things happens. Either it returns a confident paragraph built on a generic "we are committed to innovation" line from an About page, which is worse than nothing because your rep believes it. Or it returns nothing useful on every run, and you're spending credits to learn that.

The goal is not to make every agent comprehensive. The goal is to make each agent precise, economical, and useful to the rep receiving the result.

Every well-built Research Agent has the same five parts, in the same order, inside the Instructions field:

The rest of this article covers each part, then the maintenance work: Effort, Speed, merging, and retiring.

Every agent opens with a complete question. Not a topic, not an instruction, a question.

Account Research Agents start with:

Is the company publicly investing in or implementing a demand forecasting, replenishment optimisation, or inventory planning platform?

Was the company recently involved in a regulatory enforcement action, remediation programme, or Consumer Duty implementation?

Contact Research Agents start with:

Is the contact publicly identified as the owner of an active Customer Experience or Voice of Customer programme?

Did the contact recently take on a transformation, data, AI, analytics, or P&L mandate?

Not every Contact Research Agent is a signal. Some are built to produce a structured profile or career summary rather than answer a binary question. These don't need to start with Is, Did or Was. They open with a descriptive intent statement instead:

What does the contact's career profile and trajectory reveal about how they operate, how long they stay, and how they typically move?

Immediately after the opening question, use this exact line:

It's a small thing. It keeps every agent in your environment laid out the same way, which makes the instruction easier for the agent to follow and much easier for you to audit later.

Tell the agent which pages to open first.

For account research, relevant page types include: Investor Relations, Annual Reports, Governance, Newsroom, Careers, Products, Technology, Operations, Customer Experience, Supply Chain, Strategy.

For contact research, relevant sources include: LinkedIn profile, Experience section, About, Featured content, Posts, Articles, public speaking pages, company leadership pages, event biographies.

Only list the sources that are relevant to this question. Sending every agent to every page is how you turn a Low effort agent into a High effort one for no extra insight.

This is the step most people skip, and it's the one that decides whether you get real signals or polished guesswork.

Strong evidence usually includes:

Tell the agent to prefer active execution language: implementing, migrating, deploying, rolling out, launching, standardising, consolidating, remediating, delivering, piloting.

And tell it explicitly what to reject: "we believe", "we aim to", "we are committed to", "we continue to explore", "customer-centric", "digitally enabled", "data-driven". Generic positioning is not evidence of an active programme.

Write the queries yourself rather than leaving the agent to invent them. Useful operators:

Examples:

If the primary sources come back inconclusive, name the external sources that suit this particular question: trade press, financial press, regulator publications, vendor case studies, partner announcements, earnings-call transcripts, investor presentations, conference agendas, podcasts, executive interviews, public job postings, corporate filings, event biographies, customer notices, service-status pages.

Then ask the agent to confirm four things: the correct company or contact, the publication or posting date, whether the evidence is current, and whether it describes an active initiative or only a historic event.

Use it word for word, including the spelling. Don't add defensive instructions after it that repeat rules you've already set. Repetition at the end of a prompt tends to dilute the earlier steps rather than reinforce them.

Don't use any of these:

Use natural language instead: "the company website", "the company's Investor Relations pages", "the contact's public LinkedIn profile", [company name], [domain].

The agent already receives the Account or Contact context at runtime.

Variables in the instruction body add a potential failure point without really adding anything to the agent's context.

State the recency window explicitly whenever the signal is time-sensitive. Sensible defaults:

NB: Recency must come from a date visible in the source. A current-looking webpage, an undated biography, or a search result with no publication date are not dates. Say so in the instruction, because otherwise the agent will treat "this page exists today" as "this happened recently".

There are four output patterns. Picking the wrong one is the most common reason an agent's results are hard to filter on later.

Use this for any agent answering a single commercial question, where the supporting detail is explanatory rather than a set of separate fields.

What that produces:

Rules that matter more than they look:

Use labelled fields when a single evidence trail supports several dimensions that would lead to different commercial actions. The test is whether knowing which dimension fired changes what your rep does. If it doesn't, use the binary format.

This is the part most people get wrong. The Answer format block inside your instruction isn't an illustration of a good answer, it's the schema the agent has to fill in. Every field needs a label, the permitted values, and a short description of the supporting detail you want against it.

Written that way, the agent returns the same shape on every Account, which is what makes the result filterable:

Not every agent needs all four. This one is a compact version of the same pattern:

Note the fourth line. A single Not found among positives is a good result, not a failure. It tells your rep exactly which part of the story is missing.

Same labelled structure, different purpose. These agents produce a breakdown or overview rather than a set of verdicts. They aren't Play triggers or filters, they're categorised context for a rep, so the fields hold descriptions rather than Yes / Not found.

A classification agent works the same way, with the addition of a confidence field:

CRM enrichment agents return a specific factual value for a structured field: annual revenue, a private equity owner, a platform vendor, a reporting period. These are not signals and they don't use Yes or Not found as their primary format.

The answer is the value and nothing else.

No label, no units unless the format asks for them, no currency symbol unless the format asks for it, no reporting period, no source, no reasoning, no sentence around it. The output of one of these agents is imported straight into a CRM field. Anything else in the answer corrupts the field.

Wrong:

Right:

The output can only be clean if the allowed answers are defined up front. Where you can, design the field as one of:

Then put an Options: or Format: line immediately under the opening question, before the framing line. Between them, the question and that line should fully define every answer the agent is allowed to give.

Use the block that matches the field type, word for word:

Picklist

Boolean

Integer

Year

Phone

Postcode

NB: the failure value here is n/a, not Not found. Not found is for signal agents. A CRM field wants a consistent empty token.

CRM enrichment agents are the one exception to section 7. Don't tailor their QA block or name a false positive in it. Use this, unchanged:

Also tell the agent not to estimate, not to convert currencies, and not to infer a value from a third-party profile unless the source explicitly provides it. For numeric values, convert K or M into full digits and strip commas, spaces and units.

Every agent ends with a Final QA block, tailored to that agent's evidence requirements. It should:

That last point is the one that does the work. A generic QA block is easy to write and easy for the agent to skim past. Naming the specific thing you expect it to get wrong is what stops it.

Every Contact Research Agent has to confirm it's researching the right person before it treats any evidence as valid. Common names and stale profiles are the biggest source of quietly wrong contact research.

Require at least two matching identity signals from: full name, current employer, current job title or function, geography, profile photograph, company domain, event biography, consistent career history.

If identity is ambiguous, return Not found.

Tell the agent explicitly not to rely on:

For profile-style agents (career trajectory, thought leadership, service-line classification), the identity check is the prerequisite for the entire structured output. If identity can't be confirmed, the agent returns Not found, not a partial profile.

Effort measures research complexity, not commercial importance. This is the single most common mis-setting in a mature environment. An agent checking whether your most strategic accounts have a careers page is still a Low effort agent.

Score the agent across seven dimensions, using 0 for low complexity, 1 for moderate, and 2 for substantial:

Worked examples:

Score the actual complexity. Don't raise the effort because the topic sounds important, and don't raise it because a merge added a second dimension that comes from the same source pass.

Standard is the default for every agent, and it's the right answer nearly all the time.

Use Fast only when the signal is genuinely time-critical and a Standard-speed result would be stale before your rep could act on it. Fast doubles the credit cost, so a Medium agent on Fast costs the same as running two Medium agents on Standard.

If you can't name the specific window that makes the result perishable, it isn't a Fast agent.

Most environments accumulate agents. Someone adds a signal for a campaign, someone else adds a similar one for a different vertical, and eighteen months later you're paying twice to open the same three pages.

The test is evidence-trail overlap, not conceptual similarity. Two agents about "growth" may look like duplicates and read completely different sources. Two agents about apparently different topics may open exactly the same pages.

Merge when the agents:

Do not merge when:

The keeper should normally be the agent with the strongest existing instructions, the broadest appropriate vertical coverage, the richest evidence trail, the clearest downstream use, and the better-defined output.

Before you merge:

For Contact Research Agents, there's one extra step:

Sometimes the right move is neither a new agent nor a merge. Expand an existing agent when the additional signal lives on the same pages and the output stays coherent.

When you expand:

If you remember one thing, make it this.

A strong Research Agent is:

Research the same evidence trail once, capture the meaningful dimensions coherently, and don't add complexity that doesn't improve a sales decision.

Here's the whole pattern assembled into one Account Research Agent, ready to paste into the Instructions field and adapt:

Effort for this agent: Low to Medium. It uses a handful of predictable source types, needs a dated result, and returns a binary answer. It is not High just because supply chain transformation is a big-ticket theme.

💡 Test it in the Research Agent Sandbox against three Accounts you already know the answer for before you enable it across a vertical. One of the three should be an Account where you expect Not found.

Everything above is a skill Eva already has. You don't need to hand-edit thirty agents to bring an environment up to standard.

She can:

The quality of what you get back depends almost entirely on how much scope you give her. Three things make the difference:

1) Name the boundary. Which ecosystem, which verticals, account-level or contact-level. "All my Research Agents" gives her nowhere to start. "The Account Research Agents in my Financial Services ecosystem" does.

2) Say what outcome you want. A review, a recommendation, or an executed change. These are different jobs and she'll do the wrong one if you don't say.

3) Give her the constraint that matters to you. Credit reduction, better Why Now evidence, fewer false positives, tighter output for filtering. That's what she optimises against.

For a full quality pass:

For a consolidation exercise:

For a new agent:

💡 Pro Tip: Ask her to explain her Effort scoring rather than just set it. Effort is the setting most likely to be wrong across an environment, and it's the one with the most direct effect on what you spend.

NB: Eva confirms before she changes anything. She'll show you what she's about to do and wait for you to approve it, so an audit prompt won't quietly rewrite half your ecosystem.

📖 Create Research and Qualification Agents - How to add and configure agents in the Agent Training Center

📖 Agent Training Center - The full overview of where agents, personas and value propositions live

📖 Ecosystems, Verticals and Key Accounts - How vertical applicability works and why it matters for agent scope

⚡️ Play Drafting Best Practices - The equivalent guidance for the Play Agents that consume your research