If you'd rather try it first than read about it, there's a demo video and a quick tutorial that walk you through the entire workflow in just a few minutes.
By the end of it, you'll have an agent:
This article explains why I built tasq and the problems it tries to solve.
I spend most of my time building software with AI coding agents.
My workflow usually looks like this:
At first, it felt magical.
Then I started running multiple agents in parallel.
While one agent was investigating a bug, another was implementing a feature. While waiting for CI to finish, I would ask yet another agent to work on a different task.
A few days later I noticed a problem:
Sometimes an agent would finish a task and I wouldn't notice for days.
Sometimes I would discover an unfinished implementation a week later and wonder why it had stopped in the first place.
AI made software development massively parallel.
But my task management workflow was still designed for humans.
That's why I built tasq.
AI coding agent task manager.
tasq helps you turn implementation work into a visible queue, start local services for that queue, and inspect progress from both the tq
CLI and the Web UI.
Watch the Tasq introduction video.
Japanese counterpart: README.ja.md.
AI coding agents make it possible to work on multiple implementation tasks at the same time. The bottleneck moves from writing code to managing parallel work.
Agents can run in parallel, but humans still need to track which tasks were assigned, which agents are running, how far each task has progressed, and what should be reviewed next.
Running multiple agents in one repository checkout can create branch switching issues, unfinished-change conflicts, and overlapping file edits.
Each agent task often needs the same preparation steps: create a branch, create a worktree, verify dependencies, and run the right…
An AI-native task orchestrator designed for coding agents.
The obvious answer is to create more issues.
The problem is that not all tasks belong in a shared project management system.
I don't want to publish every tiny implementation detail, development experiment, or dotfiles improvement to a team-wide Linear workspace.
Many of these tasks are personal implementation notes or intermediate steps that only exist to help me finish larger work.
They also have dependencies.
For example:
I don't want to manually copy and paste these tasks into agents in the correct order.
I want the system to understand the dependency graph and schedule the work automatically.
What I needed was:
Run multiple agents and automatically consume tasks while respecting dependencies.
tasq combines three ideas:
Issues are stored locally in a database rather than in GitHub or Linear.
The orchestrator continuously watches the queue and dispatches executable tasks to coding agents.
Each task runs in its own Git worktree and branch, so multiple implementations can happen in parallel without conflicts.
tasq was heavily inspired by Codex Symphony and its orchestration model, while focusing on local-first and personal workflows.
The default implementation loop looks like this:
in_progress
.However, these steps are not hardcoded.
tasq uses WORKFLOW.md
files inspired by Symphony's workflow specification.
This means users can customize:
tasq only cares about:
Everything else belongs to the user.
In an ideal world, agents would continuously fetch tasks and finish them without interruption.
Reality is messier.
Agents may require permissions.
CI pipelines fail.
Implementations sometimes diverge from expectations.
For these situations, tasq intentionally stays lightweight.
Each issue stores the execution session identifier of the underlying coding agent.
If something goes wrong, you can simply continue from the existing session:
codex resume <thread_id>
You don't need to create another issue just to fix CI failures or tweak a generated implementation.
You simply resume the conversation and continue from where the agent stopped.
A typical tasq workflow looks like this:
tq issue create
.ready
.In practice, this often means your work becomes:
Review issues and move them to ready.
Everything else happens automatically.
tasq provides both a web interface and a CLI interface.
The CLI is primarily intended for coding agents, while the web interface focuses on issue management and orchestration visibility.
There is also a dedicated tasq skill package for coding agents so they can interact with the issue tracker without additional prompting.
There is still a lot to improve.
Current ideas include:
I personally spend most of my time inside tmux and Vim, so a TUI feels inevitable.
I also want blocked tasks to recover automatically whenever possible.
For example, if CI fails, users shouldn't need to manually resume an agent and type:
fix ci
Finally, tasq currently depends on Codex App Server and does not yet support direct execution through Claude Code.
Long term, I would like planning and implementation workflows to work seamlessly across both ecosystems.
If any of this sounds interesting, I'd love for you to try the tutorial and share your feedback.