Produktteams: Tickets, Feedback und Roadmap in einen Agenten verdrahten

Produktarbeit ist Synthese-Arbeit. Das Signal, das ein PM an einem beliebigen Dienstag braucht, ist verstreut über den Issue-Tracker, drei Feedback-Kanäle, das Analytics-Tool und ein Doku-Wiki mit starken Meinungen zur Benennung. Ein KI-Agent für Produktteams ist genau in dem Maß nützlich, in dem er all das gleichzeitig lesen kann, und MCP, das Model Context Protocol, ist die Rohrleitung, die das ohne eigenes Integrationsprojekt möglich macht.

Hier ist, was wirklich funktioniert, was du zuerst verdrahtest, und das eine Ding, das den Unterschied zwischen Demo und Gewohnheit macht.

Drei Jobs, die ein Produkt-Agent gut macht

Die Wochen-Synthese. "Fass zusammen, worüber Nutzer diese Woche geklagt haben, gruppiert nach Feature, mit Ticket-Links." Ein Agent mit Zugriff auf Helpdesk und Tracker macht aus einer Stunde Tab-Hüpfen eine Anfrage, die du beim Kaffeeholen stellst. Der Output ist nur so gut wie der Zugriff: Feedback in einem Tool, das der Agent nicht lesen kann, existiert für ihn nicht.

Duplikate und Triage. Neue Tickets werden gegen bestehende verglichen, getaggt und geroutet. Das ist Fleißarbeit, die Menschen am Freitagnachmittag schlecht machen und Agenten zu jeder Stunde konstant. Lass am Anfang einen Menschen am Merge-Knopf; das Finden übernimmt der Agent.

Release-Note-Entwürfe. Der Agent liest die gemergte Arbeit aus dem Tracker, prüft in der Doku die kundengerichteten Namen der Dinge und liefert einen Entwurf in eurer Stimme. Jemand redigiert den Ton, niemand startet vom leeren Blatt.

Beachte das Muster: Alle drei Jobs sind leselastig und werkzeugübergreifend. Das ist der Sweet Spot. Schreibzugriff (Tickets schließen, Roadmap ändern) kann später kommen, wenn das Audit-Log Vertrauen verdient hat.

Die Verkabelung, ohne Yak-Rasur

Jedes dieser Tools (Tracker, Helpdesk, Analytics, Doku) liefert zunehmend seinen eigenen MCP-Server; unser [Verzeichnis](/de/discover) sagt dir in einer Minute, welche deiner Tools dabei sind. Verbinde sie einzeln mit deinem Agenten, und es funktioniert, bis es das nicht mehr tut: Vier Tools heißen vier Auth-Flows, vier Configs und vier Tool-Kataloge, die bei jedem einzelnen Request in den Kontext des Modells laden. Bei typischen Schema-Größen sind das leicht 15.000 bis 20.000 Tokens stehender Overhead, bevor der Agent deine Frage liest. Die Arithmetik steht in [Wie viele MCP-Server sind zu viele?](/de/blog/how-many-mcp-servers-is-too-many).

Ein MCP Gateway gibt dem Team stattdessen einen Endpunkt. Tools werden einmal zentral verbunden, mit begrenzten OAuth-Freigaben; der Agent jedes PMs zeigt auf dieselbe URL und sieht denselben Katalog. Wechselt das Team nächstes Quartal den Analytics-Anbieter, passiert der Wechsel am Gateway, und niemand editiert eine Agenten-Config.

Für ein Team (im Unterschied zu einem einzelnen Entwickler) beantwortet das Gateway auch die Governance-Fragen, die den Rollout sonst im Review töten: wer welchen Zugriff freigegeben hat, wo Zugangsdaten leben und [was der Agent letzten Donnerstag wirklich im Tracker getan hat](/de/blog/ai-agent-audit-trail).

Der Unterschied zwischen Demo und Gewohnheit: Memory

Jedes Produktteam, das einen Agenten pilotiert, trifft in Woche zwei dieselbe Wand. Der Agent ist schlau, der Zugriff funktioniert, und trotzdem beginnt jede Session mit demselben Briefing: was "Activation" in euren Metriken heißt, dass "Projects v2" extern "Spaces" heißt, dass die März-Entscheidung war, die Mobile-App zu deprioisieren, dass Feedback der Enterprise-Pilotgruppe schwerer wiegt als Drive-by-Feature-Wünsche.

Dieses Briefing ist Produkt-Kontext, und es ist genau die Sorte stabilen, sich langsam ändernden Wissens, das ein zustandsloser Agent dich ewig neu liefern lässt. Es ist auch die Stelle, an der die Token-Rechnung leise wächst: Neu eingefügter Kontext wird bei jedem Schritt jeder Session bezahlt.

Ein Agent mit Memory-Schicht speichert diese Fakten beim ersten Mal und ruft sie in der nächsten Session ab. Namenskonventionen bleiben. Entscheidungen bleiben, samt Begründung. Der Agent, der im Oktober Release Notes entwirft, kennt noch die Benennungsregel aus dem Juli. Wie Memory auf Gateway-Ebene funktioniert, steht in [MCP Gateway mit Memory](/de/blog/mcp-gateway-with-memory); die Produktteam-Übersetzung ist ein Satz: Eure Entscheidungen verdampfen nicht mehr zwischen Sessions.

Ein praktischer Tipp unabhängig vom Tooling: Wenn eine Entscheidung fällt, sag dem Agenten explizit, dass er sie sich merken soll, mit dem Warum. "Wir haben Mobile deprioisiert, weil Activation web-first ist, Wiedervorlage Q1" ist ein Fakt, der einen Speicher-Aufruf und viele künftige Abrufe wert ist.

Ein Rollout, der den Realitätskontakt überlebt

Woche 1: Ein PM, zwei Tools (Tracker plus Helpdesk), nur lesend, über einen Gateway-Endpunkt. Die Wochen-Synthese auf echten Daten fahren.

Woche 2: Doku und Analytics dazu. Entscheidungen und Namenskonventionen im Memory speichern, sobald sie auftauchen.

Woche 3: Den Agenten im Tracker taggen und Duplikate vorschlagen lassen. Vorschläge, keine Merges.

Woche 4: Gemeinsam das Audit-Log durchgehen, entscheiden, welche Schreibrechte der Agent verdient hat, und erst dann erweitern.

Wo wir hingehören, klar gesagt: [Tulimoas Gateway](/de/gateway) ist ein Endpunkt mit begrenzten Verbindungen, einem Audit-Trail und Memory-Tools (remember, recall, checkpoint, set_goal), kostenlos auf jedem Plan, EU-gehostet. Es ist in früher Beta, noch nicht self-serve, und jeder Plan verbindet aktuell einen Agenten. Nimm den Rollout-Plan so oder so mit; er funktioniert mit jedem Gateway, das diese Bausteine hat.