How to Build a Read-Only AI Research Agent

An AI agent can be useful without permission to change a single thing.

When businesses think about AI agents, they often jump straight to actions. Send the email. Update the CRM. Create the task. Change the record. Contact the customer.

But some of the most useful sales work happens before anybody takes an action. Finding information. Gathering context. Checking history. Connecting information from different systems. Identifying what matters. Preparing somebody for a conversation.

That means a useful first AI agent may need: Access to approved information. A clearly defined research job. A useful output. And no permission to change anything at all.

That is a read-only AI research agent.

What is a read-only AI agent?

A read-only agent has permission to access defined information but not to alter the underlying systems. For example, it may be able to: Read CRM records. Search approved documents. Read selected email information. Access previous meeting notes. Search an internal knowledge base. Gather approved public information. Then use that information to complete a defined job.

For a sales research agent, that job might be: "Before a first sales meeting, gather the relevant approved information about the account and prepare a concise briefing for the salesperson."

The agent has responsibility. But very little action authority.

Read-only does not mean passive.

Responsibility without broad action authority.

The agent may still need to: Find information. Choose relevant sources. Compare records. Identify useful context. Recognise gaps. Detect contradictions. Organise findings. Prepare an output. Determine when it cannot answer reliably.

That is more than a simple database lookup. The agent is doing work. It just is not changing the systems it works with.

Why start read-only?

Because it separates two questions.

Question 1. Can AI understand enough of our business information to perform a useful job?

Question 2. Should AI be allowed to take actions based on that understanding?

You do not have to answer both questions at once. Start with the first. If the research is consistently poor, giving the system more authority will not improve it. If the research becomes genuinely useful, you have evidence to decide what should happen next.

A read-only agent can prove value before autonomy.

Imagine an agent preparing salespeople before meetings. If its briefing regularly contains: The wrong account. Outdated information. Irrelevant history. Missing commitments. Invented conclusions. Then you have learned something important while the system still cannot change anything.

If the briefing is consistently useful, you can decide whether the workflow should later expand. Perhaps it should prepare CRM changes. Perhaps it should create an internal task. Perhaps it should do neither. Autonomy should earn its place.

Start with a research question.

Not "research this company". That instruction is too broad.

What information would actually help the salesperson? A better job might be: "Prepare the salesperson for their first meeting with this account." Or: "Find the information needed to understand the current opportunity before the account review." Or: "Gather the relevant history before this opportunity is handed to a new salesperson."

Research should have a purpose. Otherwise AI can produce an impressive amount of information that nobody needs.

Research should have a question.

Before connecting any source, ask: What does the person need to know?

For a first meeting, perhaps: Who is the organisation? Why are we speaking? What did they ask about? Have we interacted before? Who are the relevant contacts? What information has already been provided? What remains unclear? Is there useful approved external context?

For an existing opportunity: What happened last? What was agreed? What remains outstanding? Who owes the next action? What changed? Which documents matter?

Now the agent has a reason to research.

Define the job.

A practical job description could be:

Start with internal information.

Your business may already know more than your salesperson can easily find. Before searching the internet, check what already exists.

Information may be spread across: CRM. Email. Meeting notes. Proposals. Documents. Shared drives. Internal knowledge. Previous support or delivery context where appropriate.

Salespeople may know that the information exists. The problem is finding it quickly.

Sales research is often a search problem. Not a lack-of-information problem.

CRM research

A research agent might gather: Account information. Relevant contacts. Current opportunities. Previous opportunities. Recent activity. Previous meeting notes. Outstanding actions. Known requirements. Relevant relationship history.

But it should not simply reproduce the entire CRM record. The job is to find what matters for the research question.

Email research

Where appropriate and permitted, email can contain useful context that never reached the CRM. For example: Questions. Commitments. Changes in requirements. Introductions. Documents. Timing. Objections.

But email access can also be broad. Define: Which mailbox? Which account? Which contacts? Which date range? Which threads? Which information is relevant?

Do not interpret: "The agent needs some email context" as: "Give it unrestricted access to everything."

Meeting research

Previous meeting information may reveal: What was discussed. What was decided. What was promised. Who attended. What remained unanswered. What was supposed to happen next.

For an existing opportunity, this can be more useful than generic company research.

Document research

Relevant documents might include: Previous proposals. Statements of work. Product information. Technical documentation. Approved sales materials. Customer requirements. Previous project documents.

Again: Only if the research job requires them. A research agent does not need access to every document in the company simply because documents may contain useful information.

Internal knowledge research

The agent may need to answer: Have we solved something similar before? Which service handles this requirement? What capability is relevant? Which internal specialist may need to join? What approved information can we provide?

This can help the salesperson prepare without hunting through internal systems.

External research

External information can be useful too. Depending on the job, the agent may research approved public sources such as: The organisation's website. Public company information. Recent company announcements. Relevant industry information. Published leadership information. Public product or service information.

But external research should still have a purpose. Do not collect information because it is available. Collect it because it helps answer the research question.

More research is not necessarily better research.

Imagine two meeting briefs.

Which would your salesperson actually read five minutes before the meeting? Probably the second.

Do not build the world's longest briefing. Build the one your team reads.

Design the output before the research.

A useful account brief might contain:

That gives the research a destination.

Sources matter.

AI can combine information so smoothly that it becomes difficult to remember where a statement originated. For business research, that matters.

A briefing should distinguish where appropriate between: CRM information. Meeting information. Email information. Internal documents. External sources.

This allows the salesperson to understand the basis of important claims.

Date matters too.

Suppose the agent finds: A CRM note from two years ago. A proposal from last year. An email from last month. A meeting from yesterday.

They do not necessarily carry equal relevance. The research workflow should consider recency. Old information may still matter. But it should not silently override newer information.

What if sources disagree?

This is one of the most important behaviours to design.

Suppose: CRM says the opportunity is paused. Yesterday's meeting says the customer wants a proposal this week.

The research agent should not quietly choose one. It should surface:

That is useful research.

What if the agent cannot find the answer?

Allow: Not found. Unclear. Needs confirmation. Sources conflict. Human review required.

These are legitimate outputs. A research agent that always produces an answer may be less trustworthy than one that shows uncertainty.

Do not present unclear or conflicting findings as failures. They are part of honest research.

"I don't know" is allowed.

Imagine the salesperson wants: Customer budget.

The agent searches the approved information. No budget exists. The correct result is:

Unless estimation is explicitly part of the job and clearly labelled as estimation, the agent should not fill the gap with a plausible number.

Separate fact from inference.

For example:

Those are different things. A useful research agent should preserve the distinction.

Research is not qualification.

A research agent can gather information used in qualification. But it does not automatically need authority to decide: Qualified. Not qualified. High priority. Low priority. Good prospect. Bad prospect.

Those may be separate responsibilities. Keep the research job clear.

Research is not prospecting.

The agent may gather information about an organisation. That does not automatically mean it should: Find hundreds of contacts. Generate outreach. Send emails. Create campaigns. Contact people.

Those are different jobs with different permissions and considerations. Do not allow one useful research function to quietly expand into an entire outbound process.

Research is not decision-making.

A research agent can prepare the evidence for a decision. For example: Should we pursue this unusual opportunity?

The agent can gather: Relevant requirement. Existing relationship. Previous conversations. Internal capability. Known constraints. Relevant documents.

But the decision can remain with the salesperson or manager.

AI can prepare judgement without replacing judgement.

Read-only still needs boundaries.

Read-only does not mean: No risk. The agent may still have access to business information.

Define: Which systems? Which records? Which accounts? Which documents? Which mailboxes? Which external sources? Which fields? Which date ranges? Which information types?

Read permission is still permission.

Minimum access still matters.

Suppose the job is: Prepare a briefing for a specific account meeting.

Does the agent need: Every CRM record? Every employee mailbox? Every company document? Every calendar? Probably not.

Where practical, scope access around the job. The principle remains: Permission should follow the job.

A research agent should not quietly become a write agent.

You build the workflow. Then somebody says: It would be useful if it updated the CRM too. Then: Could it create the task? Then: Could it send the briefing? Then: Could it contact the customer?

At some point the job changed. That does not mean the changes are wrong. It means they should be designed deliberately.

Update the job description. Update the authority map. Update the permissions. Test the new actions. Do not let scope expand accidentally.

Use the Authority Ladder.

A read-only research workflow might look like:

That is still an AI agent.

An agent can have responsibility without broad autonomy.

This is worth repeating.

The agent is responsible for: Preparing the briefing.

It decides: Which approved information is relevant. Which sources need checking. How information should be organised. When information conflicts. When it cannot complete the job reliably.

It has a defined outcome. It just does not have permission to alter the underlying systems.

Example: First meeting research

A new prospect books a meeting.

The agent: Identifies the organisation. Finds the original enquiry. Checks whether the company already exists in CRM. Finds relevant previous interactions. Identifies the people involved. Gathers approved public company context. Finds information relevant to the stated requirement. Prepares the briefing.

The salesperson receives:

No CRM changes. No outreach. No autonomous action. Useful work completed.

Example: Existing account research

A salesperson has a meeting with an existing account.

The agent gathers: Current opportunity. Last meeting. Recent relevant email context. Outstanding commitments. Previous proposal. Relevant account history.

Then prepares:

That can change how the salesperson approaches the meeting.

Example: Opportunity handover research

An opportunity moves to a new salesperson.

The research agent gathers: Relevant history. Previous owner. Customer contacts. Current requirement. Commercial context. Decisions. Commitments. Open questions. Relevant documents.

Then prepares the handover. Again, it can do this without changing ownership itself.

Example: Proposal preparation research

Before somebody prepares a proposal, the agent can gather: Confirmed requirements. Relevant previous discussions. Approved pricing information. Technical constraints. Outstanding questions. Previous proposals where appropriate. Relevant internal capability information.

Then prepare a research pack. The human still writes or approves the commercial proposal.

Research agents can support other agents.

A research agent does not need to be the final workflow. It can become a controlled information layer.

For example: Research Agent gathers account context. Meeting Agent uses approved context to prepare the salesperson. Follow-Up Agent uses agreed meeting outputs to monitor next actions.

Different responsibilities. Different information. Different authority. This can be easier to control than one enormous agent doing everything.

Do you need a separate Research Agent?

Not always. Research may simply be one step inside another workflow.

For example: A Meeting Preparation Agent might perform its own research. A Lead Management Agent might gather account context before routing. A Handover Agent might research relevant history.

Use a separate agent where the responsibility is distinct enough to justify it. Do not create extra agents simply to make the architecture look sophisticated.

Buy the commodity. Build the difference.

Some research capabilities may already exist in: Your CRM. Meeting software. Search tools. Knowledge platforms. AI products. Automation tools. Use those where they solve the problem adequately.

Custom work becomes more useful where your process requires: Specific internal sources. Specific context. Business-specific logic. Defined output structure. Cross-system research. Custom permissions. Specific escalation.

The objective is not to rebuild search. It is to make your business information useful at the right moment.

How to build a read-only AI research agent

Test the difficult research cases.

Do not only test: A famous company. Clean CRM data. Perfect meeting notes. A complete website.

Test: Company with similar names. Subsidiary and parent company. Old CRM information. Conflicting contact information. Several active opportunities. Missing meeting notes. Outdated website information. No recent external information. Multiple people with the same name. Conflicting internal documents. No answer available.

The agent needs to be comfortable saying: I cannot establish this reliably.

How should you measure a research agent?

Do not measure: Number of sources searched. Number of facts generated. Length of briefing. Number of tokens produced.

Measure usefulness. For example: Did the salesperson use the briefing? Was important context missing? Was irrelevant information included? How often did information need correcting? How often were sources wrong? Did it reduce repeated searching? Did it surface information the salesperson would otherwise have missed? Did it prepare the person for the actual conversation?

Activity is not value.

The briefing should be shorter than the research.

The agent may search many sources. The salesperson should not have to read all of them. That is part of the job.

The research process may be complex. The output should be useful.

Think:

What should an AI account brief include?

A practical structure is:

That is usually more useful than a generic company report.

What should it leave out?

Information that does not help the job. Potentially: Long company histories. Irrelevant news. Every CRM activity. Every employee. Generic industry explanations. Old information with no current relevance. Huge meeting transcripts. Speculative personality analysis. Information collected simply because it is available.

The research agent should filter. Not hoard.

What about external web research?

External research can add useful context. But define: Which sources are acceptable? How current should information be? Does the source support the claim? Should the source be shown? What happens when information cannot be verified? What information is actually relevant to the sales job?

The agent should not turn a meeting brief into a general internet dossier.

What about research on people?

Keep the research relevant to legitimate business context and the job being performed.

Useful professional information might include: Public role. Relevant responsibilities. Publicly stated business priorities where appropriate. Previous interactions with your business.

Avoid gathering personal information simply because it can be found. Again: The job defines the information.

What about hallucinations?

Do not try to solve this only by writing: "Never hallucinate." Design for uncertainty.

Require important information to come from approved sources. Allow: Not found. Unclear. Needs confirmation. Sources conflict. Show sources where useful. Test situations where the answer does not exist.

A good research workflow should not be punished for refusing to invent an answer.

What about stale information?

Research needs time awareness. A company website from today. A CRM note from three years ago. A proposal from last year. A meeting from yesterday. These should not be treated identically.

Where relevant, show dates. For example:

That tells the salesperson what they actually know.

What happens after the research?

Initially: A person uses it. That may be enough.

Later, you may decide the output can feed: Meeting preparation. Lead routing. Proposal preparation. Sales handover. Follow-up. CRM preparation. Another agent.

But each new use should have its own: Job. Authority. Permissions. Limits. Escalation.

A useful research agent should not become a hidden route to unrestricted automation.

When is a read-only research agent a good first AI project?

It can be worth investigating when: People repeatedly search several systems. The same research happens often. Information is scattered. The required output is reasonably clear. Research consumes meaningful time or attention. People frequently miss useful context. The consequence of the AI preparing an imperfect brief is manageable because a person reviews it.

That combination makes research an attractive place to start.

When might it not be worth building?

If: The research happens rarely. One existing system already provides everything needed. The required information is not available digitally. Nobody agrees what a useful briefing contains. The information cannot be appropriately accessed. The output would not change what anybody does.

Then AI may not be the first answer.

Frequently asked questions

Useful does not have to mean autonomous.

An AI agent does not need permission to: Send. Change. Create. Delete. Contact. Approve. It can begin with: Read. Understand. Find. Compare. Prepare. Escalate.

For many businesses, that may be enough to prove whether AI can genuinely help with a sales process. Start with the research job. Give it the information it needs. Keep the access narrow. Make uncertainty visible. Build an output somebody actually uses. Then decide whether it needs anything more.

An agent can be useful without permission to change a single thing.