It exposes an MCP server. An agent connects with a scoped, revocable token and can: claim_job, report_progress, attach_evidence, request_human_decision, resolve_decision. Every call writes to the same job timeline humans see, tagged human vs agent, so there's one audit trail of who (or what) did what. When an agent hits something irreversible it opens a request_human_decision — surfaces as an "Agent · pending" chip on the card; a human resolves it once and the agent continues.
The rest is a normal kanban: enforced stage order (transitions are logged, no jumping columns), per-stage SLAs that flag at-risk/overdue, and an optional QR per card that opens a login-free public status page.
Stack: Next.js 16, Postgres (Neon) + Prisma, NextAuth, Stripe, Vercel. The MCP server is a thin layer over the same REST API the web app uses.
A few design calls I'd love HN's brutally honest take on:
Agent as a service principal — each token is flagged human or agent (isAgent), sharing the same permission scopes. Is a distinct principal type the right call, or should it just be scopes?
request_human_decision as a first-class board object — it's a real row with options + status, not a comment mention. Over-engineered vs just letting the agent leave a note and poll?
Append-only timeline, 280 chars/event — keeps cards scannable but forces agents to be terse. Good constraint or annoying in practice?
Free plan is 10 active jobs, no card. Honest about the gaps: MCP server is read+write but not streaming yet, no native mobile app, public REST docs are thin beyond the MCP surface.
qodflow.com — happy to get into the tradeoffs.