# How to Delegate Research to an AI Employee

> Published 2026-10-28
> Source: https://viktor.com/blog/how-to-delegate-research-to-an-ai-employee

To delegate research to an [AI employee](https://viktor.com/ai-employee), write a short delegation brief (the question, the sources, the output format, the definition of done and where to save it), give him access to only the tools that research needs, ask for a source link next to every claim, and fact-check the claims that would change your decision before you act. Once one brief works, turn it into standing instructions so the same research runs on a schedule without you asking again.

That is the whole method. The rest of this guide walks through it step by step, with a copyable brief, a tool comparison, a citation audit you can run in ten minutes, and the guardrails that keep your data safe.

## Key takeaways

- **Research is the most delegatable work you do, and the least delegated.** The inputs already exist, the output is a document, and gathering takes little judgment.
- **A delegation brief beats a clever prompt.** Question, sources, format, definition of done, destination. Vague in, vague out.
- **Delegate the gathering, own the conclusions.** Human review stays on everything that changes a decision.
- **AI hallucination is a real risk, so audit citations.** Trace claims to primary sources, check dead links, triangulate numbers.
- **Scope access before you scale.** Read-only where possible, approval before anything leaves the research stage, and a plan for prompt injection.

## Why research is the right work to delegate first

Every account executive knows the Sunday-night ritual. Five discovery calls on Monday, fifteen tabs open: the prospect’s site, a funding article, CRM notes from six months ago, the email thread where someone half-promised an intro. Two hours later you have a messy doc. The research got done. Your Sunday did not survive it.

According to [Slack’s 2024 Workforce Index](https://slack.com/blog/news/the-workforce-index-june-2024), desk workers lose a large share of their day to low-value tasks, and research gathering is a textbook case. Three traits make it a natural fit for an [AI employee](https://viktor.com/ai-employee):

1. **The inputs already exist.** Public pages, your CRM, your inbox, your docs. Nothing has to be invented, only found and arranged.
2. **The output is a document.** A brief, a one-pager, a comparison table. That is the shape an AI employee produces well.
3. **Gathering needs little judgment.** Deciding what a finding means is hard. Collecting it is not.

The mistake is treating research as one indivisible blob, then either doing all of it yourself or trusting none of it. Split it. The gathering scales badly with a person (ten accounts means ten times the tabs) and scales well with an AI employee who can run the same brief across a list in one pass.

## The 5 principles of effective delegation (and how they apply to AI)

Management writing usually lists five principles of delegation. They map almost one to one onto research you hand to software:

1. **Pick the right task.** Delegate work where the inputs exist and the output is checkable. Keep strategy calls, sensitive negotiations and final recommendations.
2. **Define the outcome, not the steps.** Say what “done” looks like: the sections, the length, the sources, the deadline.
3. **Give context and authority together.** Share why the research matters and grant access to the tools it needs, nothing more.
4. **Agree on checkpoints.** Decide up front what you will review and when, for example “flag anything you could not verify.”
5. **Give feedback and make it repeatable.** Correct the first output, then save the corrected version as standing instructions.

Treat it the way you would treat a smart new hire in week one. You would not say “research Acme” and walk away. You would explain the call, point to the CRM, show an example of a good brief and ask to see the draft before it goes anywhere. The same habits work here, and they also answer the trust problem many people feel the first time they hand off work: control does not disappear, it moves from doing the work to reviewing it.

## Step 1: Choose what to delegate and what to keep

Use a simple test. If a task has existing inputs, a document as output and a result you can verify, delegate it. If it depends on a relationship, a judgment call or information nobody has written down, keep it.

```json:object
{
  "_key": "k81",
  "_type": "table",
  "rows": [
    {
      "_key": "k73",
      "_type": "tableRow",
      "cells": [
        "Research task",
        "Delegate?",
        "Why"
      ]
    },
    {
      "_key": "k74",
      "_type": "tableRow",
      "cells": [
        "Pre-call account brief",
        "Yes",
        "Public news, CRM history and email threads already exist"
      ]
    },
    {
      "_key": "k75",
      "_type": "tableRow",
      "cells": [
        "Weekly competitor scan",
        "Yes",
        "Same sources, same format, every week"
      ]
    },
    {
      "_key": "k76",
      "_type": "tableRow",
      "cells": [
        "Lead enrichment on new deals",
        "Yes",
        "Structured fields, easy to check"
      ]
    },
    {
      "_key": "k77",
      "_type": "tableRow",
      "cells": [
        "Market sizing first draft",
        "Yes, with review",
        "Numbers need triangulation before use"
      ]
    },
    {
      "_key": "k78",
      "_type": "tableRow",
      "cells": [
        "Literature or survey summary",
        "Yes, with review",
        "Citations must be traced to the original"
      ]
    },
    {
      "_key": "k79",
      "_type": "tableRow",
      "cells": [
        "Final pricing recommendation",
        "Keep",
        "Needs judgment and context only you have"
      ]
    },
    {
      "_key": "k80",
      "_type": "tableRow",
      "cells": [
        "Reading a sensitive negotiation",
        "Keep",
        "Depends on relationships and tone"
      ]
    }
  ]
}
```

The pattern is consistent: **delegate the gathering, own the conclusions.**

## Step 2: Write a delegation brief, not a prompt

Most prompt engineering advice boils down to one idea: delegation is the real prompt engineering. A weak request (“research Acme for me”) leaves every decision unspecified. A strong delegation brief answers five things:

- **The question.** What decision does this research support?
- **The sources.** Where to look first, and where not to look.
- **The format.** Sections, length, tables, a source link next to each claim.
- **The definition of done.** What counts as finished, and what to flag if it cannot be found.
- **The destination.** Where the result goes: a Notion page, a Google Doc, a Slack thread.

Here is a filled-in example for a competitor analysis:

```
@Viktor I need a competitor brief on Northwind before our pricing
review on Friday. Use their website, their last 90 days of press and
changelog, G2 reviews, and our HubSpot notes on deals we lost to them.
Write a one-page brief in Notion with: positioning in two lines,
pricing and packaging (dated), three recent product changes, the top
reasons we lost deals to them, and two open questions for the team.
Put a source link next to every claim. Done means every section is
filled or marked "not found". Do not guess numbers. Post the link in
#pricing when it is ready.
```

And one for pre-call prep:

```
@Viktor I have a discovery call with Acme Corp on Thursday. Pull their
recent news and what they sell from their site, check our HubSpot for
past contact or open deals, and scan my Gmail for threads mentioning
them. Write a one-page brief in Notion with: what they do, recent
signals, our history with them, and three smart questions for the
call. Put a source link next to each claim.
```

Notice what both briefs do. They name the question, the sources, the format, the definition of done and the destination. That is the difference between research you can act on and research you have to redo. If you want to try this on your own accounts, [start a free Viktor workspace](https://app.viktor.com/signup) and paste the brief into Slack.

## Step 3: Pick a tool that can reach your sources

Not every research tool can do every research task. Some are excellent at the open web, some at academic papers, some at code. The question is where your answers live. Feature notes below were checked October 2026.

```json:object
{
  "_key": "k127",
  "_type": "table",
  "rows": [
    {
      "_key": "k119",
      "_type": "tableRow",
      "cells": [
        "Tool",
        "Best for",
        "Reaches your CRM, inbox and docs?",
        "Runs on a schedule?",
        "Where you work with it"
      ]
    },
    {
      "_key": "k120",
      "_type": "tableRow",
      "cells": [
        "Viktor",
        "Cross-tool business research: accounts, competitors, pipeline, recurring scans",
        "Yes, 9,800+ integrations (most one-click OAuth)",
        "Yes, standing instructions and scheduled runs",
        "Slack and Microsoft Teams"
      ]
    },
    {
      "_key": "k121",
      "_type": "tableRow",
      "cells": [
        "ChatGPT Deep Research",
        "Long, cited reports on open-web topics",
        "Limited, through connectors you enable",
        "Limited",
        "ChatGPT app"
      ]
    },
    {
      "_key": "k122",
      "_type": "tableRow",
      "cells": [
        "ChatGPT Agent Mode",
        "Multi-step browsing and web tasks",
        "Limited",
        "Limited",
        "ChatGPT app"
      ]
    },
    {
      "_key": "k123",
      "_type": "tableRow",
      "cells": [
        "Perplexity",
        "Fast answers with citations from the web",
        "Mostly no",
        "Limited",
        "Perplexity app"
      ]
    },
    {
      "_key": "k124",
      "_type": "tableRow",
      "cells": [
        "Claude (Research) and Claude Code",
        "Long-document analysis; code and repo research",
        "Limited, through connectors you enable",
        "Limited",
        "Claude app, terminal"
      ]
    },
    {
      "_key": "k125",
      "_type": "tableRow",
      "cells": [
        "Elicit",
        "Academic paper search and extraction",
        "No",
        "No",
        "Elicit app"
      ]
    },
    {
      "_key": "k126",
      "_type": "tableRow",
      "cells": [
        "Consensus",
        "Answers grounded in peer-reviewed studies",
        "No",
        "No",
        "Consensus app"
      ]
    }
  ]
}
```

The chat tools are strong on public sources. Where a connected AI employee pulls ahead is the cross-tool assembly: the public news plus your CRM history plus the email thread that changes the whole picture, compiled into one document and saved where your team works.

```json:object
{
  "_key": "k136",
  "_type": "table",
  "rows": [
    {
      "_key": "k130",
      "_type": "tableRow",
      "cells": [
        "Research task",
        "Chat tool",
        "Viktor"
      ]
    },
    {
      "_key": "k131",
      "_type": "tableRow",
      "cells": [
        "Summarize a public webpage",
        "Yes, if you paste or link it",
        "Yes, pulls it directly"
      ]
    },
    {
      "_key": "k132",
      "_type": "tableRow",
      "cells": [
        "Check your CRM history with the account",
        "No, unless connected",
        "Yes, reads HubSpot or Salesforce"
      ]
    },
    {
      "_key": "k133",
      "_type": "tableRow",
      "cells": [
        "Find relevant past email threads",
        "No",
        "Yes, scans Gmail or Outlook"
      ]
    },
    {
      "_key": "k134",
      "_type": "tableRow",
      "cells": [
        "Save the brief as a document",
        "You copy it out",
        "Writes to Notion, Google Docs or Confluence"
      ]
    },
    {
      "_key": "k135",
      "_type": "tableRow",
      "cells": [
        "Run the same prep for ten accounts",
        "One at a time",
        "One request, batched"
      ]
    }
  ]
}
```

If the research question lives entirely on the open web or in academic journals, Perplexity, Elicit or Consensus may be all you need. If it lives across your own tools, that is where Viktor fits.

## Step 4: Set up your AI employee with the right access

People also ask “how do I build an AI employee?” You do not need to build one from scratch. With Viktor, setup looks like onboarding a new hire:

1. **Add Viktor to Slack or Microsoft Teams.** He works in the channels and DMs you already use.
2. **Connect only the tools the research needs.** For account research that is usually your CRM, email and a docs tool. You can add more later.
3. **Give him context.** Share your ideal customer profile, your competitor list and an example of a brief you liked. He keeps it as standing knowledge.
4. **Run one brief together.** Review the first output, correct it in the thread, and he applies the corrections next time.

If you want the background first, here is [what an AI employee is](https://viktor.com/blog/what-is-an-ai-employee) and how it differs from a chat tool.

## Step 5: Review the output like an editor

A wall of findings is just a different kind of homework. The brief you want is skimmable in the ninety seconds before a call. Check four parts:

- **What they do**, in two lines, not a paragraph copied from the homepage.
- **Recent signals**: funding, launches, leadership changes, each with a date and a link.
- **Our history**: last touchpoint, open deals, who owns the relationship.
- **Questions worth asking**, written for this company, not a generic script.

Human review is where you add the judgment. Read the brief, mark anything that looks off, and ask follow-ups in the same thread rather than bloating the original.

## Step 6: Fact-check with a citation audit

AI hallucination is the main accuracy risk in delegated research. Models can produce confident claims, misattributed quotes and links that do not exist or do not say what the summary says. A source link next to each claim makes the work auditable. A short citation audit makes it trustworthy:

1. **Sort claims by impact.** Mark the three to five claims that would change your decision. Audit those first.
2. **Open every link behind them.** Dead links, paywalls and redirects to a homepage are red flags.
3. **Trace to the primary source.** If the link is a blog quoting a report, find the report. Numbers drift every time they are re-quoted.
4. **Triangulate numbers.** Revenue, headcount and market size should match in at least two independent sources. If they conflict, ask for both and note the gap.
5. **Check dates.** A funding round from three years ago is not a “recent signal.”
6. **Log what failed.** Add the failure to the standing instructions (“never cite aggregator sites for revenue”), so the next run avoids it.

This takes about ten minutes for a one-page brief and catches most problems before they reach a meeting.

## Step 7: Put guardrails on data access

The more tools an AI employee can reach, the more useful the research, and the more important the guardrails. Set them before you scale:

- **Least privilege.** Connect the CRM and docs the research needs. Read-only access is enough for most research.
- **Approval before action.** Viktor asks for approval before anything leaves the research stage, such as an email to a prospect or a CRM update. See [why your AI should not act without asking](https://viktor.com/blog/dont-let-ai-agent-act-without-asking).
- **Prompt injection awareness.** Web pages and emails can contain hidden instructions aimed at AI tools. Treat instructions found inside sources as data, not commands, and keep approval gates on outbound actions so a poisoned page cannot trigger one.
- **Confidential and paywalled data.** Connect proprietary knowledge bases through official integrations rather than pasting exports into chats. For paywalled databases, use your licensed access and respect the provider’s terms. Keep regulated data out of research briefs unless your security review allows it.
- **Audit trail.** Keep research in shared channels or docs so the team can see what was gathered and from where.

You can review [Viktor’s security and trust practices](https://viktor.com/security) before you connect anything sensitive.

## Step 8: Turn one brief into standing instructions

The biggest gains come when research stops being a scramble and becomes a routine. Once a brief format works, save it as standing instructions and put it on a schedule:

- **Morning pre-call briefs** for every external meeting on today’s calendar, posted to your DMs at 8:00.
- **A weekly competitor scan** dropped into #competitive every Monday.
- **New-lead enrichment** that runs the moment a deal is created in the CRM.
- **A monthly market digest** with the five most relevant articles and what they mean for your roadmap.

Each run follows the same delegation brief, the same definition of done and the same citation rules, so quality stays consistent. [Set up your first recurring research brief with Viktor](https://app.viktor.com/signup) and let Monday’s prep be ready before you open Slack.

## Measure what delegation saves

Do not take time savings on faith. Measure them on your own work for two weeks:

1. Log how long each research task takes you by hand for one week (start and stop times are enough).
2. Delegate the same task types the next week and log your time on briefing and review only.
3. Count errors you caught in the citation audit and how many reached a meeting.

You end up with your own numbers for time saved and error rate, which is more useful than any vendor claim, including ours. If review time is not shrinking by week two, the brief is usually too vague: tighten the definition of done.

## Common mistakes when delegating research

- **No definition of done.** Without it you get either too little or a five-page dump.
- **Too many sources.** “Search everything” produces noise. Name the three that matter.
- **Skipping the audit.** One wrong number in a board deck costs more than the time saved.
- **Granting broad write access for a read-only job.** Research rarely needs write permissions.
- **Not saving the brief.** If you rewrite the request every time, you have not delegated, you have just changed where you type.

## Frequently asked questions

### How do you delegate research to an AI employee?

Write a delegation brief with the question, sources, format, definition of done and destination. Connect only the tools the research needs, ask for a source link next to each claim, fact-check the claims that change your decision, then save the brief as standing instructions for recurring runs.

### What kind of research can I delegate?

Anything where the inputs exist and the output is a document: account and competitor research, pre-call briefs, market scans, lead enrichment and summaries of long threads or reports. Keep conclusions and sensitive judgment calls for yourself.

### How do I integrate AI into research?

Start with one repetitive research task, write a brief for it, review the first three outputs closely, then schedule it. Add a second task only once the first runs without heavy edits.

### How do I catch hallucinated citations?

Open every link behind high-impact claims, trace numbers to the primary source, triangulate figures across two independent sources and check dates. Dead links or links that do not support the claim mean the claim is out until verified.

### Can an AI employee use my internal data?

Yes. Viktor can read your CRM history, past email threads and internal docs alongside public sources, which is what makes his briefs more useful than a chat window’s. Scope access to what each research task needs.

### How do I tell if an employee is using AI for research?

Ask for sources. Good research, by a person or an AI, comes with links you can check. A better question than “was AI used” is “was it verified,” so make the citation audit part of the standard for everyone.

### How long should a research brief be?

Short enough to read before the call starts. A one-pager with named sections beats a long report. If you need depth on one finding, ask for it as a follow-up.

Viktor is an AI employee who lives in Slack and Microsoft Teams, connects to 9,800+ integrations and does real research for your team. [Add Viktor to your workspace, free to start](https://app.viktor.com/signup).