WTmag
Conversational task-to-PR orchestration. Think through work with your orchestrator, pull from GitHub Issues, Linear, Jira, and more, and dispatch parallel AI workers in isolated environments to get it done.
type
AI DEVTOOL
Role
AI Product Engineer
platform(s)
CLI / Open Source
website
wtmag.dev
WTmag is a local agent orchestration CLI I built to close the gap between having a task and having an agent working on it. The starting point can be a real conversation: talk through a problem with your orchestrator, shape a rough idea into a brief, write it up as a ticket, or point it at an existing task pulled from GitHub Issues, Linear, Jira, or any source WTmag is configured for. Either way, it creates an isolated Git worktree, starts a tmux worker, and spawns an agent with the full context.
The design is built around a two-tier model. You run an orchestrator agent in your main session. It understands a bundled skill that lets you work through things naturally: brainstorm an issue, flesh it out, point it at an existing ticket, or ask it to pull everything open for review, and dispatches parallel workers without you having to context-switch. Each worker gets its own worktree, its own session, and its own running agent.
I built and maintain WTmag as a solo project, written in Go. I live on the terminal: tmux, Neovim, CLI tools first. WTmag came out of not wanting to rely on GUI orchestration tools to manage agent work.
How It Works
One conversation. As many parallel workers as the work requires. Talk through what needs doing, pull from any connected source, and WTmag handles the rest while you keep moving.
You load the WTmag orchestrator skill into your agent and start a conversation. That conversation can go anywhere: work through a rough problem and define it into a task, reference an existing ticket by number, or ask it to pull open issues from whatever sources it’s connected to. The orchestrator fetches the full context and dispatches workers accordingly.
WTmag is built to be extensible at its core. GitHub Issues and Jira ship built-in, but the task source system is open: teams can connect Linear, Asana, GitLab Issues, or any platform they already track work in. The same principle applies to agents. Either side of the system can grow without the other changing.
The Workflow
You open a tmux session on your default branch, load the WTmag orchestrator skill, and start talking. The conversation can be as exploratory as you need: work through a problem, define the scope, pull in an existing ticket from wherever your team tracks work, and the orchestrator turns it into parallel dispatch, one worker per task.
Each worker defaults to a window inside your current tmux session. When a task grows, promote it into a dedicated session with a single command. When it is done, WTmag removes the worktree and tmux target together. You can attach to any running worker by id, or fuzzy-find it with tmux-sessionx and jump straight in.
Supported Agents
WTmag ships with built-in support for pi, opencode, Claude Code, and Codex. All four spawn in interactive TUI mode so you can jump in and work alongside the agent at any point. The default agent and launch preferences are configurable globally or per project, and always overridable on a per-command basis.
Custom agents are fully supported. Define your own with a name, a command, and how it receives prompts, and WTmag handles the rest. WTmag intentionally stays out of credential management; every agent authenticates through its own native flow, so there is nothing extra to configure on WTmag’s side.
The Takeaway
The problem WTmag solves is friction. The gap between having a task and having an agent working on it in an isolated environment used to involve several manual steps. WTmag collapses that into one command, or zero if you are talking to the orchestrator.
The tmux-native design was deliberate. It keeps you close to the work, lets you intervene without ceremony, and makes the whole system feel like an extension of the terminal workflow rather than a replacement for it. That is the bar I hold AI tooling to: it should make the work feel lighter, not introduce a new layer to manage.
Most tools I reach for daily are terminal-native. WTmag is how that stays true for agent work too. If you are the kind of engineer who lives in the terminal and wants to keep it that way, this is built for you.
