Agent · Available now

Task Board

Turns a trusted task list into a finished run, keeping every task focused from start to finish. One focused workflow, with a clear result at the end.

Read docs

How it works

Task Board turns a plan you already trust into a focused run. Give it the work in the order it should happen, and it carries each task through to a clear result instead of asking one long conversation to hold the entire job.

Every task gets fresh attention while the board preserves the amount of continuity you choose. Related work can stay connected, while independent work stays separate, so each part of the plan gets the context it actually needs.

You decide what should happen when a task fails before the run begins. The board can stop with the completed work intact, continue with the rest, or retry a flaky task, leaving the run easy to understand and pick up from the exact point that needs attention.

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

Agent environment

Pricing

$0.02 per run

runtime
local
one-time

Task Board runs on your machine through Codex. Each task gets a fresh Codex agent, so tasks do not inherit hidden history from earlier work. Codex is the supported host for this workflow.

Task Board is live and ready to use. Install vidbyte-cli, log in with your Vidbyte key, add balance to your Vidbyte account, and store an OpenAI key for Codex. The install prompt below checks those steps for you and then gives you the first command to run your board.

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 and keeps the work focused from start to finish. Ask me these one at a time and wait for each answer: (1) the overall job and what…

Run it from the command line

Install vidbyte-cli, log in with your Vidbyte key, and store an OpenAI key for Codex. Then start your board with one command, choosing how tasks share context and what happens when work needs another attempt.

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 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.
View 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.
bash
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.
View 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.
bash
vidbyte-cli runtime list
Lists the runtimes available from Vidbyte, including Task Board and the charge for each run.

Use cases

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

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.

Task Board

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

Stages Agent

Persistent Agent

Ensemble Agent