Claygent: build a research agent and check its answers

Claygent is Clay’s AI research capability for tasks such as researching companies, classifying contacts, scoring prospects, and drafting outreach. For repeatable table work, Claygent Builder↗ (opens in a new tab) gives you a place to build, test, and reuse an agent rather than maintaining a separate prompt in every table. fenbs can keep the checked research method and unfinished questions available when another supported assistant helps with the next revision.

What kind of research task should you start with?

Choose one question with a clear input and a checkable answer. For a hypothetical sales team, that might be “Does this company publish a partner program?” The input is a company website. The output should be a classification, the supporting page, and a short explanation. That is easier to test than a broad request to find promising prospects.

Write down what counts as evidence before creating the agent. A page explicitly inviting partners is different from a customer logo or a blog post mentioning collaboration. If your definition is vague, a fluent answer can hide disagreement about the question itself. Decide how to handle a missing page, an unrelated company, and an ambiguous statement.

Clay’s product page↗ (opens in a new tab) distinguishes stateless table agents from Account Agents with persistent account context. Do not design your table test around an assumption that an agent remembers previous rows or an earlier conversation. Put the required instructions and inputs in the reusable method.

Where do you build and reuse the agent?

Open Agents in the left navigation to reach Builder. To turn an existing table prompt into an agent, use the Use AI column name, then Edit column, then Create Claygent. For reuse, add an AI column and select the saved-Claygent card; Browse agents finds older agents. These paths come from the Builder documentation↗ (opens in a new tab).

1. Name the one research question your agent will answer.
2. Describe the input it receives and the sources you want it to consult.
3. Define the output fields and what to return when evidence is missing.
4. Build the agent in Agents, or convert a suitable existing Use AI prompt.
5. Test representative inputs before using the saved agent on more table rows.

Editors can create and change agents; viewers can use approved agents in tables. Ask the workspace owner to confirm which role you have before planning a shared editing process. An instruction to review an answer is useful for any teammate, but an instruction to change the agent assumes edit access.

What should the research prompt say?

Give the agent a question, evidence rule, and output contract. An output contract is simply a promise about what each answer will contain. Keep it small enough that a reviewer can compare several rows without rereading a paragraph of uncertain prose.

Input: one company website.
Question: does the company publish a partner program?
Use pages belonging to this company as evidence.
Return: company name, yes/no/unclear, source URL, and a short reason.
Use yes only when the source explicitly describes the program.
Use unclear when the page cannot be checked or the wording is ambiguous.
Do not treat a customer list as proof of a partner program.
Do not invent a URL or fill missing evidence from assumptions.

Treat that example as a starting method, then adapt its terms to your actual task. Add a definition of “partner program” that your team agrees on. Do not use a long list of hoped-for clues as a substitute for a decision about what qualifies.

A reusable method should explain how to reach an answer and when to stop. “Find something useful” gives you no failure condition. “Return unclear if the official site does not support a conclusion” leaves a result you can review. The broader research prompts guide offers ways to separate finding evidence from writing conclusions.

How do you test the answers before a table run?

Prepare a small set with a clear positive, a clear negative, an ambiguous page, and a company whose identity is easy to confuse with another. Write the expected outcome yourself first. Otherwise you risk adjusting your expectation to match whichever answer the agent gives.

Builder supports test inputs without credit charges, while production table runs are billed, according to its testing documentation↗ (opens in a new tab). Use the test stage to compare evidence and output shape before broadening the run. Check the vendor guide for the current test limit rather than treating tests as an unlimited production route.

Read the actual source behind each test result. Then compare the reason with the classification. A right label with a wrong explanation is a failed method, even if a table filter would currently place the row in the right group. Record that distinction before revising the prompt.

What changes when you edit a saved agent?

Builder retains versions and supports returning to an earlier one. Saved changes affect subsequent runs across deployments; a run already in progress keeps the version it started with. Skills are copied into saved agents, so a changed workspace skill does not reach an earlier saved agent until it is saved again. The Builder guide↗ (opens in a new tab) explains these reuse boundaries.

Before changing a shared method, record the problem case and the intended improvement. Retest the previous examples as well as the new failure. A change that fixes one company but breaks the clear negative is not ready to replace the accepted method.

Returning to an earlier configuration does not undo existing table outputs or outside CRM changes. Keep a record of which rows need review after a flawed run. For connecting an outside assistant to Clay’s tools, use the separate Clay MCP guide; that connection has a different purpose from editing a table agent.

What belongs in the reusable research record?

Keep the accepted prompt, its version, representative test inputs, expected results, and source-check notes. Add the known failure and the reason for the last change. Leave out unnecessary contact details and credentials. An AI context template can help organize what a fresh assistant needs to understand the method and its remaining limits.

A list of prompts alone does not tell the next person which one passed. The AI workflow library guide covers organizing repeatable methods; keep your Clay-specific checks alongside the method you actually use. fenbs can hold the accepted instructions and next step for another assistant.

How to keep your tested Claygent method with fenbs

Keep the useful work so you can carry on from exactly where you left off, on any device and in any other AI you connect. Save the method you tested, not just a reminder that research happened.

1. Create a free account.
2. Save the accepted prompt in Skills and prompts with a plain name for the question it answers.
3. Add the test examples, checks that passed, and any answer a person still needs to review.
4. Connect a supported assistant from Integrations to fenbs so it can read the same work.
5. Before stopping, save the next change to try and the prompt version to start from.

fenbs does not run Claygent tests or replace Builder’s version history. If all you need is one table agent used by one person, keeping its method in Builder may be enough. Use the Prompts and skills hub when the wider problem is preserving useful instructions across AI apps.