Case study: Cardloop

We didn't read about AI agents. We built the thing that runs them.

Cardloop is an open-source IDE for running Claude agents on a kanban board: you write a card, an agent picks it up, and the work lands as a commit. We built it, open-sourced it under MIT, and run our own company on it: 27 projects on one board, including the site you are reading right now. Every number below can be checked against the public repository or reproduced with the command next to it.

The numbers, and how to check them

Measured 2026-09-16 on the production instance. The repository is public: github.com/igdigitallab/cardloop

3,343

automated tests covering the backend

pytest tests/ --collect-only -q

171

HTTP endpoints (77 GET, 78 POST, 12 DELETE, 2 PUT, 2 PATCH)

grep -oE 'app\.router\.add_(get|post|put|delete|patch)\(' webapp.py

27

projects run from one board

data/registry.json

324

commits, 26 June to 18 September 2026

git log --oneline | wc -l

11

built-in sub-agent roles (architect, debugger, reviewer, and more), editable in the UI

ls roles/builtin/*.md | wc -l

10

custom tools the agent can call: 9 drive the built-in browser, 1 consults a second model

grep -rn '^\s*@tool(' *.py features/*.py

6

GitHub stars, 0 forks, 0 open issues. We have not run a marketing push for it

curl -s https://api.github.com/repos/igdigitallab/cardloop

What it actually does

  1. Authentication and roles. One shared web password plus optional TOTP two-factor login. This is a single-operator tool, not a multi-tenant app. Inside a project, an agent runs under one of 11 declarative roles (architect, debugger, reviewer, and more), each editable in the UI and overridable per project.
  2. Data. No relational database. Project state lives in JSON files; a SQLite FTS5 index gives full-text search across chat, board, timeline, files and memory, with word-stemming, through its own CLI.
  3. Real time. Server-Sent Events stream chat and activity; separate WebSocket connections drive an in-browser terminal (xterm.js) and a live, controllable browser panel the agent can navigate while the operator watches from a phone.
  4. Isolation. Every card runs on its own git worktree and branch, so two agents editing the same repository cannot corrupt each other's commits. A diff sits behind a manual Apply/Discard gate before it merges.
  5. Integrations. A second agent engine (Codex) runs behind a feature flag alongside Claude. The live browser has three swappable backends: built-in Chromium, our own anti-detection browser, or an external session that is already logged in. A paid bridge solves widget-style captchas (reCAPTCHA, hCaptcha, Turnstile).
  6. Security. Secrets sit in a per-project Fernet-encrypted vault, decrypted only for an authenticated session. The agent gets full host access by design, with no sandbox, and destructive commands (a force-push, an rm -rf) go through a separate approval gate instead of running unchecked.
  7. Deployment. Runs as a systemd service or in Docker. A canary rollout script waits for the service to sit idle, restarts it, runs a post-restart health check, and rolls back to the previous release automatically if that check fails.

What it is not

The part that makes the rest of this page checkable.

Self-hosted only

There is no hosted version to sign up for. The product is a git repository and a Docker Compose file. Running it means running it on your own server.

One contributor

Every one of the 324 commits in the public history comes from the same author. No outside pull requests or issues yet.

Full host access, not a sandbox

The agent runs with full access to whatever host it is installed on. We gate the commands that can do real damage; we do not pretend there is a sandbox underneath.

English-only interface

UI, logs and code are English by design, since the project is open source. Only the agent's own replies to the operator can be set to another language.

Engineering decisions worth explaining

  1. One event stream for both the chat and the automation. A live conversation with the agent and an unattended card run from the board go through the same async generator and the same session, not two separate code paths that quietly drift apart, which is a common failure mode in tools like this.
  2. Isolation through git worktrees, not containers. Cheaper than spinning up Docker-in-Docker for every card, but it needs a clean git tree. On a dirty repository, Cardloop honestly falls back to a less-isolated "legacy" mode instead of silently pretending the isolation is still there.
  3. Deferred runs instead of a broken task. Hitting Claude's five-hour usage limit mid-task does not fail the run. The engine pauses, polls the quota, and continues on its own once the limit resets, and that is the detail that decides whether you can leave an agent working overnight.
  4. A canary deploy grown out of a real incident. The restart script's health check retries 12 times over roughly a minute before it rolls back, because an earlier version rolled back a healthy deploy: the port was listening in about 3 seconds, but the event loop was still finishing startup work for another 10–15.

Why this matters if you are hiring us

An agency that builds and runs its own tooling is a different claim than one that resells someone else's. Cardloop is how we run 27 projects, including the site you are reading right now, from one board. If we build something for your business, this is the discipline it inherits: isolation before a change ships, a test suite that runs on every push, and a rollback path that does not depend on someone noticing at 2am.

Tell us what's slowing you down.

We reply the same business day.