Paca is a free, open-source, self-hosted, AI-native project management platform in which human Scrum teams and AI agents work as equal teammates on the same board, the same sprints, and the same goals.

What it is

Paca is an Apache-2.0 licensed, self-hosted project management platform written in Go and distributed from paca-ai.org, listed in the registry under Business Software / Project & Work Management. Its defining idea is that AI agents belong inside the Scrum process rather than beside it: agents are assigned to sprints, appear on the Scrumban board next to human teammates, pull tasks from the backlog, update work status in real time, and contribute to BDD specifications written as Gherkin scenarios and to System Design Documents. The project frames this as collaboration rather than automation, and grounds it in the Cynefin and Stacey frameworks, on the argument that complex domains need teams instead of pipelines. Sprints and agents run through the P-A-C-A cycle — Plan, Act, Check, Adapt — which loops sprint data back into the next planning round.

The concrete problem it solves is the gap between where AI assistance lives and where the work lives. In Jira, Trello, ClickUp, and Monday, AI arrives as chatbot add-ons and peripheral automation, and the collaboration model remains human-only by default. Paca replaces that arrangement with a single board and a single data model that both humans and agents read and write. It also replaces the vendor-cloud deployment model: the platform is self-hosted, so sprint data, specifications, and design documents stay on the operator's own infrastructure, and process customisation is not gated behind an enterprise tier.

Key capabilities

• AI agents participate as first-class teammates: assigned to sprints, present on the Scrumban board, picking up backlog tasks and updating status in real time.
• BDD support where agents help Product Owners and BAs write Gherkin scenarios, alongside contributions to System Design Documents.
• The P-A-C-A cycle (Plan → Act → Check → Adapt) with a feedback loop from sprint data into the next planning cycle.
• Configuration-driven behaviour: workflows, statuses, field definitions, board layouts, sprint rules, and agent behaviour are set in project-level configuration files without writing code.
• A plugin system with backend plugins compiled to WebAssembly (Go, Rust, AssemblyScript, or any WASM target) under plugins/backend/, and frontend module bundles under plugins/frontend/.
• Sandboxed plugins using a capability-based permission model, where each plugin declares exactly which host functions it needs.
• A Plugin Marketplace reachable in the UI at Settings → Plugins → Marketplace, plus local installation through ./scripts/install-local-plugin.sh ./my-plugin --api-key.

Who uses it and how

• Scrum and Scrumban teams that want agents joining sprint planning and holding board tasks, rather than generating output in isolation.
• Organisations required to keep project data on their own infrastructure, since every deployment is self-hosted.
• Teams whose process does not fit default tooling and who would otherwise need enterprise-tier customisation, which Paca handles through configuration and plugins.
• Teams working in complex problem domains, following the Cynefin and Stacey framing that Paca explicitly adopts.
• Teams building agent workflows around the MCP server and Paca Skills documented in the project's navigation.

Getting started

The README points to a dedicated Getting Started section and describes a self-hosted deployment. Plugins can be installed inside the running UI from Settings → Plugins → Marketplace, or from the filesystem with ./scripts/install-local-plugin.sh ./my-plugin --api-key.

How it compares

Jira, Trello, ClickUp, and Monday are closed or proprietary products delivered from vendor cloud, priced at roughly $8–$20+ per seat per month, with AI arriving as chatbot add-ons and customisation locked behind enterprise tiers. Paca is Apache-2.0, self-hosted, and free forever, so data ownership sits with the operator and the workflow, data model, and UI are open to extension through configuration and plugins. The trade is operational: the vendor products include hosting and support that a Paca operator supplies.

When to use it — and when not to

A self-hoster must run the platform and its components directly; the README excerpt does not name a database, storage layer, SMTP dependency, Docker image, or compose file, so deployment prerequisites must be read from the full documentation before committing. Teams that want a vendor-managed SaaS contract with support and billing, or that depend on deeply embedded existing Jira workflows, should not pick it. The project is also modest in scale — 1829 stars, 154 forks, and 8 open issues — with no release history given in the facts, so adopters should expect to follow the repository rather than wait for a packaged version.

plugins/
├── backend/        # WASM modules — add custom routes, logic, data models
└── frontend/       # UI modules — add custom pages, board views, widgets

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

Plan  →  Act  →  Check  →  Adapt
  ↑                             |
  └─────────────────────────────┘