The Apache 2.0, self hosted alternative to Jira and Trello puts AI agents on the same Scrum board as humans, sharing two week work cycles, a common backlog, and jointly authored test specifications.
The project management software market has spent the last three years answering a single question: where does the AI assistant sit? Most incumbents, including Jira, Trello, Asana, and ClickUp, have answered "on the side," as a chat panel that summarizes tickets, drafts a standup note, or fills in a field. A small open-source project called Paca is betting on a different answer: the agent belongs on the same board as the human, assigned to the same sprint, working from the same backlog.
Paca is an Apache 2.0-licensed, self-hosted project management platform that, in its own framing, treats artificial agents as full members of a Scrum team rather than as a chatbot add-on. The project's GitHub repository describes a workflow in which agents pick up backlog items, co-author behavior-driven development (BDD) specifications in the Gherkin format (a plain-English syntax for writing test cases such as "Given a user is logged in, When they click checkout, Then they see a confirmation"), and join the same sprint planning meetings that humans do. The project is small by most measures: 313 stars, 6 forks, and 823 commits as a public point-in-time snapshot, with no published customer base or revenue figures. The interesting question is not whether Paca will displace Jira. It is whether the data model behind the bet is honest enough to make "Scrum teammate" mean something different from "chatbot with a Scrum vocabulary."
That bet is encoded in a four-phase Plan, Act, Check, Adapt loop that the README explicitly maps to both the Scrum cycle and the scientific method. In a typical workflow, a human product owner creates an epic, an agent helps break the epic into stories, a second agent estimates and prioritizes them, a human reviews the plan, and a third agent executes the work. Each phase is supposed to leave evidence in the same data store: the board, the sprint, the backlog, the BDD spec, the System Design Document, that humans and other agents can audit later. Whether the codebase delivers that level of discipline is a question the maintainers themselves are still working through. The project ships with documented opt-outs (--scale ai-agent=0 for fully human teams, --scale postgres=0 for embedded deployments) that signal which parts of the bet are load-bearing and which are optional.
The technical surface is unusually broad for an early-stage project. According to the README, the web client is built on React with TanStack Start and shadcn/ui, with a Go and Gin REST API, a Node.js and Socket.IO realtime layer, and a Python and FastAPI agent service that wraps the OpenHands SDK. Plugins run inside a WebAssembly sandbox with a capability-based permission model, meaning each plugin must explicitly request the system calls it needs rather than inheriting ambient access. The project also publishes a Model Context Protocol (MCP) server on npm as @paca-ai/paca-mcp, plus a set of Claude Code slash commands (single-line instructions typed into Anthropic's Claude Code terminal tool to trigger a specific behavior) including /paca, /paca-epic, /paca-clarify, /paca-breakdown, /paca-sprint, /paca-estimate, /paca-prioritize, /paca-do, /paca-test, /paca-doc, and /paca-setup.
The framing is unusually explicit. The README invokes the Cynefin framework and the Stacey diagram, two well-known complexity-theory models used to sort problems by how predictable their cause-and-effect is, to argue that software work in complex domains requires a team (human plus AI) rather than a pipeline. "Paca" itself is a pun on the Japanese word "baka" (ばか), meaning "silly" or "foolish." The project frames itself as a deliberately contrarian free-and-open-source challenge to PM vendors with multi-billion-dollar market capitalizations. That positioning is project self-description, useful as a quote rather than as a fact about the broader PM industry's reception of the bet.
What the project does not yet claim, and what a reader should not infer, is that putting an agent on the same Scrum board makes it a teammate in any deeper sense. The board is a UI surface. Whether the agent's role, prompt, accountability, and review trail are first-class fields in the data model, or whether they live in a sidecar that the rest of the system does not enforce, is a question that requires reading the source, not the README. Paca's own contributors signal where the bet is unproven: the AI agent service is one of several services in the Docker Compose stack, and the WebAssembly plugin sandbox is described as a security boundary rather than as a proven isolation guarantee.
The watch items for the next year are specific. Will the MCP server and the Claude Code slash commands attract third-party plugin authors, or will the plugin model remain an empty stage? Will the BDD-co-authoring workflow show up in a published test suite, or only in the README? And will a real team, not a maintainer, document what it looks like when an agent's pull request fails code review? Paca is, at root, a hypothesis: that an AI agent with a sprint assignment, a BDD spec to defend, and a shared backlog is a meaningfully different object from an AI agent with a chat window. The codebase is the place to look for evidence of which side of that line it actually lands on.