Copilot

What it does

You give it a requirement — text, a file, a URL, audio, or an image — and it runs a multi-role agent workflow (architect, draft, judge, security, QA, vision) to turn that requirement into one or more OpenProject work packages: epics, features, tasks and bugs, each with an estimate, a priority, a suggested role (backend/frontend/QA/devops), and — where useful — a test stub (Playwright or Cypress).

Threaded conversations — each requirement lives in a thread; the agent can ask for clarification before drafting.
A project knowledge base — indexed content (with embeddings) the agent retrieves against, so drafts stay consistent with how your project is actually built, and near-duplicate tickets are flagged before they’re created.
Human review before publish — drafts sit in a workbench; nothing reaches OpenProject until someone approves it.
Lifecycle sync back from OpenProject — a webhook keeps each published ticket’s status (created / in progress / closed / rejected) in sync with what actually happens in OpenProject.
Usage and budget limits — token usage is tracked per company per month, with a hard monthly limit and per-role generation timeouts, so a runaway thread can’t burn an unbounded LLM bill.

Admin

Copilot in the staff admin: a chat-style canvas for the requirement thread, a ticket generator/workbench, a threads queue, a project knowledge table, a usage dashboard, an impact dashboard (tickets pushed, acceptance rate, cycle time), and settings (OpenProject connection, default project, LLM routing per agent role). See the Copilot admin guide for a walkthrough of each screen.

Configuration

Copilot needs an OpenProject base URL and API key, a default project and work-package type, and (optionally) a trigger configuration that lets an intake project auto-decompose into a destination project. Credentials are stored encrypted, like every other provider credential.

API

/api/v1/copilot/, plus a WebSocket channel for live generation progress.