The sprint board looks normal until the new assignee appears.
Two backend tickets sit in the next sprint. A designer has a review task. The ops lead is tracking a migration checklist. Then someone drags a story into a lane reserved for an AI agent.
The ticket says what tickets usually say: "Refactor invoice export. Add tests. Update docs."
For a human teammate, that might be enough. They know which repo they can touch, when to ask before changing an API, who owns the rollback, and what kind of evidence counts as done.
An agent does not carry that context unless the team writes it down.
Once agents share the same board as humans, the ticket stops being only a task description. It becomes a control surface.
Paca is a signal, not the whole story
Paca is an open-source, self-hosted project management board built around the idea that humans and AI agents can collaborate inside the same Scrum system.
Its README describes agents that can be assigned to sprints, appear on a Scrumban board, pick up tasks, update status, collaborate on BDD specs, contribute to System Design Documents, and adapt alongside human teammates. Recent release notes in the repo mention in-app AI chat that can create or update epics, stories, tasks, and documentation, plus activity diffs and revert for field changes.
The project also shows the kind of architecture teams are starting to expect around agent work: an MCP server, editor skills, OpenHands-powered agents in isolated sandbox containers, WASM plugins with declared permissions, and self-hosting for teams that want control over their own data and workflow.
The interesting part is not whether Paca replaces Jira, Linear, Trello, GitHub Issues, or a spreadsheet. Most teams will keep whatever board they already use.
The signal is simpler: the work board is becoming the place where agent collaboration gets assigned, constrained, reviewed, and remembered.
The Hacker News discussion around "Paca - Lightweight Jira alternative for human-AI collaboration" made that tension visible. One commenter liked the idea of project-level chat but said they would "hesitate to put it on an in-flight project." Another described a current setup built from git worktrees, one branch per PR, multiple agents running separately, and a lot of manual instruction.
Then a commenter asked the question every operator should ask before agents get a real lane on the board: "When an agent and a human disagree on priority, who wins... is there an override, a queue or some kind of arbitration?"
That question belongs on the ticket.
A normal ticket is under-specified for agent work
Most project tickets are written for people who already understand the team's boundaries.
A human engineer reads "update the sync job" and knows not to rotate production credentials without approval. A project manager reads "clean up stale records" and knows which customer table is off limits. A support lead reads "draft customer reply" and knows legal needs to review anything involving refunds or security claims.
An agent may infer some of that from context. That is not the same as permission.
The failure mode is not only bad code. It is silent overreach.
An agent might touch adjacent files because they look related. It might update a field that triggers a customer-facing workflow. It might summarize a sensitive document into a ticket comment. It might accept a test result as proof even though the team needed a screenshot, a diff, a log, or a human approval.
Human tickets usually answer one question: what needs to be done?
Agent-ready tickets need to answer a longer set:
- What may the agent access?
- What may it change?
- What evidence must it attach?
- Where does the human gate sit?
- What happens if a human and agent disagree?
- Who owns rollback?
- What receipt proves the work happened inside the agreed boundary?
Without that contract, the board gives the agent a task but not a safe operating envelope.
The agent-work contract
An agent-work contract is a small block of structured instructions attached to any ticket an AI agent can pick up.
It does not need a new platform. It can live in Jira, Linear, GitHub Issues, Trello, Notion, Paca, or a spreadsheet. The format matters less than the habit.
A compact version looks like this:
Agent-work contract
Agent role:
- What the agent is allowed to do on this ticket.
Allowed tools and data:
- Repos, docs, systems, files, queues, datasets, or APIs the agent may use.
- Explicit exclusions.
Change boundary:
- Files, records, environments, customers, or workflows the agent may change.
- Actions that require human approval before execution.
Acceptance evidence:
- Required proof: tests, screenshots, logs, diffs, links, metrics, review notes, or before/after examples.
Human gate:
- Who reviews the work.
- What the agent must stop and ask before doing.
Conflict rule:
- What happens if the agent finds a contradiction, stale requirement, failing test, or disagreement with a human instruction.
Rollback owner:
- Person responsible for reverting or disabling the change.
- Rollback path or runbook link.
Receipt requirement:
- Where the agent records what it did, what it touched, what it skipped, and what remains uncertain.
A weak ticket says:
Fix failed account export job.
An agent-ready ticket says:
Fix failed account export job.
Agent role:
- Diagnose the failing export job and propose a minimal code change.
Allowed tools and data:
- Read access: export service repo, staging logs, existing runbook.
- No production database access.
- Do not inspect customer file contents.
Change boundary:
- May edit export service code and tests.
- Do not change job schedule, retention rules, billing fields, or customer notification templates.
- Ask before changing any shared schema.
Acceptance evidence:
- Attach failing log excerpt with sensitive values removed.
- Attach test command and result.
- Link diff.
- Explain why the fix is limited to the export failure.
Human gate:
- Engineering lead reviews before merge.
- Ops lead approves if job schedule or retry behavior changes.
Conflict rule:
- If logs and ticket acceptance criteria disagree, stop and ask in the ticket.
- If the fix requires production data inspection, stop and request human handling.
Rollback owner:
- Ops lead owns rollback.
- Rollback path: revert PR and rerun previous export job version.
Receipt requirement:
- Add a ticket comment listing files changed, tests run, assumptions made, and unresolved risks.
That extra block looks bureaucratic until the first agent makes a plausible change in the wrong place.
Then it looks cheap.
What to add before agents pick up tickets
The contract should focus on operational control, not model prompting.
A ticket does not need to explain how an LLM works. It needs to define the work boundary clearly enough that a reviewer can tell whether the agent stayed inside it.
Start with access. If the agent can read a repo, say which repo. If it can use logs, say which environment. If customer data is out of bounds, say so in the ticket rather than assuming the agent will infer it from policy.
For teams experimenting with MCP servers, sandboxed agents, plugin permissions, or self-hosted boards like Paca, this is where the board and the execution environment meet. The board describes the permission. The runtime enforces as much of it as possible.
Next, define the evidence. A human teammate can walk over and say, "I checked staging and it works." An agent needs to leave something behind.
That evidence might be a test run, a diff, a replay link, a screenshot, a sanitized log excerpt, a before/after record count, or a short explanation of why it did not touch a tempting adjacent area.
The evidence should match the risk. A copy edit does not need the same proof as a migration script. A production automation change needs more than "tests passed."
Then define the human gate. Not every ticket needs approval at the same place. Some tickets can be agent-drafted and human-reviewed. Some can be agent-tested but human-merged. Some can be agent-proposed but not executed. Some should never be assigned to an agent at all.
"Ask if unsure" is too soft. "Stop before changing billing logic" is better. "Security lead must approve any new data retention behavior" is better still.
Finally, define conflict and rollback. Agents will find contradictions: the ticket says one thing, the README says another, a failing test suggests the acceptance criteria are stale, or a human leaves a comment that conflicts with the original scope.
The ticket should say what happens next. Stop and ask. Escalate to a named person. Open a follow-up issue. Mark the ticket blocked. Do not let the agent invent arbitration rules while work is already in motion.
Where this fits with the rest of the control stack
The agent-work contract is not a replacement for good workflow design. It is the piece that connects the board to the rest of the system.
A session manifest tells the next actor what context the agent used, what decisions it made, and what state it left behind. The ticket contract can require that manifest when the work spans more than one session or agent.
A run map or replay pattern, like the one in our review of Apache Burr's agent state machine approach, helps teams reconstruct how an agent moved through a process. The ticket contract can specify when replay evidence is required.
Receipts make completed work auditable. Approval queues make human gates explicit. Workflow controls define which actions can run without review and which cannot.
Together, these patterns turn agent work from "the bot did something" into a sequence a human can inspect.
That matters because most small teams will not start with a dedicated AI project board. They will start by inviting agents into the systems they already use: a GitHub issue, a Linear ticket, a Jira story, a Trello card, or a row in a spreadsheet.
The contract is portable because the risk is portable.
Start with one workflow
The safest way to adopt agent work is not to agent-enable the whole backlog.
Pick one workflow where the risk is real but bounded: a staging-only bug fix, a documentation update tied to a source file, a test-generation task, or a support-draft workflow that requires human approval before anything reaches a customer.
Write the agent-work contract for the first ticket before expanding autonomy.
If the contract feels hard to write, that is useful information. It means the workflow boundaries are still implicit. Humans may be carrying them in habit, memory, or Slack threads.
Agents need those boundaries in the work artifact.
Paca is worth watching because it treats the project board as a shared space for humans and agents rather than a passive list of tasks. The operator lesson travels further than the tool: when an agent joins the board, the ticket has to describe the work and the rules of engagement.
If you want to test this in one real workflow, BaristaLabs can help map the ticket contract, approval gate, rollback path, and receipt pattern before you widen agent access. Start with a single agent-ready ticket, then build from evidence instead of optimism.
AI Pilot Readiness Checklist
Turn the idea into a pilot you can defend.
AI agent articles are easy to bookmark and hard to operationalize. Use the readiness questions as a shared way to decide whether a workflow is specific enough, safe enough, and measurable enough to pilot. If they surface a strong candidate, BaristaLabs can review it with you and help shape a first version that fits your systems, approval process, and risk tolerance.
Please do not submit PHI, customer records, credentials, or confidential workflow exports.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.