Introducing tasq: An AI-Native Task Orchestrator for Coding Agents A developer built tasq, an AI-native task orchestrator for coding agents that manages parallel implementation work. The tool stores issues locally, respects dependency graphs, and uses Git worktrees to avoid conflicts when multiple agents run simultaneously. It was inspired by Codex Symphony and focuses on personal, local-first workflows. 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 https://github.com/user-attachments/assets/8c4fdc9c-c70b-4f86-8e0a-323f8880ffb7 . Japanese counterpart: README.ja.md https://github.com/version-1/tasq/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