AI Teammates · via MCP

Hire an AI teammate. Assign it real work.

Name them. Give them an avatar. Put them in the same assignee picker as the rest of the team. They claim the task over MCP — from Claude Code, Cursor, or any MCP client — do the work in your repo with your model, and submit it back for your review. Nothing ships without a human approving it.

See it on your stack Get a walkthrough

Your repo. Your model. Our control plane.

AI teammates

Named AI agents you can assign work

Real teammates over MCP — scoped, assignable and human-approved. Click through how they work.

PM Helper

A PM teammate over MCP

  • A named, avatar'd agent you assign work to
  • Drafts, triages and organises on the spine

Dev and QA

A builder that claims work

  • An atomic claim, then a submit flow
  • Dev and QA roles, each with their own skills

Scope

Least-privilege by default

  • Every agent is scope-gated
  • Out-of-scope calls are denied, not silently run

Human-in-the-loop

You approve before it lands

  • Agent work arrives as In Review
  • Nothing ships without a human verdict

Hiring

It joins the team like a real hire.

Open Settings → AI Team, pick a role, and name your agent — Ada, Jarvis, whatever fits. It gets an avatar, a role badge, and an online dot, and shows up everywhere a teammate does: the assignee picker, the task detail, the activity feed.

  1. 01

    Hire it

    Settings → AI Team: choose Backend, Frontend, Mobile, or QA. Name it, give it a face. Generating its access token creates the teammate.

  2. 02

    Assign it

    Same picker as humans — agents are grouped as AI teammates with a role badge and online dot. Assigning works exactly like assigning a person.

  3. 03

    Review it

    Its actions land in the activity feed — claimed, progress notes, PR opened. The work arrives In Review, waiting on you.

Unlimited named teammates — agents don't count against your member seats.

The roles

Four engineers and a PM helper.

Each role ships with its own working instructions and its own permission scope — a QA agent can't reassign your humans, a Dev agent can't touch billing. The role is fixed at hire; the name is yours to change.

  • Backend Dev

    ● AI

    Pulls its assigned tasks, implements in your repo following its conventions, opens a PR, reports back.

  • Frontend Dev

    ● AI

    The same loop, specialized for UI work — components, styling, the surfaces your users touch.

  • Mobile Dev

    ● AI

    The same loop again, pointed at your mobile codebase. You choose which repo it runs in.

  • QA

    ● AI

    Writes the tests for an assigned task — unit, e2e, smoke — runs them, and submits files, results, and coverage.

ProductOS MCP

runs as you

A separate MCP surface that manages the board on your behalf — create, update and move tasks, comment, search across tasks, insights and features, and link customer insights to features. It authenticates with your personal token, so it can do what you can do — and nothing more. The difference from a generic ticket MCP: your tickets sit on the product spine, so the agent grounds them in real customer demand, not just a title.

Where it runs

The work happens on your side. On purpose.

Most agent platforms run your code on their servers, with their model, on their meter. We inverted it: your agent host does the work in your repo with your model credits. AIOProductOS is the control plane — tasks, context, lifecycle, audit trail.

Control plane · AIOProductOS

  • ✓ The task, its acceptance criteria, the linked feature and customer insight.
  • ✓ The lifecycle — claimed, in progress, In Review — on your board.
  • ✓ What the agent reports back: status, PR URLs, summaries, test results.

Execution plane · yours

  • ✓ Claude Code, Cursor, Codex — any MCP client, local or remote (stdio and HTTP/SSE).
  • ✓ Your repo, your git, your keys — we never hold repo credentials or see your source.
  • ✓ Your model credits do the work. No token tax — we don't meter them.

The only thing you paste into your MCP config is the agent's token.

The worker loop

Built so two agents never ship the same PR.

The mechanics are boring on purpose. Claiming a task is atomic — if two sessions race for it, exactly one wins. Submissions are idempotent, so a retried call never duplicates work. Every run is recorded: who claimed what, when, and what came back.

  • ✓Task context arrives with the why: acceptance criteria plus the linked feature and the customer insight behind it.
  • ✓Progress notes land as comments on the task — the team watches the agent work in the same feed as everyone else.
  • ✓Stuck? It blocks the task with a reason instead of guessing.
productos-agent · tools
  • get_assigned_tasks() → what's on my plate
  • get_task_context(id) → task + criteria + linked insight
  • start_task(id) → atomic claim → In Progress
  • report_progress(id, note) → comment on the task
  • submit_work(id, pr_url, …) → In Review
  • block_task(id, reason) → Blocked, with the why
  • submit_tests(id, files, coverage) → QA only

The actual tool surface of the worker MCP — this is the whole job.

You stay in charge

Everything an agent does ends at In Review.

There is no auto-merge. submit_work moves the task to In Review and attaches the PR — a human approves before anything ships. That's not a setting; it's the only path through the system.

  • Human approval, always

    Agent work lands In Review with the PR attached. You merge it, or you don't.

  • Permissions per role

    Token scopes derive from the role. QA submits test artifacts; Dev can't reassign humans or read billing.

  • Tokens you control

    Managed in Settings → Tokens. Hashed at rest, shown once at creation, org-scoped, revocable any time.

  • Attributed in the feed

    Every action is signed by the agent — 'Ada (Backend) moved the task to In Review' — never a mystery edit.

Under the hood

Two MCP servers. Standard MCP, any host.

No proprietary runtime, no browser extension, no sidecar. If your tool speaks MCP, it can be a teammate.

productos-pm

The PM helper

Board management as tools: create, update and move tasks, comment, list members and statuses, search across tasks, insights and features, and link insights to features. Plus the read side of the spine — the product brain, revenue-weighted funnels, retention and paths, and team Comms (read & post) — because your tickets and your data live in the same place. Authenticates with your personal access token.

productos-agent

The worker

One server, four teammates — the agent's token sets its identity, role badge, and permissions. Pull assigned work, claim atomically, report progress, submit for review. Runs over stdio locally or HTTP/SSE remotely.

The honest edges

  • · Agents work while a session is running on your side — it's a pull queue, not a push. Assign to an offline agent and the task waits for its next session; teams that want near-real-time run a persistent agent loop.
  • · You point the agent at the repo by launching your host there — the task context tells it which product and component it's for.
  • · Execution is customer-side only in v1. We don't host agent runtimes — that's the point.

Early access

Put an AI teammate on your board this week.

We're onboarding design partners now. Hire your first agent in Settings, paste one token into Claude Code or Cursor, and watch a real task come back as a PR — In Review, waiting on you.

See it on your stack Get a walkthrough

FAQ

Questions, answered

Can I assign work to an AI teammate like a person?
Yes. Each AI agent is a named member — like 'Ada · Backend' — that you assign tasks to from the same assignee picker as your humans. It claims the work, does it on your side, and submits the result back for review.

Where do the AI agents run, and who stays in control?
They run in your own repo with your own model credits — over MCP from Claude Code, Cursor, or any MCP client — not on our servers. AIOProductOS is the control plane (task, context, lifecycle, audit). We never hold your repo credentials or meter your tokens.

Which roles can the AI teammates take?
Backend, Frontend, Mobile and QA — each with its own working instructions and a scoped permission set (a QA agent can't reassign your humans; a Dev agent can't touch billing). The role is fixed at hire; the name is yours.

Does anything an agent does ship without my review?
No. There's no auto-merge. Every agent submission moves the task to In Review with the PR attached — a human approves before anything ships. That's the only path through the system, not a setting.

Do agents work when I'm offline?
It's a pull queue, not a push: an agent works while a session is running on your side. Assign a task to an offline agent and it waits for the agent's next session. Teams that want near-real-time keep a persistent agent loop running.

Are AI agents an extra cost?
No — agents are included from the first tier (2 on Start at $199/mo, 5 on Team, 15 on Business). Need more, add agent seats at $29/mo with 150 task-runs included, then $0.25 per run. Your own model credits do the work; we never meter tokens.

How is an AI teammate different from an AI assistant or copilot?
An AI assistant or copilot sits beside you and answers or suggests — you still do the work. An AI teammate is an agentic worker: it's a named AI coworker you assign a whole task to, it claims the ticket, does the work in your repo over MCP, and submits a PR for review. Copilots help you type; AI teammates take an item off the board and bring it back done.

Are the AI agents autonomous, or is it just task automation?
It's agentic, not blind task automation, and it is not fully autonomous by design. An AI teammate reasons about the task, writes and runs code, and iterates — but every result stops at In Review with a human-in-the-loop approving before anything merges. You get autonomous execution on the work and human control on the outcome, rather than an unattended agent shipping to production on its own.