Agent · Available now

Persistent Researcher

Every source you research is kept, filed, and still there next week — not thrown away with the session that found it. One focused workflow, with a clear result at the end.

Read docs

How it works

Persistent Researcher runs research as a thread instead of a conversation. You give it a question, it goes and reads, and every source it finds is written down with its link, a summary of what it says, and one line on why it bears on your question. That record belongs to your account, not to a chat window, so closing the tab costs you nothing. Come back in a week with a follow-up question and it adds to the same thread rather than starting over. The research accumulates the way a file accumulates, not the way a conversation evaporates.

What you get back is a thread you can read, share, and keep adding to: a set of filed sources, what they agree on, where they contradict each other, and which claims nothing supports yet. Each run inside a thread has its own public ID, so you can check a run's status, follow it until it settles, or resume one that stopped partway. Threads carry rollup counters, so you can see how much has been gathered on a question without opening every run. Nothing has to be reconstructed from scrollback.

It does not write your document and it does not decide for you. It gathers, files, and reports the state of the evidence, and the argument stays yours to make. You can scope a run by source kind, domain, publication date, and language, and that scope is part of what the thread records. The framing you set when you open a thread carries into every later run, so the tenth answer comes back in the same shape as the first.

harness
hosted
usage
research
source-filing
citations
literature-review
research-threads
evidence-trail
long-running-research
follow-up-questions
contradiction-mapping
market-research
competitive-analysis
due-diligence
research-handoff
resumable-runs

Agent environment

Pricing

Usage-based

harness
hosted
usage

Persistent Researcher runs on Vidbyte's servers, so your computer does not need to stay on. Start and track runs with vidbyte-cli or the research workspace; read full sources, explore a single source, and export results on the website. It keeps research in a thread so you can return to it and add more later.

This agent is live today. Install vidbyte-cli, log in with your Vidbyte key, and add balance to your account. You do not need to install a coding agent or connect a provider account. The install prompt checks the setup steps that apply to you.

Run it from your own agent

Copy prompt

Paste this into the agent you already use and it will ask you what you need, then write the exact Persistent Researcher invocation for your job.

You are helping me write a research brief for Vidbyte's Persistent Researcher, which files every source it reads into a durable thread I can return to. Ask me these four things one at a time and wait for each answer: (1) the single question…

Run it from the command line

Every agent starts with the same two setup commands: install vidbyte-cli, then log in with your Vidbyte key. After that, Persistent Researcher is a small set of research commands for opening threads, adding to them, and tracking runs. The reading itself happens on Vidbyte's side, so none of these commands needs your machine to stay awake.

bash
pipx install vidbyte-cli
Installs vidbyte-cli from PyPI, the command line every Vidbyte agent is started and tracked from. pipx gives it its own environment and puts the `vidbyte-cli` command on your PATH; without pipx, run `python -m pip install vidbyte-cli` inside an activated virtual environment instead, and read the CLI repository README for the full installation notes. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked.
View subcommands
--python
Picks the Python interpreter pipx builds the CLI's environment with, such as `--python python3.12`. vidbyte-cli needs Python 3.11 or newer, so set it when your default Python is older and the install refuses to resolve.
bash
vidbyte-cli login
Stores your Vidbyte API key, which is what identifies you and what every agent's charge is billed against. It reads the key at a hidden prompt, checks it against Vidbyte before saving anything, and then keeps it in your operating system's keyring. Run `vidbyte-cli whoami` afterwards to confirm which account the stored key belongs to.
View subcommands
--with-token
Reads the key from standard input instead of a hidden prompt, which is how you log in from a script or a CI job. Pipe it in from your secret store rather than typing it into the command. There is deliberately no --api-key flag, because anything in the command line leaks into process listings, shell history, and CI logs.
--allow-file-fallback
Approves storing the key in a permission-restricted file when the machine has no operating-system keyring, such as a bare Linux server. Without it, login asks before falling back, or refuses when there is no terminal to ask on. Anything running as your user can read that file, so use it only where a keyring genuinely is not available.
bash
vidbyte-cli research start "<your question>"
Opens a new thread for one question and starts its first run. This is the command that creates the record everything else attaches to, and it prints the thread ID you will use from then on. State the output shape you want here, because the thread keeps that framing for later runs.
View subcommands
--size
Picks a preset breadth for the run: small, medium, or large. Use it when you do not want to size the run by hand. A small run suits a quick follow-up, and a large one suits a first sweep of an unfamiliar topic.
--target-sources
Sets how many sources discovery should aim to collect, from 1 to 1000. Raise it when you need both sides of a contested question well represented. Lower it for a focused check.
--search-calls
Caps how many search calls the run may make, from 1 to 100. It bounds how widely the run looks before it starts reading. Use it to keep a narrow question narrow.
--kind
Restricts discovery to one kind of source, paper or web, and can be repeated. Use paper when you need peer-reviewed evidence rather than commentary. Leave it out to search both.
--include-domain / --exclude-domain
Restricts discovery to, or excludes, a specific hostname, and each can be repeated. Include a domain when you trust a particular source, and exclude one when it keeps crowding out better material. The scope is recorded with the run.
--published-after
Only considers sources published on or after a date, written as YYYY-MM-DD. It is how a follow-up asks for what is new since the last check. Combine it with a dated question for the cleanest result.
--language
Sets a preferred source language, such as en. Use it when the audience reads one language or when a topic is covered best in a particular one. Leave it out to accept any language.
--max-cost-cents
Refuses the run if it would cost more than this many cents, from 1 to 100000. It is a hard ceiling on one run's metered spend. Set it whenever you want a run's cost known before it starts.
--idempotency-key
Lets you retry a start whose result you never saw without being charged twice. Reuse the key the first attempt printed, and the original result is recovered. Leave it out and a fresh key is generated.
bash
vidbyte-cli research add <thread_id> "<follow-up>"
Adds another run to a thread that already exists, which is how a question grows without starting over. The new run works from what the thread has already filed rather than re-reading everything. Use it instead of opening a second thread whenever the follow-up is about the same question.
View subcommands
--published-after
Limits the follow-up to sources published on or after a date. It is the option that turns a follow-up into a check for what changed. Pair it with a question that names the same date.
--size / --target-sources / --kind
Size and scope the follow-up exactly as they do for start. Add accepts every option start accepts, because both submit the same kind of run. Keep follow-ups small unless they open a genuinely new angle.
--idempotency-key
Lets you retry an add whose result you never saw without being charged twice. Reuse the key the first attempt printed. Leave it out and a fresh one is generated.
bash
vidbyte-cli research resume <run_id>
Continues a run that stopped partway because it failed, came back partial, or ran out of balance. It picks up from the state Vidbyte already holds rather than redoing finished work. This is the command that makes a stopped run a pause instead of a loss.
View subcommands
--idempotency-key
Lets you retry a resume whose result you never saw without being charged twice. Reuse the key the first attempt printed. The original resume is recovered instead of a second one starting.
bash
vidbyte-cli research status <run_id>
Reports one run's current state, its phase, how many continuations it has had, and when it last changed. It is a single check that returns immediately. Use it when you just need to know whether to keep waiting.
bash
vidbyte-cli research watch <run_id>
Follows one run until it reaches a final state, printing changes as they happen. Use it when you want to be told the moment a run settles rather than checking yourself. It backs off deliberately, because API keys are metered on a per-minute request budget.
View subcommands
--timeout
Stops waiting after this many seconds, up to a full day. The run itself keeps going when the timeout expires. Use it in scripts that should not block forever.
bash
vidbyte-cli research threads
Lists every thread you own, which answers the question of what you were researching. Each row carries the public thread ID the other commands take. It is a read, so it starts no run.
View subcommands
--limit
Sets how many threads to return in one page. Leave it out and the server picks a sensible default. Raise it when you are looking for an old thread.
--cursor
Continues from the cursor a previous page reported. Use it to walk through a long list of threads page by page. Each page prints the cursor for the next one.
bash
vidbyte-cli research thread <thread_id>
Shows one thread and its rollup counters, so you can see how much has accumulated on a question without opening each run. It is the fastest way to decide whether a line of inquiry is worth pushing further. Pass the public ID that start or threads printed.

Use cases

Each example names the problem, the setup, the command to run, and the result you should expect.

Why use this agent

A general agent researches inside a session, and the session is the storage. That is fine for a question you will answer and forget, and it quietly fails for every question that outlives one sitting. The sources go into the transcript, the transcript goes into the context window, and the context window is both finite and disposable. When you come back three days later, the agent has no idea what it read, so it reads it again and gives you a different answer the second time. Persistent Researcher moves the storage out of the session and into a thread that belongs to your account, so returning to a question is repeatable rather than a restart.

The second difference is auditability. A general agent hands you prose, and prose is exactly the format in which you cannot check anything: the claim and its source have been merged into one sentence, and the only way back is to search again yourself. This agent files each source separately with its link and a note on why it matters, and only then reports what the set adds up to. That gives you two things prose does not: a citation you can hand to someone skeptical, and a visible gap where the evidence is thin. When a decision is important enough to be questioned, being able to point at the source is the whole difference between research and an opinion.

The third is that research is rarely one question. It is a question that turns into four, spread over a week, revisited when something changes. A general agent has no unit for that, so you either hold it all in one bloated session or scatter it across sessions that cannot see each other. Threads are that unit. Each question gets its own accumulating record, and each run inside it can be tracked and resumed on its own. You stop managing conversations and start managing questions.

Research vanishing with sessions
Everything a run reads is filed under a thread you own. Closing the terminal, losing the laptop, or coming back in a month costs you nothing. The evidence is not stored in a transcript you have to keep alive.
Re-reading the same sources
Because the thread knows what has already been filed, a follow-up works from that record instead of reading the web from scratch. The second question on a topic starts ahead of the first. A chat session behaves the opposite way.
Context windows filling up
The sources live outside the model's context, so a long-running question never reaches the point where continuing means forgetting the beginning. Your own agent's window stays free for the work you are doing. Research stops competing with everything else in the session.
Claims with no traceable source
Every filed source carries its link, a summary, and the reason it bears on your question. Any sentence in the output can be walked back to a page someone else can open. That is what makes the research usable in a document that will be reviewed.
Summaries hiding disagreement
Filing sources separately keeps contradictions visible instead of averaging them into a confident paragraph. You are told where the sources conflict and which claims nothing supports. That is usually the most decision-relevant part.
Runs lost to failures
Runs are durable and addressed by their own ID, so a stopped run can be resumed where it stopped. Work already done stays done. A crash or a timeout stops being a restart.
Not knowing run progress
Status and watch report the real state of a run, including its phase and how many continuations it has had. You can decide to wait or leave without guessing. Watch backs off on purpose so following a run does not use up the request budget you need for the next one.
Research that cannot transfer
A thread reads as evidence rather than as your conversation. A teammate can pick it up without replaying your prompts or asking what you meant in message eleven. Handoff stops requiring a meeting.
Questions blurring together
One thread per question keeps each line of inquiry's sources separate. You can tell which evidence supports which conclusion. Decomposition happens in the threads instead of in your head.
Output shape drifting
The framing you set when you open a thread persists across later runs. The tenth answer comes back in the same form as the first. You stop re-specifying the format every time you return.
Monitoring costs full effort
A dated follow-up on an existing thread asks only for what changed. The thread already knows what has been filed. Keeping up with a topic stops taking the same effort as researching it.
No proof work happened
A thread is a durable record with a public ID, a run history, and filed sources. You can point at it in a review, a diligence process, or a postmortem. A chat log is not that.

When to use it

When the research will outlive the session you started it in.
When you will come back to the same question more than once.
When someone other than you will need to read the evidence.
When the sources matter as much as the answer, because the conclusion will be challenged.
When you are researching several related questions and need to keep their evidence separate.
When a decision is important enough that "where did that come from" must have an answer.
When you want to know where sources disagree, not just what the consensus paragraph says.
When the topic moves and you will need to ask what changed later.
When your own agent's context window is already full of the work you are doing.
When you are handing the topic to a teammate and do not want the handoff to be a meeting.
When the same question keeps getting re-asked across your team and nobody has a shared record.
When you need the research limited to particular domains, dates, languages, or source kinds.
When a previous run stopped partway and redoing its finished work would be a waste.
When you are gathering background for something that ships weeks from now.
When you want the research to accumulate rather than be re-derived every time.
When you need a durable record for a review, a diligence process, or a postmortem.
When you cannot sit and watch the run finish and need it to survive you walking away.

Persistent Researcher

How it works

Agent environment

Run it from your own agent

Copy prompt

Run it from the command line

Use cases

Why use this agent

When to use it

Similar agents

Persistent Agent

Ensemble Agent

Adversarial Team