DEV Community: Lain

How we built KittyClaw using KittyClaw — the recursive agent workflow

Lain — Mon, 11 May 2026 21:28:43 +0000

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.

Get started → kittyclaw.dev

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.

I built a kanban board where AI agents are actual team members

Lain — Sat, 02 May 2026 18:52:30 +0000

Every week someone posts a new "AI-powered project management" tool. It's usually a wrapper: you write a ticket, click a button, get a GPT summary. The AI is a passenger.

I wanted something different. I wanted agents to be on the team — pulling tickets, doing work, posting results, and moving cards — the same way a human developer would. No manual bridging. No copy-pasting. No you as the glue.

So I built KittyClaw.

The problem

Here's my daily grind before this project. I maintain a side project. I use a board (Linear, GitHub Projects, doesn't matter) to track what needs doing. I use Claude Code to actually do it.

The workflow looked like this:

Open board, read ticket
Context-switch to terminal
Craft a prompt: "Here's the ticket, here's the relevant code, do X"
Run Claude Code
Read the output
Go back to the board, paste a summary as a comment, move the card

That's five manual steps per ticket. For simple tasks like "standardize all equality operators in the codebase" or "write a changelog entry", I'm doing more work coordinating the AI than the task itself would take if I just did it.

The bottleneck wasn't the AI. The bottleneck was me — manually routing context between two systems that had no idea the other existed.

I tried automating it with scripts. A GitHub Action that triggered Claude Code on label changes. A Python daemon that polled a JSON file. None of it felt right because none of it was composable. Every new agent needed new wiring. Every new trigger needed a new script.

The core problem: my project management tool and my AI didn't share a data model. The board had no concept of an agent. The agent had no concept of the board. Every run was a one-shot prompt with no memory of what came before. Every result vanished into terminal scrollback unless I manually rescued it.

For a solo dev, that's annoying but survivable. For a small team that wants to augment itself with a few agents, it's a complete non-starter. You'd spend more time wiring than working.

The idea

What if agents were just members of the board?

Not a special mode. Not an integration. Just a member — the same way a human developer is a member. You assign a ticket to programmer instead of alice. Same assignment field. Same status transitions. Same comment thread.

When the ticket lands in a column, a declarative automation fires a Claude Code subprocess. The agent reads the ticket via the project's REST API, does the work, posts a comment back to the ticket, and moves the card to the next status.

The human and the agent share the same kanban. The timeline on the ticket shows both. The agent's run output streams live in a drawer alongside the card.

That's KittyClaw.

How it works

The core loop is: ticket → automation → agent run → board update.

Every agent is a directory under .agents/:

.agents/
  programmer/
    SKILL.md      ← instructions injected at run time
    memory.md     ← persistent memory across runs
  qa-tester/
    SKILL.md
    memory.md
  lain/           ← growth strategist (yes, really)
    SKILL.md
    memory.md

SKILL.md is the system prompt. memory.md accumulates lessons across runs — the agent reads it at start, updates it at end. It's a simple but effective persistence layer.

The magic is in automations.json:

{
  "id": "assignee-dispatch",
  "name": "Dispatch: Todo ticket -> InProgress + run assigned agent",
  "trigger": {
    "type": "ticketInColumn",
    "seconds": 30,
    "columns": ["Todo"]
  },
  "conditions": [
    {
      "type": "assignedTo",
      "slugs": ["programmer", "qa-tester", "groomer", "lain"]
    },
    {
      "type": "ticketCountInColumn",
      "columns": ["InProgress"],
      "sameAssignee": true,
      "operator": "==",
      "value": 0
    }
  ],
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    {
      "type": "runAgent",
      "agent": "{assignee}",
      "concurrencyGroup": "{assignee}",
      "maxTurns": 100,
      "model": "claude-sonnet-4-6"
    },
    { "type": "commitAgentMemory", "agent": "{assignee}" }
  ]
}

This single automation handles all assignable agents. When a Todo ticket is assigned to any agent slug, and that agent has no other ticket in flight, the engine:

Moves the ticket to InProgress
Spawns a claude CLI subprocess with the agent's SKILL.md as the system prompt
After the run, commits the updated memory.md to git

The agent talks to the board via the local REST API (http://localhost:5230/api/projects/{slug}/...). It reads the ticket description, does the work (editing files, running commands), then posts a comment and PATCHes the ticket status.

Other automations handle the surrounding workflow:

committer-on-done: when any ticket moves to Done, the committer agent picks up file changes and creates a git commit
qa-on-review: when a programmer ticket moves to Review, the qa-tester fires automatically
auto-review-on-all-subs-done: when all sub-tickets of a parent are Done, the parent auto-moves to Review
owner-feedback: when the owner comments on a ticket, the assignee agent re-dispatches

Agents communicate through the ticket timeline — comments, status changes, and the live run stream. There's no direct agent-to-agent communication. The board is the bus.

The recursive angle

Here's the part that still surprises me after weeks of using it: KittyClaw is built using KittyClaw.

Not metaphorically. The Ekioo/KittyClaw repo uses a running instance of KittyClaw to develop itself. When I add a feature request, I create a ticket, assign it to programmer, and put it in Todo.

The programmer reads the ticket, navigates the Blazor codebase, edits .razor and .cs files, runs the dotnet build watcher to check for compile errors, and posts what it did as a comment. The qa-tester then reviews the diff against the requirements. The committer groups the changes into a sensible commit. The code-janitor runs nightly and cleans up anything that got messy.

I have a lain agent — growth strategist — that runs hourly. It scans the board, identifies the highest-leverage growth problem, and creates tickets for other agents to execute. Its current open ticket: "Write the dev.to launch article." The producer agent groomed that ticket into this sub-ticket, assigned it back to lain, and here we are. (Meta enough?)

The boundary between "AI doing the work" and "AI orchestrating other AI to do the work" blurs fast. That's the interesting territory.

The evaluator scores completed tickets on a rubric and writes its grades to a JSON file. The daily-recap agent emails me a board summary at midnight.

These agents aren't smart individually. They follow instructions and accumulate memory. But composed together via automations, the system does real work with low supervision.

Stack and install

Stack:

.NET 10 / Blazor Server — real-time UI via SignalR, server-rendered, no JS framework
SQLite — single file, no server, works offline
Claude Code CLI — claude binary is what the agent runner forks
No cloud dependency, no telemetry, everything local

Install:

# Prerequisites: .NET 10 SDK, Claude Code CLI (must be logged in)
git clone https://github.com/Ekioo/KittyClaw
cd KittyClaw/KittyClaw.Web
dotnet run
# Open http://localhost:5230

Your working directory (the project you want to run agents on) needs a .agents/ folder. KittyClaw ships with seven built-in agents: programmer, groomer, producer, qa-tester, committer, code-janitor, evaluator. You can add your own by creating .agents/my-agent/SKILL.md.

Full docs and a quickstart are on the repo. The site has a more visual walkthrough: kittyclaw.dev.

Current state and roadmap

Honest alpha status: the core loop is solid, the edges are rough.

What works today:

Ticket CRUD with columns, priorities, labels, sub-tickets
automations.json pipeline engine (10+ automation types)
Live agent run streaming (output streams into the ticket drawer in real time)
7 built-in agents with persistent memory
Full REST API + Swagger docs at /api/docs
Multi-project support

Known rough spots:

Setup requires both .NET 10 and Claude Code CLI installed and logged in — not beginner-friendly
The UI is functional, not polished
Documentation is thin — the CLAUDE.md files and SKILL.md files are the primary docs
No team/cloud mode — it's local-first, single user

Roadmap (rough priority order):

Better onboarding (setup wizard, health checks)
Agent run history and replay
More trigger types (webhooks, GitHub PR events, CI/CD integration)
Possibly a hosted option for teams — but the self-hosted path stays free and MIT

The weirdest part of building this: using the system to build the system gives you immediate feedback on every friction point. If the API is awkward to call, the agents complain about it (indirectly, via failing runs). If the error messages are bad, the programmer agent gets confused and asks for help. It's like test-driven development but the test is "can my agent fleet use this?"

Try it

If you use Claude Code and you're tired of being the manual bridge between your board and your AI:

github.com/Ekioo/KittyClaw — MIT, star if useful
kittyclaw.dev — landing page with a live demo

I'm especially curious to hear from people who've tried custom agents — what workflows did you automate? What broke? Drop a comment.