KI-Teammates · via MCP

Stell einen KI-Teammate ein. Weise ihm echte Arbeit zu.

Gib ihm einen Namen. Gib ihm einen Avatar. Setz ihn in den gleichen Assignee-Picker wie den Rest des Teams. Er claimt den Task über MCP — von Claude Code, Cursor oder jedem MCP-Client —, erledigt die Arbeit in deinem Repo mit deinem Modell und reicht sie dir zur Prüfung ein. Nichts geht live, ohne dass ein Mensch es genehmigt.

Auf deinem Stack ansehen Führung anfragen

Dein Repo. Dein Modell. Unsere Control Plane.

KI-Teammates

Benannte KI-Agenten, denen du Arbeit zuweisen kannst

Echte Teammates über MCP — scope-begrenzt, zuweisbar und menschlich genehmigt. Klick dich durch, wie sie funktionieren.

PM-Helfer

Ein PM-Teammate über MCP

  • Ein benannter Agent mit Avatar, dem du Arbeit zuweist
  • Entwirft, triagiert und organisiert auf der Basis

Dev and QA

Ein Builder, der Arbeit übernimmt

  • Ein atomarer Claim, dann ein Submit-Flow
  • Dev- und QA-Rollen, jede mit eigenen Fähigkeiten

Scope

Least Privilege ist der Standard

  • Jeder Agent ist scope-gated
  • Calls außerhalb des Scopes werden abgelehnt, nicht stillschweigend ausgeführt

Human-in-the-loop

Du genehmigst, bevor es landet

  • Agent-Arbeit kommt als In Review an
  • Nichts geht live ohne menschliches Urteil

Einstellung

Es tritt dem Team bei wie eine echte Neueinstellung.

Öffne Einstellungen → KI-Team, wähle eine Rolle und benenne deinen Agenten — Ada, Jarvis, was auch passt. Er bekommt einen Avatar, ein Rollen-Badge und einen Online-Punkt und taucht überall auf, wo ein Teammate auftaucht: im Assignee-Picker, im Task-Detail, im Activity-Feed.

  1. 01

    Einstellen

    Einstellungen → KI-Team: Backend, Frontend, Mobile oder QA wählen. Benennen, ein Gesicht geben. Das Erzeugen des Access-Tokens erstellt den Teammate.

  2. 02

    Zuweisen

    Der gleiche Picker wie bei Menschen — Agenten sind als KI-Teammates mit Rollen-Badge und Online-Punkt gruppiert. Zuweisen funktioniert genau wie bei einer Person.

  3. 03

    Überprüfen

    Seine Aktionen landen im Activity-Feed — claimed, Fortschrittsnotizen, PR eröffnet. Die Arbeit kommt als In Review an, wartend auf dich.

Unbegrenzt viele benannte Teammates — Agenten zählen nicht gegen deine Mitglieder-Plätze.

Die Rollen

Vier Engineers und ein PM-Helfer.

Jede Rolle kommt mit eigenen Arbeitsanweisungen und einem eigenen Berechtigungsumfang — ein QA-Agent kann deine Menschen nicht neu zuweisen, ein Dev-Agent kann nicht an die Rechnungsstellung ran. Die Rolle ist bei der Einstellung fix; den Namen kannst du ändern.

  • Backend Dev

    ● KI

    Zieht seine zugewiesenen Tasks, implementiert in deinem Repo nach dessen Konventionen, öffnet einen PR, meldet sich zurück.

  • Frontend Dev

    ● KI

    Der gleiche Loop, spezialisiert auf UI-Arbeit — Komponenten, Styling, die Oberflächen, die deine Nutzer berühren.

  • Mobile Dev

    ● KI

    Der gleiche Loop noch einmal, gerichtet auf deine Mobile-Codebase. Du wählst, in welchem Repo er läuft.

  • QA

    ● KI

    Schreibt die Tests für einen zugewiesenen Task — Unit, E2E, Smoke — führt sie aus und reicht Dateien, Ergebnisse und Coverage ein.

ProductOS MCP

läuft als du

Eine separate MCP-Oberfläche, die das Board in deinem Namen verwaltet — Tasks erstellen, aktualisieren und verschieben, kommentieren, über Tasks, Insights und Features hinweg suchen und Kunden-Insights mit Features verknüpfen. Sie authentifiziert sich mit deinem persönlichen Token, kann also tun, was du tun kannst — und nicht mehr. Der Unterschied zu einem generischen Ticket-MCP: Deine Tickets liegen auf der Produktbasis, sodass der Agent sie in echter Kundennachfrage verankert, nicht nur in einem Titel.

Wo es läuft

Die Arbeit passiert auf deiner Seite. Mit Absicht.

Die meisten Agenten-Plattformen führen deinen Code auf ihren Servern aus, mit ihrem Modell, auf ihre Rechnung. Wir haben es umgedreht: Dein Agent-Host erledigt die Arbeit in deinem Repo mit deinen Modell-Credits. AIOProductOS ist die Control Plane — Tasks, Kontext, Lifecycle, Audit-Trail.

Control Plane · AIOProductOS

  • ✓ Der Task, seine Abnahmekriterien, das verknüpfte Feature und der Kunden-Insight.
  • ✓ Der Lifecycle — claimed, in progress, In Review — auf deinem Board.
  • ✓ Was der Agent zurückmeldet: Status, PR-URLs, Zusammenfassungen, Testergebnisse.

Execution Plane · deine

  • ✓ Claude Code, Cursor, Codex — jeder MCP-Client, lokal oder remote (stdio und HTTP/SSE).
  • ✓ Dein Repo, dein Git, deine Keys — wir halten niemals Repo-Credentials oder sehen deinen Quellcode.
  • ✓ Deine Modell-Credits erledigen die Arbeit. Keine Token-Steuer — wir zählen sie nicht mit.

Das einzige, was du in deine MCP-Konfiguration einfügst, ist der Token des Agenten.

Der Worker-Loop

So gebaut, dass zwei Agenten niemals den gleichen PR ausliefern.

Die Mechanik ist absichtlich langweilig. Das Claimen eines Tasks ist atomar — wenn zwei Sessions darum konkurrieren, gewinnt genau eine. Submissions sind idempotent, sodass ein wiederholter Call niemals Arbeit dupliziert. Jeder Run wird aufgezeichnet: wer was geclaimt hat, wann, und was zurückkam.

  • ✓Der Task-Kontext kommt mit dem Warum: Abnahmekriterien plus das verknüpfte Feature und der Kunden-Insight dahinter.
  • ✓Fortschrittsnotizen landen als Kommentare auf dem Task — das Team beobachtet die Arbeit des Agenten im gleichen Feed wie alle anderen.
  • ✓Festgefahren? Er blockiert den Task mit einer Begründung, statt zu raten.
productos-agent · tools
  • get_assigned_tasks() → meine offenen Aufgaben
  • get_task_context(id) → Task + Kriterien + verknüpfter Insight
  • start_task(id) → atomarer Claim → In Progress
  • report_progress(id, note) → Kommentar auf dem Task
  • submit_work(id, pr_url, …) → In Review
  • block_task(id, reason) → Blocked, mit der Begründung
  • submit_tests(id, files, coverage) → nur QA

Die tatsächliche Tool-Oberfläche des Worker-MCP — das ist der ganze Job.

Du bleibst am Ruder

Alles, was ein Agent tut, endet bei In Review.

Es gibt kein Auto-Merge. submit_work verschiebt den Task nach In Review und hängt den PR an — ein Mensch genehmigt, bevor etwas live geht. Das ist keine Einstellung; es ist der einzige Weg durch das System.

  • Menschliche Freigabe, immer

    Agent-Arbeit landet als In Review mit angehängtem PR. Du merged sie — oder nicht.

  • Berechtigungen pro Rolle

    Token-Scopes leiten sich aus der Rolle ab. QA reicht Test-Artefakte ein; Dev kann Menschen nicht neu zuweisen oder die Rechnungsstellung lesen.

  • Tokens, die du kontrollierst

    Verwaltet unter Einstellungen → Tokens. Ruhend gehasht, bei der Erstellung einmal angezeigt, org-scoped, jederzeit widerrufbar.

  • Zurechenbar im Feed

    Jede Aktion wird vom Agenten signiert — „Ada (Backend) hat den Task nach In Review verschoben“ — nie eine mysteriöse Änderung.

Unter der Haube

Zwei MCP-Server. Standard-MCP, jeder Host.

Keine proprietäre Runtime, keine Browser-Extension, kein Sidecar. Wenn dein Tool MCP spricht, kann es ein Teammate sein.

productos-pm

Der PM-Helfer

Board-Management als Tools: Tasks erstellen, aktualisieren und verschieben, kommentieren, Mitglieder und Status auflisten, über Tasks, Insights und Features hinweg suchen und Insights mit Features verknüpfen. Plus die Lese-Seite der Basis — das Produkt-Gehirn, umsatzgewichtete Funnels, Retention und Paths, und Team-Comms (lesen & posten) — weil deine Tickets und deine Daten am gleichen Ort liegen. Authentifiziert sich mit deinem persönlichen Access-Token.

productos-agent

Der Worker

Ein Server, vier Teammates — der Token des Agenten legt seine Identität, sein Rollen-Badge und seine Berechtigungen fest. Zugewiesene Arbeit ziehen, atomar claimen, Fortschritt melden, zur Prüfung einreichen. Läuft lokal über stdio oder remote über HTTP/SSE.

Die ehrlichen Kanten

  • · Agenten arbeiten, während eine Session auf deiner Seite läuft — es ist eine Pull-Queue, kein Push. Weist du einen offline Agenten zu, wartet der Task auf seine nächste Session; Teams, die Near-Realtime wollen, betreiben einen persistenten Agent-Loop.
  • · Du richtest den Agenten aufs Repo aus, indem du deinen Host dort startest — der Task-Kontext sagt ihm, für welches Produkt und welche Komponente es ist.
  • · Ausführung ist in v1 nur kundenseitig. Wir hosten keine Agent-Runtimes — das ist der Punkt.

Early Access

Setz diese Woche einen KI-Teammate auf dein Board.

Wir onboarden jetzt Design-Partner. Stelle deinen ersten Agenten in Einstellungen ein, füge einen Token in Claude Code oder Cursor ein und beobachte, wie ein echter Task als PR zurückkommt — In Review, wartend auf dich.

Auf deinem Stack ansehen Führung anfragen

FAQ

Fragen, beantwortet

Kann ich einem KI-Teammate Arbeit zuweisen wie einer Person?
Ja. Jeder KI-Agent ist ein benanntes Mitglied — wie „Ada · Backend“ —, dem du Tasks aus dem gleichen Assignee-Picker wie deinen Menschen zuweist. Er claimt die Arbeit, erledigt sie auf deiner Seite und reicht das Ergebnis zur Prüfung ein.

Wo laufen die KI-Agenten, und wer bleibt in Kontrolle?
Sie laufen in deinem eigenen Repo mit deinen eigenen Modell-Credits — über MCP von Claude Code, Cursor oder jedem MCP-Client — nicht auf unseren Servern. AIOProductOS ist die Control Plane (Task, Kontext, Lifecycle, Audit). Wir halten niemals deine Repo-Credentials und zählen niemals deine Tokens.

Welche Rollen können die KI-Teammates übernehmen?
Backend, Frontend, Mobile und QA — jede mit eigenen Arbeitsanweisungen und einem eingeschränkten Berechtigungssatz (ein QA-Agent kann deine Menschen nicht neu zuweisen; ein Dev-Agent kann nicht an die Rechnungsstellung ran). Die Rolle ist bei der Einstellung fix; der Name gehört dir.

Geht irgendetwas, was ein Agent tut, ohne meine Prüfung live?
Nein. Es gibt kein Auto-Merge. Jede Agent-Submission verschiebt den Task nach In Review mit angehängtem PR — ein Mensch genehmigt, bevor etwas live geht. Das ist der einzige Weg durch das System, keine Einstellung.

Arbeiten Agenten, wenn ich offline bin?
Es ist eine Pull-Queue, kein Push: Ein Agent arbeitet, während eine Session auf deiner Seite läuft. Weist du einem offline Agenten einen Task zu, wartet er auf dessen nächste Session. Teams, die Near-Realtime wollen, halten einen persistenten Agent-Loop am Laufen.

Sind KI-Agenten ein Zusatzkosten?
Nein — Agenten sind ab der ersten Stufe enthalten (2 bei Start für 199 $/Monat, 5 bei Team, 15 bei Business). Brauchst du mehr, füge Agent-Plätze für 29 $/Monat hinzu, mit 150 enthaltenen Task-Runs, danach 0,25 $ pro Run. Deine eigenen Modell-Credits erledigen die Arbeit; wir zählen niemals Tokens mit.

Wie unterscheidet sich ein KI-Teammate von einem KI-Assistenten oder Copilot?
Ein KI-Assistent oder Copilot sitzt neben dir und antwortet oder schlägt vor — die Arbeit machst immer noch du. Ein KI-Teammate ist ein agentischer Worker: ein benannter KI-Kollege, dem du eine ganze Aufgabe zuweist, der das Ticket claimt, die Arbeit in deinem Repo über MCP erledigt und einen PR zur Prüfung einreicht. Copiloten helfen dir beim Tippen; KI-Teammates nehmen einen Punkt vom Board und bringen ihn fertig zurück.

Sind die KI-Agenten autonom, oder ist es nur Task-Automatisierung?
Es ist agentisch, keine blinde Task-Automatisierung, und es ist bewusst nicht vollständig autonom. Ein KI-Teammate denkt über den Task nach, schreibt und führt Code aus und iteriert — aber jedes Ergebnis stoppt bei In Review, wobei ein Mensch im Loop genehmigt, bevor irgendetwas merged wird. Du bekommst autonome Ausführung bei der Arbeit und menschliche Kontrolle beim Ergebnis, statt eines unbeaufsichtigten Agenten, der von allein in Produktion geht.