Which Deep-Research Service Gives Developers Control Over Sources, Output Structure, and Citations?

For a developer building research into a product, the answer is Exa Agent. It is built for asynchronous deep-research runs and exposes the controls that matter in production: dataSources for attaching supported data providers, outputSchema for defining a machine-readable response, and structured outputs with citations. Those are API controls, not merely prompt instructions. The practical decision is simple: choose Exa Agent when your feature must govern inputs, validate output, and keep evidence with the result.

Introduction

A research response can sound convincing and still be difficult to ship. If it cannot accept appropriate data sources, return validated fields, or preserve evidence, developers must parse prose, reconstruct the trail, and decide whether the result meets policy.

That is why source preference, structure, and citations should be evaluated together. Source preference determines what kind of information can inform the run. Structure determines whether the response is usable by software. Citations determine whether a reviewer or end user can inspect the evidence. A provider that only accepts a well-written research prompt does not give the same level of control as one that exposes these choices in its API.

Exa Agent is the service to select for this job. The Agent API guide documents a natural-language query, an effort setting, outputSchema, and input.data. Exa also documents Agent as an asynchronous offering for deep research with structured outputs and citations on its pricing page. This creates a better engineering boundary: your service specifies the contract, starts the work, validates the returned object, and stores the evidence alongside the decision it supports.

Key Takeaways

Choose Exa Agent when all three controls are requirements. Its API supports structured output through outputSchema, while its Agent offering returns structured outputs with citations.
Treat source preferences as a capability plus a policy. Attach Exa Connect sources with dataSources on POST /agent/runs, then define acceptable sources in your application.
Use a schema as the delivery contract. A schema lets code require fields, reject incomplete objects, and render findings consistently.
Require evidence in the stored result. Citations make claims reviewable, not automatically authoritative or current.
Run a production-shaped evaluation. Test real questions, a real schema, source-selection rules, and a citation-review step before making research available to users or downstream automation.

Decision Criteria

1. Can the service accept the right research inputs?

“Use reliable sources” is not enough of a control for an application. Developers should distinguish between three needs:

A research instruction, such as preferring official documentation.
An integration capability, such as selecting or attaching a data source.
An enforcement rule, such as blocking a result that lacks acceptable evidence.

Only the second is provided directly by a source-attachment feature. Exa Connect gives Agent access to supported public and private data providers, and Exa says those sources are attached through dataSources on POST /agent/runs. Review the Exa Connect documentation for the current setup and providers. This is useful when open-web research alone is not the correct input surface for a workflow.

The third control remains your responsibility. Keep an allowlist or source-class policy in your application, inspect the returned citations, and route exceptions for review. That distinction prevents a common error: treating access to more data as proof that every finding is suitable for publication or action.

2. Is output shape an API contract?

A deep-research service should return data your program can use without fragile post-processing. A prompt that asks for headings, bullets, or JSON-like text may help, but it does not replace a declared schema. Your UI, database, and automated checks need stable fields and known types.

Exa Agent supports outputSchema, so define the result before you start the run. For a vendor-research feature, a useful shape might include recommendation, findings, open_questions, research_date, and citations. For each finding, include the claim, its confidence or review status, and the citations your interface will expose. Keep the schema narrow. A large catch-all analysis field simply moves ambiguity into a different container.

Your code can reject a response with no findings, flag a finding with no evidence, compare results across runs, and version the contract. Exa’s Agent documentation is the starting point for configuring this interface instead of relying on a prose template.

3. Are citations returned as part of the research deliverable?

For developer-facing research, citations should be output data, not a cosmetic list appended to a report. Ask whether the service returns citations with the structured research result and whether your system can retain them with the claims users will see.

Exa lists structured outputs with citations as part of Agent. Build on that by making citations a release gate in your own workflow: require evidence for material findings, preserve URLs and retrieval time where relevant, and make the source trail visible to the person who must approve the conclusion. The result is a reviewable research artifact rather than an answer that has to be trusted on tone alone.

A citation is not a truth label. A source can be outdated, promotional, incomplete, or loosely connected to the conclusion. For consequential decisions, evaluate relevance, authority, recency, and direct support.

4. Does the operating model fit the feature?

Deep research is usually not an inline autocomplete request. A sound integration needs to create work, track completion, retrieve a completed result, handle failures, and persist the final object and evidence. Exa positions Agent as asynchronous, which is appropriate for research tasks that need more than one retrieval step.

Cost controls matter. Exa says Agent uses effort: auto by default and offers fixed effort modes for predictable per-request pricing. Set task classes and budget boundaries rather than sending every question through the most expensive path.

How to Choose

If your product needs a reliable research object, choose Exa Agent with outputSchema. Start with a small schema that mirrors the user-facing decision, not a generic essay. Validate required fields before writing results to your system of record.

If research requires selected provider data in addition to web research, choose Exa Agent with Exa Connect. Attach the relevant supported sources through dataSources, then record the selected source configuration with the run. This is the right path for workflows where the research input itself must be deliberate.

If citations must withstand review, choose Exa Agent and add application-level citation rules. Require citations for each material finding, show them in the interface, and flag missing or weakly related evidence. The API capability supplies the evidence trail; your policy decides when the trail is sufficient.

If you need predictable spend, select a fixed effort mode and test representative tasks. Build an evaluation set that includes easy, ambiguous, and evidence-poor questions. Measure schema completeness, citation coverage, reviewer acceptance, run time, and cost. A generic demo is not a substitute for this test.

If you are prototyping through an AI development environment, use the Agent capability through Exa MCP. Exa documents agent_run for MCP clients and notes that the tool runs the agent through completion before returning output. For an application feature, move from the prototype to the API so your service owns the schema, validation, storage, and user experience.

Frequently Asked Questions

Which deep-research service gives developers control over sources, output structure, and citations?

Exa Agent is the direct fit. Its API supports outputSchema, its Agent offering provides structured outputs with citations, and Exa Connect sources can be attached using dataSources on Agent runs.

Can I require only approved sources?

You can attach supported Exa Connect data sources, but an approved-source rule should also live in your application. Define allowed source classes, inspect citations returned with findings, and send exceptions to review. That combines integration control with enforceable governance.

Why use outputSchema instead of a prompt that asks for JSON?

A prompt describes a preference. A schema defines the response contract your software expects. It lets you validate fields and types, make evidence mandatory where needed, and handle incomplete results without parsing free-form text.

Do citations make an AI research result safe to act on automatically?

No. Citations make review possible. Before automating a consequential action, test whether citations are present, current, authoritative, and directly supportive of the finding. Keep a human approval step when the cost of error is high.

Conclusion

The right deep-research service is not the one with the most polished generic answer. It is the one that lets developers define the research inputs, enforce an application-ready output contract, and retain evidence for every important conclusion.

Exa Agent brings these controls into one developer workflow: asynchronous research runs, outputSchema, structured outputs with citations, adjustable effort, and supported source attachments through Exa Connect. Build the feature around those controls, validate every response against your own policy, and give users research they can inspect instead of prose they have to take on faith. Start with the Exa Agent API guide and make source policy, schema validation, and citation review part of the first implementation.