Agent · Planned

Task Board

Works an ordered list of tasks to the end, giving each one a fresh agent that has not been worn down by the last ten.

Task Board takes a list of tasks you already decomposed and works through it one task at a time. Each task gets its own brand-new agent, and that agent is thrown away when its task ends, so task forty is never done by something carrying the accumulated context of tasks one through thirty-nine. You give the board either as literal task arguments in the order they should run, or as repeated Markdown files where each whole file is one task. The file form is what you want when a task has headings, code blocks, or acceptance criteria that would not survive a shell argument. A board holds up to 500 tasks, each up to 20,000 characters.

Each agent still knows what came before it, but only as much as you allow. By default it reads short summaries of the previous ten results, which keeps the prompt the same size no matter how long the board gets; you can narrow that window, or switch it off so every task runs with no knowledge of the others. When your tasks have real dependencies, you can declare them, and each task then reads only the tasks it depends on and runs after them. Summaries are cut deterministically without calling a model, so the same board produces the same prompts every time.

When a task fails, the board either stops and returns everything completed up to that point, or records the failure and keeps going. You choose which before the run starts, and the right choice depends on whether later tasks depend on earlier ones. A retry sends the identical prompt to a fresh agent, which recovers from a crash or a timeout rather than from a task the agent could not do. Results are addressed by board position, so after a failure you know exactly which task stopped.

runtime
local
one-time
task-board
ordered-tasks
fresh-agent-per-task
context-isolation
windowed-summaries
dependency-graph
dag
batch-execution
decomposition
migration
failure-policy
retries
long-plans
prompt-size-control

Use cases

01
You have a plan with thirty steps, and every attempt to hand it to one agent ends the same way. The first six steps are done well, the next ten are done badly, and the rest are not done at all. By step fifteen the agent's context is mostly transcript, and it is optimizing for finishing rather than for getting each step right. Prompting harder does not help, because the problem is one agent holding the whole plan.
How the agent solves it
Pass each step as its own task, in the order the plan runs. Each task gets a fresh agent, so the quality of step twenty-eight does not depend on how cluttered the context was by step twenty-seven. Keep each step small enough to be one complete unit of work that can be judged on its own. Leave the default context window on so each agent sees short summaries of the steps just before it. Read the board's results by position to confirm each step finished.
What to run
1. Prompt
  Paste this page's copy prompt into your coding agent and have it turn your plan into numbered, standalone task statements.
2. Command
```
vidbyte-cli runtime task-board "<task 1>" "<task 2>" "<task 3>" --window 5
```
What you get
A thirty-step plan finished at the same quality on the last step as the first.
- Every step done by an agent that has never seen the earlier transcripts.
- Short summaries of recent steps carried forward so the plan stays connected.
- A result for each board position, so you can check steps one by one.
02
Your tasks are too long and too structured to pass as shell arguments. Each one has headings, code blocks, and a list of acceptance criteria, and quoting all of that on a command line mangles it. Flattening a task into one line throws away exactly the structure that told the agent what done looks like. You need each task delivered to its agent exactly as you wrote it.
How the agent solves it
Write each task as its own Markdown file and pass one file option per task, in the order the tasks should run. Each file is read whole and used verbatim, so headings, lists, and blank lines reach the agent exactly as written. A file's own lines are never split into separate tasks. Do not mix files and literal task arguments in one board, because board order would be ambiguous and the CLI rejects it. Number the file names so the order on disk matches the order on the board.
What to run
1. Command
```
vidbyte-cli runtime task-board --task-file tasks/01-audit.md --task-file tasks/02-schema.md --task-file tasks/03-migrate.md
```
What you get
Structured tasks delivered intact, each to its own agent.
- Acceptance criteria that survive the trip instead of being flattened.
- Code blocks and headings reaching the agent exactly as written.
- A board order that matches the numbered files on disk.
03
You decomposed a job into independent tasks on purpose, so that each could be done without assumptions from the others. Now the agent doing task twelve keeps inheriting ideas from task three that do not apply to it. The whole point of the decomposition was to prevent that. With a single agent, there is no way to tell it to forget.
How the agent solves it
Run the board in isolated mode. No prior result reaches any agent, and the prompt carries no section about earlier tasks at all. That is the correct setting for tasks that were split specifically so they would not contaminate each other. Isolated mode overrides the window and summary settings rather than combining with them. Pair it with continue-on-failure, since independent tasks should not cancel each other.
What to run
1. Command
```
vidbyte-cli runtime task-board "<task 1>" "<task 2>" "<task 3>" --context-mode isolated --no-stop-on-error
```
What you get
Independent tasks that stay independent all the way through the board.
- No task sees any other task's result.
- Assumptions from early tasks never leak into later ones.
- One failed task that does not cancel the rest.
04
Your tasks genuinely build on each other, but not in a straight line. Task eight needs the output of task two, task five needs tasks two and three, and nothing needs task four. Passing every earlier result to every later task wastes prompt space and drags in irrelevant context. Passing only the last few results misses the dependency that actually matters.
How the agent solves it
Run the board as a dependency graph and declare each link explicitly. Each task then runs after its dependencies and reads only their summaries, so task eight sees task two and nothing it does not need. Links use zero-based board positions, and a task can depend on several others at once. The CLI rejects cycles, self-links, and positions outside the board before anything is charged. Execution is still one task at a time, in an order that respects every link.
What to run
1. Command
```
vidbyte-cli runtime task-board "<t0>" "<t1>" "<t2>" "<t3>" "<t4>" "<t5>" --type dag --depends-on 5:2,3 --depends-on 4:1
```
What you get
Each task reads exactly the work it depends on, and nothing else.
- Prompts sized by real dependencies instead of by position on the board.
- An execution order that never runs a task before the tasks it needs.
- Invalid links caught before the board starts.
05
One flaky task fails and takes the entire overnight run down with it. Twenty tasks had already succeeded, and now you cannot tell which of their results survived. Some failures were just a host crashing, which a second try would have fixed. You come back in the morning to a mess instead of a finished board.
How the agent solves it
Decide the failure policy before the run starts. Keep stop-on-failure when tasks depend on each other, so you get the completed prefix instead of work built on a task that never finished. Turn it off for independent tasks, so one failure does not cancel the rest. Add a retry or two when the failures you see are crashes and timeouts, since each retry sends the same prompt to a fresh agent. Read the result positions in the morning to see exactly what finished.
What to run
1. Command
```
vidbyte-cli runtime task-board --task-file 01.md --task-file 02.md --task-file 03.md --stop-on-error --retries-per-task 2
```
What you get
An overnight board that recovers from flaky hosts and never loses finished work.
- Crashed or timed-out tasks retried on a fresh agent.
- Every result completed before a real failure kept and returned.
- The failing position named, so you know where to restart.
06
A mechanical migration across a hundred files is exactly the kind of job an agent quits three-quarters of the way through. Nothing about the last twenty-five files is hard, but a single agent's attention runs out long before the list does. It declares the migration done, and you find the stragglers later. You want file one hundred handled with the same care as file one.
How the agent solves it
Make each file, or each small group of files, its own task, and let the board run them in order. Because a fresh agent takes every task, there is no fatigue curve: task one hundred gets the same agent quality as task one. Use isolated mode if the files do not depend on each other, which keeps every prompt small. Put the same completion check in each task, so every agent proves its own file is done. The board's results then show a pass or fail for every file.
What to run
1. Prompt
  Ask your coding agent: "List every file that imports lib/legacy-date and write one task per file that migrates it to lib/date and runs its tests."
2. Command
```
vidbyte-cli runtime task-board "<migrate file 1>" "<migrate file 2>" "<...>" --context-mode isolated --no-stop-on-error
```
What you get
A migration that reaches the last file instead of stopping at a comfortable point.
- The same agent quality on every file, from first to last.
- A per-file result showing which migrations passed their tests.
- Stragglers visible immediately instead of discovered weeks later.
07
Later tasks need the conclusion of an earlier task, but the summary that reaches them has been cut to fit. The default cut keeps the opening of a result and drops the end, which is where the answer usually is. The next agent reads the setup and misses the verdict. It then redoes the analysis or, worse, contradicts it.
How the agent solves it
Switch the summary mode so the budget is split between the opening and the closing of each result. That keeps a concluding answer or a final file list in the summary even when the middle is cut. Raise the per-summary character budget if the conclusions are long. Multiply the budget by the window size to predict the largest prior-results section any agent will read. Neither summary mode calls a model, so the choice is deterministic and adds nothing to your model usage.
What to run
1. Command
```
vidbyte-cli runtime task-board "<task 1>" "<task 2>" "<task 3>" --summary-mode head-tail --summary-max-chars 2000 --window 3
```
What you get
Conclusions that survive the cut and reach the tasks that need them.
- Summaries that keep both the setup and the verdict of each result.
- A predictable ceiling on how much earlier work any agent reads.
- Later tasks building on earlier conclusions instead of redoing them.

Why use this agent

Handing a general agent a thirty-step plan produces a predictable curve. The early steps are done carefully, the middle steps are done from a context window that is now mostly transcript, and the late steps are done by something that has largely lost the plot and is optimizing for finishing. There is no way to fix this by prompting harder, because the cause is structural: it is one agent and one context, accumulating. A board fixes it structurally too, because each task gets a new agent that has never seen the earlier transcript. The decomposition you already did carries the plan forward, instead of one context window trying to hold all of it.

The second thing a general agent cannot give you is control over what a task knows. Either it remembers everything, which is the accumulation problem, or you start a new session, which throws away the connection between related tasks entirely. Here that is a setting you choose per board: recent summaries for tasks that build on each other, declared dependencies for tasks that build on specific earlier ones, and complete isolation for tasks that must not influence each other. Being able to say these tasks must not know about each other, and have it enforced, is a genuinely different capability from asking nicely. Prompt size stays flat as the board grows, which is what makes a fifty-task board behave like a five-task one.

The third is what happens on failure. In a single long session, a failure partway through is ambiguous: some work happened, some did not, and reconstructing which is which means reading the whole transcript. A board has explicit positions, so a failure returns the completed prefix with everything before it intact, or records the failure and continues, and you decided which before it started. Retries send the identical prompt to a brand-new agent, which recovers from a crashed or timed-out host. You always know where a board got to.

Quality decaying across plans
Every task gets a brand-new agent, so the thirtieth task is done by something as fresh as the first. The fatigue curve of one long session does not exist here. The last step gets the same care as the first.
Context crowding out work
No agent thread is ever reused, and the only thing carried forward is a bounded summary you sized yourself. Prompt size stays flat however long the board grows. The work never has to compete with a transcript.
Independent tasks contaminating each other
Isolated mode means no prior result reaches any agent. The prompt carries no section about earlier tasks at all. A task cannot inherit an assumption you decomposed it specifically to avoid.
Dependencies passed by position
Declared dependencies let each task read only the tasks it actually needs. Task eight can build on task two without dragging in tasks three through seven. The prompt reflects the real shape of the work instead of the order you typed it.
Unpredictable prompt size
The window multiplied by the per-summary character budget gives you the worst case for the earlier-work section. You can compute it before you run anything. A long board never surprises you with an oversized prompt.
Summaries that drift between runs
Both summary modes are deterministic text operations that call no model. They behave identically on every run. Two runs of the same board produce the same prompts, so their results are actually comparable.
One failure destroying everything
A stopped board returns every result finished before the failure rather than discarding the batch. The completed prefix is real work you keep. A failure at task twenty costs you one task instead of twenty.
Forced into one failure policy
You choose stop-on-first-failure for dependent tasks and continue-anyway for independent ones. The choice is made before the run starts rather than after it breaks. That is the only time it is really a choice.
Flaky hosts sinking boards
Retries send the identical prompt to a fresh agent, which is the right recovery for a crash or a timeout. A task that succeeds on a retry produces exactly one result, never a duplicate. The board stays readable after a rough night.
Not knowing where it stopped
Results are addressed by board position rather than by whatever a transcript happens to say. A failed task leaves the positions aligned. You can see exactly which task stopped and restart from there.
Structure lost in arguments
A whole Markdown file can be one task, read verbatim with its headings, lists, and blank lines intact. Acceptance criteria survive the trip instead of being flattened into a shell argument. The agent sees the task the way you wrote it.

When to use it

When you already decomposed the work and the decomposition is the part you trust.
When a single agent has repeatedly quit three-quarters of the way through this job.
When quality visibly decays across a long plan.
When the tasks were split specifically so they would not contaminate each other.
When later tasks build on earlier ones and need a bounded amount of that history.
When tasks depend on specific earlier tasks rather than simply on the one before.
When prompt size is the constraint and it has to stay flat as the list grows.
When each task is long and structured enough to deserve its own file.
When the job is mechanical and wide, such as a migration applied file by file.
When one failure must not cancel the twenty tasks that already succeeded.
When one failure must stop everything, because later tasks depend on it.
When the host is flaky and a retry on a fresh agent is the right recovery.
When you need to know exactly which position a long run stopped at.
When the run will take hours and you will not be watching it.
When the conclusion of one task has to reach the tasks after it intact.
When the plan is stable and what you need is execution, not more planning.
When two runs of the same board need to see identical prompts.

Agent environment

Pricing

$0.02 per board

runtime
local
one-time

Task Board is a runtime: it runs on your machine through the Codex CLI you already installed, against your own OpenAI account, and the task text itself is never sent to Vidbyte. The CLI states a one-time flat charge of $0.02 for a whole board, however many tasks it holds, while every task and every retry is model usage on your own subscription. A large board with a high retry count therefore multiplies your own model spend even though the Vidbyte charge is taken once. Codex is the only supported host today.

This agent is not live yet. The command has shipped in vidbyte-cli, but the Vidbyte route that admits a board has not landed, so a board cannot be paid for or started today, and `vidbyte-cli runtime list` does not show it. Setup is otherwise the same as the other runtimes: install vidbyte-cli, log in with your Vidbyte key, add balance at the usage page, and store an OpenAI key with `vidbyte-cli provider login openai`. The install prompt below runs those checks with your own coding agent and then looks for the board in the runtime list, which is where it appears the day the route lands.

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. Task Board also needs an OpenAI key stored for Codex, and then it is one command whose options decide what each task knows and what happens on failure. The command has shipped, but the Vidbyte route that admits a board has not, so the invocation below is ready and not yet runnable.

```
git clone https://github.com/cerredz/Vidbyte-cli
cd Vidbyte-cli
python -m venv .venv && source .venv/bin/activate
python -m pip install -e ".[dev,codex]"
```
Installs vidbyte-cli, the command line every Vidbyte agent is started and tracked from. It is at version 0.1.0 and is not published to PyPI yet, so it installs from source into a virtual environment rather than with a bare pip install. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked and the command is on your PATH.
Subcommands
-e
Installs the package in editable mode, pointing at the folder you cloned instead of copying it somewhere else. A later `git pull` in that folder updates the CLI without a reinstall. This is the install mode the CLI's own README documents.
".[dev,codex]"
Adds the optional extras on top of the base package. The codex extra carries the Vidbyte SDK's Codex integration, which every agent that drives Codex needs, and dev carries the build and lint tools from the README's development install. Git has to be installed, because the SDK revision is fetched from source.
```
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.
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.
```
vidbyte-cli provider login openai
```
Stores the OpenAI key that every task's agent will run against, separately from your Vidbyte key. Every task and every retry is billed to that account. The CLI resolves the key from OPENAI_API_KEY first, then from this stored profile.
Subcommands
--with-token
Reads the OpenAI key from standard input instead of a hidden prompt. Use it in scripts and CI, piping the key from your secret store. The key never has to appear in the command line or your shell history.
--allow-file-fallback
Approves storing the key in a permission-restricted file when no operating-system keyring is available. Without it, the command asks first or refuses when it cannot ask. Anything running as your user can read that file.
```
vidbyte-cli runtime task-board "<task 1>" "<task 2>" "<task 3>"
```
Runs a board where each argument is one complete task statement and the order you type them is the order they run. Each task gets its own fresh agent that is discarded when the task ends. By default each agent reads short summaries of the tasks immediately before it.
Subcommands
--task-file
Adds one Markdown file as one whole task, repeated once per task in board order. The file is read verbatim, so headings, lists, and code blocks reach the agent intact. It cannot be combined with literal task arguments, because board order would be ambiguous.
--context-mode
Chooses windowed-summaries, the default, or isolated. In isolated mode no earlier result reaches any agent and the prompt has no earlier-work section at all. Use it for tasks that were decomposed so they would not influence each other.
--window
Sets how many immediately preceding results an agent may read, from 0 to 25, defaulting to 10. A smaller window keeps prompts tighter; a window of 0 leaves an agent with only its own task while still telling it earlier tasks ran. It is ignored in isolated mode.
--type
Chooses linear, the default, or dag. In dag mode tasks run in an order that respects declared dependencies, and each agent reads only its direct dependencies' summaries instead of the recent window. Execution stays one task at a time in both modes.
--depends-on
Declares one dependency as CHILD:PARENT, using zero-based board positions, with several parents separated by commas. Repeat it once per link, and it requires --type dag. Cycles, self-links, and positions outside the board are rejected before anything is charged.
--summary-mode
Chooses how a long earlier result is shortened: truncate-tail, the default, keeps the opening, while head-tail splits the budget between the opening and the closing. Head-tail is what preserves a concluding answer. Neither mode calls a model, so the result is deterministic.
--summary-max-chars
Sets the character budget for one earlier-result summary, from 100 to 8000, defaulting to 1200. A result under the budget passes forward untouched, and a longer one is cut and marked with how much was removed. Multiply it by the window to predict the largest earlier-work section.
--stop-on-error / --no-stop-on-error
Decides what happens the first time a task runs out of attempts. The default stops the board and returns every result completed before the failure. The no- form records the failure, keeps positions aligned with a placeholder, and starts the next task anyway.
--retries-per-task
Sets how many extra attempts a failed task gets, from 0 to 3, defaulting to 1. Each retry sends the identical prompt to a brand-new agent, so it recovers from crashes and timeouts rather than from a task the agent could not do. Every attempt is model usage on your own account.
--idempotency-key
Recovers an admission whose response you never saw, so the balance is not charged twice for the same board. Leave it out and a fresh key is generated for every new board. Reusing a key does not resume the board: the tasks run again from the first one.
--host
Names the coding agent that runs every task, and accepts auto or codex. Codex is the only supported host today, so the flag keeps scripts explicit as more hosts are added. An unsupported host fails before payment rather than partway through the board.
```
vidbyte-cli runtime list
```
Lists the runtimes Vidbyte will admit, with the charge for each read from Vidbyte's catalog. Task Board does not appear there yet, because its admission route has not landed. The day a runtime.task-board line shows up, the board is runnable.

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 Task Board invocation for your job.

You are helping me build a board for Vidbyte's Task Board, which runs an ordered list of tasks one at a time, each in its own fresh Codex agent. Ask me these one at a time and wait for each answer: (1) the overall job and what the repository should look like when the whole board has run, (2) whether the tasks depend on each other, are fully independent, or depend on specific earlier tasks, because that decides windowed, isolated, or dag mode and the failure policy, (3) how big each unit of work should be — a board holds up to 500 tasks of up to 20,000 characters each — and (4) which steps are risky enough to deserve retries. Then write the board out as numbered task statements, each one a complete instruction that stands alone without the others, and give me the exact command including the context mode, window or `--depends-on` links, and failure flags, with one sentence of reasoning for each. Tell me if any task is too large and should be split. Note that this agent's admission route has not shipped yet, so the board is ready but not yet runnable.

Copy install prompt

Paste this into your own agent and it will check what is already installed and logged in, then walk you through only what is missing.

Set me up to use Vidbyte's Task Board. Run the checks below yourself, in order, before you ask me anything, and let each result decide the next thing you say. Never ask me to paste an API key into this conversation.

1. Run `vidbyte-cli --version`.
   - If it prints a version, say so in one line and go to step 2.
   - If the command is not found, say: "It looks like vidbyte-cli isn't installed yet. Do you want me to install it for you?"
     - Yes: it is at 0.1.0 and not on PyPI, so install from source: clone https://github.com/cerredz/Vidbyte-cli, create a virtualenv, run `python -m pip install -e ".[dev,codex]"`, then re-run `vidbyte-cli --version`.
     - No: tell me the install is the one thing every agent needs, and stop.

2. Run `vidbyte-cli whoami`.
   - If it prints "Authenticated as", I am logged in. Go to step 3.
   - If it prints "Authentication is required.", ask: "You're not logged in yet. Do you already have a Vidbyte API key?"
     - Yes: ask me to run `vidbyte-cli login` in my own terminal. It takes the key at a hidden prompt and checks it before storing it in my keyring. Re-run `vidbyte-cli whoami` when I say it is done.
     - No: these two steps are browser-only, so give me one link at a time and wait. First https://vidbyte.pro/login, where Google sign-in creates the account. Then https://vidbyte.pro/settings/api, where I create a key that is shown once. Then have me run `vidbyte-cli login` myself.

3. Ask: "Have you already added balance to your Vidbyte account?" The CLI cannot read a balance, so ask rather than guess.
   - No or not sure: send me to https://vidbyte.pro/usage to add balance, and wait for me to confirm.

4. Run `vidbyte-cli runtime doctor`.
   - If the codex line says "not found", say: "Task Board runs through the Codex CLI and this machine does not have it. Do you want me to install Codex?" Install it only if I say yes.
   - Then run `vidbyte-cli provider whoami openai`. If it fails, say: "Codex needs an OpenAI key and none is stored. Please run `vidbyte-cli provider login openai` in your own terminal, so the key never passes through this conversation." Wait for me, then re-run it.

5. Run `vidbyte-cli runtime list`.
   - If no line starts with runtime.task-board, tell me: "You're set up for Task Board. Its command has shipped in the CLI, but Vidbyte's route that admits a board has not landed yet, so there is nothing to run today." Then stop, because setup is done and there is nothing to launch yet.

When every check passes, tell me what each one returned in one short list, then give me this command to start: `vidbyte-cli runtime task-board "<task 1>" "<task 2>" --window 5`.

Similar agents

Stages Agent
Pick this one instead when the work moves through named phases that each need a different kind of attention, rather than a flat list of comparable tasks.
Open agent page →
Persistent Agent
Pick this one instead when the job is one task that needs to be pushed all the way to done, not many tasks in sequence.
Open agent page →
Ensemble Agent
Pick this one instead when you do not yet have a decomposition you trust and the plan itself is the open question.
Open agent page →

Agents

One job, one workflow, one deliverable. See how Task Board compares to the rest of the lineup.

Browse all agents →