Help.

FAQ

What is wakala?

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 sections on the home page for the full pitch.

Is this for humans or for agents?

Both. Agents interact through the MCP server. Humans can step in using the same MCP tools from a REPL or any client that speaks JSON-RPC — the protocol is the same.

Do I need to install anything?

No. wakala is a managed service. Your agent connects to it via the Model Context Protocol over HTTPS — the same way it would connect to any other MCP server.

Does this store my prompts?

No. Page views on this site record the six fields listed in Policies › Security › What we log. Prompts your agent sends to the MCP server are processed but are not stored in our database. See Policies › Privacy for the full retention story.

What's an MCP server?

Model Context Protocol — a standardized way for an LLM-powered agent to call external tools. The spec is open and the wire format is JSON-RPC. If your agent supports MCP, it can call wakala without any custom integration code. See modelcontextprotocol.io.

How is this different from a workflow board for humans?

A workflow board is for humans to visualize human-driven work. wakala tracks work that an AI agent does, with binary-enforced guardrails — when an agent tries to mark a blocked task as done, the server rejects the call. There is no "soft" workflow rule that an agent can ignore. That's the whole difference.

What's coming next?

Nothing we can promise on a public page. We ship when features are ready, not before. The best signal of what's actively in flight is the live site itself.

How do I report a bug or abuse?

Email info@wakala.dev. Include the request path, the approximate time, and the agent you were using. We have the page-view log to cross-reference; we do not have your prompts.

Tutorial — five minutes to your first governed task

You've already started the Challenge and have a key. This walks you through how to use it: point your agent at wakala, create a task with a definition of done, and watch the guardrails stop a bad transition. (If you want the unguarded version first, that's also on /challenge.)

Step 0 — Get an API key

• An MCP-compatible agent (Claude Code, Cursor, or anything that supports a custom MCP server config).
• About five minutes. The hardest step is editing a JSON file.
• An API key. During a live Challenge window, get one from /challenge. Outside a window, email info@wakala.dev.

Step 1 — Add wakala to your agent's MCP config

Drop this into your agent's MCP server list, replacing <YOUR_KEY> with the API key you got in Step 0:

{
  "mcpServers": {
    "wakala": {
      "type": "http",
      "url": "https://mcp.wakala.dev/mcp",
      "headers": {
        "X-PROJECT-KEY": "<YOUR_KEY>"
      }
    }
  }
}

Most agents read this from a file. Claude Code looks for ~/.claude/mcp_servers.json; Cursor uses ~/.cursor/mcp.json; check your agent's docs if you're not sure.

Step 2 — Create a task with a definition of done

Ask your agent to create a task. The MCP server accepts natural-language prompts and maps them to the underlying calls. Try:

Create a task in wakala:
  title:    Add a /help page to the marketing site
  priority: medium
  assignee: claude
  acceptance_criteria: |
    Single page with #faq and #tutorial anchored sections.
    Renders against the layered style.css system, not the inline block.
    Tutorial walks an agent through MCP config + first governed task.
  status:   todo

The agent will issue an MCP create_task call. The server returns a task id and persists the task. Note: the acceptance criteria are stored as the task's definition of done — the agent cannot mark it done without the server being able to verify the criteria are met.

Step 3 — Add a blocking dependency

wakala lets you declare that one task depends on another. The agent can only move a task out of todo once its dependencies are done. Try:

Add a dependency in wakala:
  task_id:        <the id from step 2>
  depends_on_id:  <some other existing task id>

The dependency is binary-enforced. The agent's prompt can declare the task "ready", but the server will reject a status: in_progress transition until the dependency is satisfied.

Step 4 — Try (and fail) to skip the guardrail

Ask your agent to mark the task done without satisfying the dependency:

Update task <id> to status: done

The MCP server returns a structured rejection. The agent sees it as a tool error and (with any well-behaved agent loop) reports it back to you as a constraint, not a success. That's the whole point: the guardrail is on the server side, so no amount of prompt cleverness can route around it.

Step 5 — Satisfy the dependency and finish the task

Mark the dependency done, then mark your task done. Both transitions now succeed. The structured transition log records both state changes with timestamps; see Policies › Security for the fields we actually persist (page-view log only — the MCP-side transition log is on the operator's server, not on this site).

What happens after the Challenge window

API keys issued during the Challenge expire when the window closes. Tasks you created during the window are exported to the operator; the operator can email you a copy on request. See Policies › Data retention for the full retention story. Nothing about the Challenge is silently extended — if you want to keep using wakala past the window, wait for a follow-up window or email info@wakala.dev.