How we built KittyClaw using KittyClaw — the recursive agent workflow
I launched an open-source AI-agent kanban board last week. Small launch, real lessons. The meta story is the interesting part: the tool built itself.
KittyClaw is a Blazor Server kanban board that dispatches Claude Code agents against your project tickets. You write a ticket, assign it to an agent, and the agent executes it — then posts a comment, moves the card, and updates its memory file for next time.
The recursive part: we used KittyClaw to build KittyClaw.
The numbers first
At the time I'm writing this (J+7 post-launch):
- 81 tickets created on the KittyClaw-Front project board
- 57 Done (70% close rate)
- 140 git commits — most of them agent-authored
- 10 agents active: programmer, producer, lain (growth), qa-tester, groomer, committer, evaluator, code-janitor, channel, daily-recap
- 55 of 57 Done tickets closed by agents — the remaining 2 were owner actions (social media, things that require a human body)
I wrote maybe 20 commits myself. The agents wrote the rest.
What the board looks like in practice
Every feature, every launch copy, every dev.to article has a ticket. Tickets have a description with acceptance criteria, a priority, and an assignee (the agent slug). When you move a ticket to Todo, KittyClaw's automation engine polls the board every 30 seconds and fires the matching agent via the Claude Code CLI.
The agent gets:
- A system prompt (
.agents/{agent}/SKILL.md) — their job description and rules - The ticket description — the specific task
- Their memory file (
.agents/{agent}/memory.md) — lessons from previous runs - The preamble (
.agents/preamble.md) — shared project context
Then they execute, post a comment with the result, and move the card to Review (or Done if it's self-validating work).
The board is the interface. The agents are the workers. The human is the tech lead who writes tickets and reviews diffs.
A real example: the waitlist email sequence
One of the early tickets: "Deploy kittyclaw.dev on Cloudflare Pages — with a waitlist signup that sends a welcome email sequence."
What happened:
- The programmer agent integrated Brevo's API into the Cloudflare Pages Worker —
POST /v3/contacts, list ID wiring, trigger logic - The programmer shipped a 3-email welcome sequence: day 0 (welcome), day 3 (feature highlight), day 7 (soft CTA)
- The code-janitor agent, running a routine audit on a later pass, flagged that the Brevo API key was hardcoded in client-side JS (real security catch, not a style issue)
- The programmer agent fixed it, moving the key to a Cloudflare Pages secret
I reviewed the diff. It was good. I approved.
The sequence has been live since launch day and sent ~7 welcome emails to real subscribers.
What worked better than expected
1. Agents improve over runs.
The memory file is the key. After each run, agents update their own .agents/{agent}/memory.md with lessons — what worked, what failed, patterns to avoid. By run 10, the programmer agent had internalized "Windows paths use forward slashes in curl commands" and stopped making that mistake. No prompt engineering needed — just compounding context.
2. The lain orchestrator decomposed epics correctly without being told how.
Some tickets started vague: "Run a ClawDeck migration campaign." The lain agent broke that into sub-tickets with correct assignees, priorities, and parent IDs — producer for copy, programmer for landing page, owner for outreach. I didn't write a rule for this decomposition pattern. It derived it from the structure it observed in existing tickets.
3. QA caught real bugs.
The qa-tester flagged a broken referral attribution bug where utm_campaign had a fallback value that labeled all organic traffic as campaign traffic, and several cases where the programmer's output didn't match the acceptance criteria. Not rubber-stamping. Actual quality gating.
What didn't work
1. Ambiguous tickets produce bad output.
When the ticket description was vague — "improve the website" — the programmer agent made changes that weren't wrong, but weren't what I wanted. The solution: write every ticket as if briefing a junior developer. Specific, with acceptance criteria, with "done looks like X."
2. Complex UI work exceeded the programmer agent's reliable range.
The programmer agent is reliable at CRUD operations, API integrations, config changes, and self-contained JS functions. It struggles with multi-file UI refactors where context spans 5+ files. I learned to split those tickets: one ticket per component, not one ticket for the whole feature.
3. Agents occasionally forgot the project slug.
Early runs had agents calling /api/projects/undefined/tickets. The fix was promoting it to the SKILL.md as a rule: "Your project slug is kittyclaw-front. Use it in every API call." This is now in every SKILL file.
The key insight: agents replaced execution, not judgment
The agents didn't figure out what to build. I did. They didn't decide the architecture. I did. They didn't write the tickets. I did.
What they replaced: the time between "ticket written" and "ticket done."
For a solo founder, that's 80% of the calendar. Coding, writing copy, running manual QA, updating configs, committing — these are all agent-sized tasks if you brief them well. The bottleneck moved from doing the work to specifying the work clearly enough that the agent can do it right.
That turns out to be a genuinely different skill. It's closer to tech lead than engineer. And it's faster — a lot faster.
The meta-lesson about agentic tools
Most AI coding tools are about speeding up a human writing code. KittyClaw is about replacing the human in the loop for routine execution entirely.
The difference matters because:
- Async execution: agents run while you're doing something else. You're not in a chat waiting for output.
- Persistent memory: agents get better at your specific project over time, not just at code in general.
- Structured handoffs: the kanban board forces every agent output to be reviewable before it moves forward. No runaway agents.
Is it production-ready for every workflow? No. It's v0.1 alpha. There are rough edges. But for a solo developer building a SaaS product, it's already meaningfully faster than working alone.
What's next
- 8 GitHub stars right now. We're building in public — if this resonates, a star goes a long way for discoverability: github.com/Ekioo/KittyClaw
- Hosted version coming in July — if you want early access, leave your email at kittyclaw.dev
- Next agent we're adding: a dedicated architect agent for breaking down complex technical epics before they hit the programmer
- Multi-agent parallelism: right now agents run sequentially per trigger. We're working on parallel execution for independent tickets.
Try it
KittyClaw is MIT-licensed and self-hosted. You need:
- .NET 10
- A Claude API key (BYOK)
- A project you want to accelerate
Setup takes about 5 minutes. The first agent run is usually within 10.
What would you add to KittyClaw? Drop it in the comments — the next agent I build might be the one you need.
If this was useful, a ❤️ helps more developers find it.
Top comments (0)