When I shipped KittyClaw two weeks ago, the tool did one thing: serve as a board.
The Claude agents ran alongside - first by hand, then via a : a Node script polling KittyClaw's API, triggering the right agent based on who was assigned to which ticket.
The dispatcher worked great.
It orchestrated Aekan's 13 agents for weeks.
But it was an external process: one more to launch, a state file () to keep in sync, logs to dig up in , a config to copy-paste across projects in JS.
Today, the dispatcher doesn't exist anymore.
Orchestration lives inside KittyClaw.
I run on KittyClaw, nothing else.
Aekan's 13 agents still run - but the infra that drives them is now a first-class citizen of the board.
This shift from "dispatcher on the side" to "dispatcher inside the board" is small in lines of code, but it completely changes what the tool is.
And how I work.
This piece documents KittyClaw, the kanban orchestrator at the center of the Ekioo agent-fleet R&D.
Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), KittyClaw runs the AI agents that drive these projects in production.
Before: two processes to run, two places to look The old setup was three stacked layers: KittyClaw - the board, with its UI and REST API. - a separate Node script in the project's , launched manually in a terminal.
Claude Code - the agents themselves, launched by the dispatcher.
It worked.
But every project had its own , usually forked from Aekan and hand-adapted.
Patterns duplicated: 30s polling, lock, evaluator debounce, daily budget.
Adding a feature (say or ) meant re-coding it in every dispatcher, or accepting that one project had it and others didn't.
And visually, orchestration was invisible from the board.
To see an agent's live activity, I'd pop a terminal, the dispatcher log, cross-reference with the board.
Two places, two vocabularies.
The board didn't know there was a dispatcher.
The dispatcher showed nothing on the board.
They talked through the API and a JSON file - fully functional, but decoupled to the point of not knowing each other.
The click: the dispatcher belonged inside KittyClaw What pushed me over was the pile-up of small repeated frictions.
Every new project, I duplicated .
Every useful feature (like Lain's CEO wake on idle board), I'd ask myself "do I back-port it to Aekan?".
Every bug, "which of the three dispatchers is running this one?".
And above all: KittyClaw already had all the info.
Tickets, assignments, columns, members flagged as agents, history.
The dispatcher only re-read what the board already knew, to decide what to launch.
Duplicated reasoning, not data.
If it's repetitive across projects, it belongs in the engine.
If the board already knows the state, it's the best-placed thing to react.
After: the board is the orchestrator The new workflow is one step: I create a ticket on the board, assigned to .
That's it.
Thirty seconds later, KittyClaw sees the ticket in the column with assignee , moves it to , and launches Claude Code with the skill and the ticket context.
Outputs stream into a live run panel.
When the agent finishes, the ticket is ready for review.
What makes this workflow possible is an file in the project workspace: No magical engine.
It's a 30s poll that reads the board, matches a pattern, and launches a process with the right skill and context.
But once it's in place, I'm no longer in the loop.
I become a supervisor.
What changes mentally The time saved is real - no more switching, no more sessions to locate, no more commands to retype.
But the real shift is elsewhere.
With the external dispatcher, I'd already moved past one-on-one chat.
The board + dispatcher formed a running team.
But the whole thing was fragmented: I watched the board to decide, a terminal to see what agents were doing, logs to debug.
Three views for one system.
Now, the board is the system.
I see global state, I assign, I let the infra dispatch, I watch streaming runs from the ticket