About wakala

What it is

A governed task tracker built for AI agents. Tasks have a definition of done, dependencies, statuses, assignees, priority, and approval gates. The point is not to plan projects — it's to keep an agent's work honest. See the chaos and solution on the home page for the full pitch.

Why it exists

The hard part of getting agents to do real work isn't capability — it's governance. Most agent tooling optimizes for throughput: how many tasks did the agent finish, how fast, how cheaply. wakala optimizes for correctness: did the agent do the right things in the right order, and can you prove it after the fact.

That's a smaller audience than the broader agent-tool ecosystem. The people who need it are the ones shipping agent work to production and discovering that the prompt layer alone doesn't enforce their standards. For them, "the agent said it was done" isn't good enough. They need binary-enforced guardrails — a server that rejects bad transitions, not a comment that flags them.

Who wakala is for (and not for, yet)

The primary persona is the solo agent operator — one developer, one MCP-compatible agent, one project at a time. You're already shipping real work through the agent, and you've discovered that prompt discipline doesn't survive a long enough context window. The work is too important to leave to "the agent said it was done."

You're in the target audience if

• You run an MCP-compatible agent (Claude Code, Cursor, OpenCode, etc.) on real engineering work
• You've shipped something the agent "completed" that wasn't actually done
• You prefer binary-enforced rules over prompt-encouraged rules
• You want one source of truth between your work and the agent's work

Not for you, yet, if

• You need a full enterprise PM suite with custom fields, workflows, and integrations on day one
• Your team isn't using any AI agents in engineering workflows yet
• You need team / multi-tenant features (these ship later)
• You only do human-only work tracking (use a dedicated tracker; wakala assumes an agent is involved)

What's shipped

• This marketing site (home, pricing, policies, help, challenge, this page).
• The page-view logger. Every GET records six fields listed under Policies › Security › What we log.
• An MCP server for the Challenge window. Status is reflected on the live Challenge page itself — when the window is open, /challenge self-issues API keys; when it isn't, the page says so.

What's not shipped

• A web UI for human-driven task work. The MCP server is the only surface.
• Multi-tenant or team features. There is one tenant per Challenge key.
• Anything beyond the tasks module. The issues module is planned but not built.
• SDK or framework integrations. Bring your own MCP-compatible agent.

Status

Soft launch. The /challenge page is the source of truth for whether the current Challenge window is open or closed; this page does not duplicate that state. When a window is open, the MCP server mints time-boxed API keys from /challenge and the walkthrough becomes a working demo.

Stack

• Go (single binary, ~11 MB, no runtime dependencies beyond libc).
• SQLite via modernc.org/sqlite (pure-Go, no CGo).
• ~3,500 lines of static HTML, CSS, and JS (no framework, no Tailwind, no CDN except Rybbit analytics).
• Inter for prose, system mono stack for code (SFMono-Regular, Consolas, Liberation Mono, Menlo).
• Nginx Proxy Manager in front for TLS termination. Go server listens plain on :8000 (host port stays 8080 so NPM is untouched).
• One container per environment. Source-of-truth deploy: make docker-publish.

Contact

The operator is reachable at info@wakala.dev. That's a real inbox, read by a real person, with a real SLA on the order of a day or two. There is no support tier, no escalation path, no status page. If you need any of those, this isn't the right product for you yet.