Paca: a self-hosted Scrum board where AI agents hold a seat

The problem Paca targets: agents that live outside the process

Most teams that use AI in software delivery keep the agent in a separate window. It writes code or drafts a ticket, a human copies the result into Jira or Trello, and the board records only the human half of the work. Paca is built on the opposite premise: an AI agent is assigned to a sprint, appears on the Scrumban board next to human teammates, picks up tasks from the backlog, updates status, and contributes to BDD specs and System Design Documents. The README frames this against the Cynefin and Stacey frameworks, arguing that complex work needs teams rather than pipelines.

The audience is narrow and specific. It is a Scrum team, or a team running something close to Scrumban, that already has agents doing real work and wants that work visible in the same backlog humans use. The README positions Paca against Jira, Trello, ClickUp, and Monday on three axes: agents as first-class participants rather than chatbot add-ons, self-hosting so the data stays on infrastructure you control, and no per-seat cost. The project describes itself as free and Apache-2.0 licensed.

How Paca is put together: a small core, config, and WASM plugins

The repository layout tells most of the story. The top level holds apps/, deploy/, docs/, scripts/, and services/ alongside the usual community files. The README states that the backend is written in Go and that Paca ships as a small, focused core with everything else optional. Workflows, statuses, field definitions, board layouts, sprint rules, and agent behavior are driven by project-level configuration files, so adapting the process does not require touching code.

Extension happens through plugins, split into two trees. Backend plugins compile to WebAssembly and can be written in Go, Rust, AssemblyScript, or anything else with a WASM target; they can add custom routes, logic, and data models. Frontend plugins are standard module bundles that add pages, board views, and widgets. The README states that plugins run sandboxed under a capability-based permission model, where a plugin declares exactly which host functions it needs. That is a meaningful design choice: it limits blast radius, but it also means a plugin that needs a capability the host does not expose simply cannot be built without changing the host.

The collaboration loop is named the P-A-C-A cycle: Plan, Act, Check, Adapt. Plan is backlog refinement where product owners, business analysts, and agents write BDD scenarios and SDD designs together. Act is the live sprint where humans and agents pull tasks. Check is QA agents running automated verification with human review. Adapt feeds sprint data into the next cycle. That is a description of intended workflow, not a set of enforced states; the README does not claim the platform blocks a transition that skips a phase.

Installing Paca and driving it from an MCP-connected agent

The README does not print a full server installation walkthrough. It points to a Getting Started anchor, a deploy/ directory at the repository root, and an Artifact Hub badge for a Helm chart under the paca repository, so the intended production path appears to be Kubernetes via Helm. If you are evaluating Paca, read deploy/ and docs/architecture/overview.md before you plan a rollout; the README alone is not enough to stand the service up.

What the README does document in detail is the plugin installation path. Community plugins are installed from inside the UI at Settings, then Plugins, then Marketplace, with an Install button and no command line involved. For local development, the README gives a filesystem install script that takes a plugin directory and an API key:

./scripts/install-local-plugin.sh ./my-plugin --api-key <your-api-key>

Run that from the repository root with your own key substituted. The script is the documented route for iterating on a plugin you are building, as opposed to one you are consuming from the marketplace.

The README also advertises an MCP server so that external agents can connect to Paca, and a set of Paca Skills for Claude Code, Gemini CLI, Cursor, and similar tools. The MCP section is linked from the top navigation but its body is not reproduced in the README excerpt, so treat the exact tool names and transport configuration as something to confirm in the docs directory rather than assume from the heading. The same applies to the browser extension shipped in v0.15.0: the README says it authenticates through your existing Paca session using a same-hostname cookie trick documented in apps/extension/README.md, and that a pre-built zip is attached to each release. That file is the place to look for the actual install steps.

The browser extension and environment previews in v0.15.0

The v0.15.0 release notes describe a browser extension for page annotations. You open a running environment's preview page, comment directly on an element of that page, and turn the comment into a Paca task in one click. The extension reuses your existing Paca session instead of asking for a separate login, which the README attributes to a same-hostname cookie trick documented in apps/extension/README.md.

That detail is worth pausing on. Same-hostname cookie sharing works when the preview environment and the Paca instance are served from the same hostname, which is a deployment constraint rather than a general property. The README does not describe what happens when they are not, and it does not describe a fallback authentication flow. If your preview environments live on separate hostnames from your Paca instance, verify the extension's behavior before you build a review process around it. The release also ships a pre-built zip per release, so installation is a manual browser step, not something the server pushes to you.

Where Paca is the wrong tool

Paca is not a drop-in Jira replacement for a team that wants managed hosting. It is self-hosted by design, and the README's comparison table lists vendor cloud as the thing Paca deliberately avoids. That means you own the database, the upgrades, and the backups. The repository contains a SECURITY.md and a CODE_OF_CONDUCT.md, but the README does not document a rollback procedure, a migration guide between minor versions, or a backup and restore workflow. For a platform that holds your sprint history, that silence is the largest practical risk in adopting it.

The second mismatch is teams with no agents. If your process is human-only, the central feature of Paca is dead weight, and a plain Kanban tool will be simpler. The README's own framing is that Paca gives agents a seat at the table; remove the agents and you are left with a configurable board whose main differentiator no longer applies.

Third, the plugin model cuts both ways. WASM sandboxing with declared capabilities is a sound boundary, but a plugin author who needs a host function Paca does not expose has no path except changing Paca itself. The README does not document a mechanism for requesting or adding new host capabilities. If your customization needs are unusual, budget time to read the plugin documentation before committing.

How Paca differs from Jira and Trello in practice

Jira and Trello are human-first tools with AI features attached. In Jira, an agent typically shows up as an app, a bot account, or an automation rule that reacts to a transition. In Trello, it is a power-up or an external script. In both cases the agent is a visitor to a system designed around human actors, and its work is represented indirectly.

Paca inverts that. An agent is assigned to a sprint and appears on the board as a participant, and the P-A-C-A cycle treats agent output as a normal input to Plan, Check, and Adapt. The difference is not that Paca has AI features and Jira does not; it is where the agent sits in the data model. That matters if you want sprint metrics to include agent throughput, or if you want a product owner to review an agent's BDD scenario in the same interface where the scenario will be executed.

The cost of that inversion is maturity. Jira and Trello have years of migration tooling, permission models, and integrations that Paca's README does not claim. Paca is at v0.15.0, released on 2026-09-08, with a release candidate two days earlier and v0.14.1 on 2026-09-01. The cadence is fast, which is good for features and bad for anyone who needs a frozen API surface. If you need a stable plugin API or a documented upgrade path across minor versions, the README does not provide one.

Licence, maintenance, and what an upgrade actually costs

Paca is licensed under Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the licence and notices intact. It also includes an explicit patent grant. This is a permissive licence with no copyleft obligation on your own code, which matters if you plan to write proprietary plugins or embed Paca in a product. None of this is legal advice; check the LICENSE file and your own counsel for your situation.

The repository is not archived, and the last push was on 2026-09-10, eight days before this writing. Releases are frequent: v0.14.1 on 2026-09-01, v0.15.0-rc.1 on 2026-09-07, and v0.15.0 on 2026-09-08. That pace suggests the project is being worked on continuously, but it also means the surface you integrate against can move between minor versions. The README does not document a deprecation policy, a plugin API versioning scheme, or a migration path between releases.

Upgrade cost, then, is the thing to price before you commit. You will need to track release notes yourself, test plugin compatibility against each new version, and confirm that the WASM host functions your plugins declare still exist. For a small team running one instance, that is a recurring but manageable task. For an organization that needs change control and rollback guarantees, the absence of documented migration and rollback procedures in the README is a gap you would have to fill internally.

Editorial conclusion

Adopt Paca if you run a Scrum team that already uses AI coding or planning agents and you want them tracked as board participants rather than external tools, and if you are comfortable reading a docs/ directory and a deploy/ directory to work out installation. Do not adopt it if you need a hosted service with a support contract, or if your team has no interest in agents on the board and just wants a lighter Trello. Verify first: read deploy/ and docs/architecture/overview.md in the repository to confirm which deployment path (Helm chart, container, or source build) is current for v0.15.0, and check that the plugin marketplace and browser extension match the release you install.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Paca-AI/paca on GitHub
3. Project website
4. README
5. Releases