Give synthesis one bounded verification tool

Learning objective

Give a specialist a narrowly scoped cross-role tool for frequent simple checks while routing complex requests through the coordinator.

Core idea

Role-specific access does not require a handoff for every small question. A synthesis specialist might repeatedly need to confirm whether a supplied passage supports a claim. Giving it the researcher’s complete search menu would blur the roles; routing every passage check through the coordinator would add unnecessary work.

A bounded verify_fact tool offers a middle path. It checks one claim against an identified source in the supplied evidence set. It does not discover sources, expand the research question, or decide how to resolve conflicting documents. This is an application-defined tool, not an Anthropic built-in verification service.

The boundary depends on the operation’s inputs and implementation. Calling an unrestricted search tool verify_fact does not make it narrow. The tool must perform a small, repeatable check whose result lets the synthesizer continue its own task. When the question exceeds that contract, the coordinator owns the broader investigation.

How it works

Define the frequent check precisely

Start with repeated workflow traces. Anthropic’s tool-design guidance recommends examining tool calls for common workflows and considering consolidation of frequently chained tasks. If synthesis repeatedly needs the same source lookup and claim check, package that operation around the evidence it already has.

In this application, verify_fact accepts claim and source_id. The input_schema defines these as required strings. The description says that the tool evaluates one claim against one approved source and returns the relevant passage with a bounded assessment. These fields are your custom contract; they are not reserved Messages API parameter names.

The implementation resolves source_id inside the supplied evidence registry. It does not treat an arbitrary URL embedded in claim as another source to retrieve. If the source is missing or the claim needs evidence outside that document, the result identifies the limitation. The specialist must not convert an inconclusive check into a verified assertion.

Use a result that separates the assessment from its evidence. For example, the custom output can contain a status such as supported, contradicted, or insufficient evidence, plus the passage and source location. Those status labels are application-defined. Their purpose is to distinguish a confirmed statement from a question the tool could not settle.

Expose the check without exposing the whole role

For a Messages API synthesis agent, add only the verify_fact definition to its role-specific tools array alongside any operations required for synthesis. Keep general discovery and broader retrieval operations on the research role’s array. See 2.3.1 for role-specific menu construction and 2.3.2 for constrained retrieval.

The tool’s description is important because this capability crosses a role boundary. Explain when it saves a handoff and when it does not apply. A check of one supplied quotation fits; a request to reconcile several jurisdictions or find a missing primary source does not. The distinction is the work required, rather than the length of the user’s sentence.

Anthropic recommends clear, distinct tool purposes and descriptions that explain limitations. A vague description such as “verify anything” invites the synthesizer to treat the tool as a general research capability. Name the evidence scope directly so selection follows the operation you implemented.

If the check cannot run, the client-tool response still uses tool_result and the corresponding tool_use_id. An execution failure uses is_error: true. A successful check that finds insufficient evidence is different: the operation ran and returned a limited evidential conclusion. Preserve that distinction instead of labeling every unresolved claim as a transport failure.

Route the complex work explicitly

The synthesizer’s assignment specifies how to return unresolved questions. In a Messages-based coordinator workflow, the coordinator reads the specialist’s final handoff and starts a research request with the researcher-specific tools array. The routing is application control flow; verify_fact does not automatically create another agent.

For an Agent SDK workflow, the coordinator defines research specialists through agents, using AgentDefinition.description for delegation suitability and AgentDefinition.prompt for the assignment. Delegation uses the Agent tool. See 1.2.1 for coordinator-owned routing and 1.3.3 for the self-contained context the delegate needs.

A useful unresolved handoff names the claim, the source checked, the relevant passage, and why a local check was insufficient. The coordinator can then assign the missing investigation instead of asking the researcher to repeat synthesis. This is the same evidence-bearing handoff principle taught in 1.3.4, applied to a cross-role tool’s scope limit.

Key distinctions and trade-offs

Each evidence need in the research system has one owner and one shape:

Frequent check versus specialist investigation: A local check verifies a bounded statement against known evidence. Investigation chooses evidence, resolves conflicts, or expands the question. Frequency can justify a narrow tool; it does not justify unrestricted access.

Read-only versus narrowly scoped: A general web search can be read-only and still take synthesis outside its assignment. Scope concerns what information and decisions the operation reaches, not only whether it changes external state.

Unsupported claim versus failed execution: “The source does not support the claim” is a useful result. “The source could not be loaded” is an execution problem. The agent needs that distinction to decide whether to revise the text or request missing evidence.

Reduced handoffs versus hidden research: A bounded tool can remove repeated coordinator round trips. If the tool performs open-ended searching under the hood, it hides the same role expansion rather than solving it. Evaluate what execution actually does.

Architecture / decision scenario

A multi-agent research system produces a comparative report. The synthesizer frequently checks whether a supplied policy passage states an exact effective date. Each check is simple, but sending it through the coordinator and researcher repeatedly slows report assembly.

The architect adds an application-defined verify_fact tool to the synthesis request’s tools array. Its required claim and source_id inputs identify one statement and one approved source. The implementation resolves the source in the supplied registry and returns the relevant passage, source location, and assessment. The synthesizer can correct a date without starting another investigation.

A later claim asks whether an exception applies across several conflicting policy documents. The bounded tool reports that one source cannot settle the question. The synthesizer includes that limitation in its handoff rather than guessing or using an unrestricted search operation.

The coordinator reads the unresolved question and assigns a research specialist to compare the named policies and find any missing controlling source. In an Agent SDK implementation, the coordinator invokes the specialist through Agent with the relevant assignment context. The researcher returns evidence, and synthesis resumes with a supported conclusion. Simple checks stay local; complex evidence decisions retain coordinator ownership.

Common exam traps

• Giving synthesis the researcher’s full tool menu to avoid small handoffs.
• Assuming a read-only tool is automatically narrow enough for every role.
• Describing verify_fact as an Anthropic built-in tool.
• Treating insufficient evidence as confirmation or an execution failure.
• Hiding open-ended research inside a tool labeled as a simple check.
• Routing every bounded quotation check through a full research delegation.

Where the exam guide differs

What to remember

Give a specialist a cross-role tool only for a clear, frequent, bounded operation. Express the scope in its description and input_schema, enforce it in execution, and return evidence with the assessment. Let the coordinator route questions that require broader source selection or conflict resolution.

Knowledge check

References

• Anthropic, Define tools
• Anthropic, Handle tool calls
• Anthropic, Subagents in the SDK
• Anthropic, Writing effective tools for agents
• Anthropic, Claude Certified Architect – Foundations Exam Guide