Transparente Gesichtsableitung des vom Autor bereitgestellten Kiki-Katzenbilds
Zurück zum Saal

Kiki

Arbeitssignale und Agentenausführung

Damit ein Vorschlag zur Ausführung durch den Zuständigen wird.

Ein Paperclip-Plugin und ein Slack-Collector, die einem Team helfen, seine KI-Agenten zu betreiben.

2026.04 — 2026.05

pinxlab AI R&D, freiberuflich · Planung und Entwicklung des Workflows, Untersuchung stockender Ausführung und Entwurf des Wiederherstellungspfads

  • PluginImplementiert · Paperclip
  • MCP-ServerImplementiert · Slack-Collector

Kiki vocabulary

Lens
Agent Execution
Dispatch
Recovery
Work Signals
Signal Ingestion
Proposal
  1. assignment
  2. wake
  3. guardrail
  1. stage reaper
  2. zombie sweeper
  3. circuit breaker
  4. escalation
  1. observe
  2. signals
  3. profile
  4. directive
  1. proposal
  2. approval

Assignment: assigneeAgentId · PATCH /api/issues/:id · queueIssueAssignmentWakeup · issue.updated · CTO TRIAGE · AUTO-PROMOTE TO TODO · AUTO-REBALANCE · in_progress · REASSIGN WITHOUT WAKE · repatchAssignment · kiki-retry-issue · status: todoWake: queueIssueAssignmentWakeup · REASSIGN WITHOUT WAKE · ctx.agents.invoke · POST /api/agents/:id/wakeup · invokeOnce · INVOKE DEDUP · windowMs · HANDOFF-ACK · AT-LEAST-ONCE · HANDOFF_ACK_MAX_RETRIES · ORPHAN WAKE · lastRunAt · maxConsecutiveWakes · WAKE-STORM GUARD · heartbeat_runsGuardrail: issue.updated · in_progress · ORPHAN WAKE · SPEC COMPLETE · PO SPEC GATE · PO DELEGATION GATE · REVIEW SCORECARD · 30/30 · REWORK · PO ACCEPTANCE SCORECARD · findScorecardInComments · ANTI-DECEPTION RATCHET · WORKFLOW GUARDRAILStage Reaper: PATCH /api/issues/:id · lastRunAt · stage-reaper · repatchAssignment · heartbeatSeconds · maxConsecutiveWakes · COOLDOWN · lastSignalTime · stageEntryTime · LEVEL-TRIGGERED · WAKE-STORM GUARD · pipeline-reaper · stage-without-PATCH · kiki-retry-issue · LEAD REROUTEZombie Sweeper: zombie-sweeper · ZOMBIE_RUNNING_MAX_MIN · ZOMBIE_QUEUED_MAX_MIN · execution_run_id · RUN OWNERSHIP CONFLICT · heartbeat_runs · claude_local · execution_locked_at · SELF-HEALCircuit Breaker: CLOSED · HALF_OPEN · auth_fail · rate_limit · RETRY STORM · CB_FAILURE_THRESHOLD · KEY ROTATOR · HTTP 429 · process_lost · agent.run.failedEscalation: process_lost · agent.run.failed · ESCALATION COMMENT · LEAD REROUTE · QA FALLBACK · agent.status_changed · failed-run-escalator · PIPELINE NOTIFIER · pipeline-health-snapshot · SILENT STALLObserve: observe_channel · slack_read_channels · slack_read_thread · slack_read_reactions · slack_user_activity · .last_observed.json · DELTA TRACKING · oldest · SOCKET MODE · kiki-observe · NO RAW TEXTSignals: NO RAW TEXT · UserSignal · message_count · avg_response_time_minutes · active_hours · thread_participation_rate · topic_keywords · evidence_count · LLMExtractedSignal · FeedbackSignalProfile: FeedbackSignal · UserProfile · CommunicationStyle · DecisionPattern · WorkRhythm · focusBlocks · confidence · ContextMode · DELEGATION CHAINS · refresh-profilesDirective: AgentDirective · profileToDirectives · reportFormat · taskConstraints · directiveToSkillMarkdown · agent.created · PATCH /api/skills/{skillId} · grounding_policy · systemPrompt · NO USER PIIMaintenance Proposal: MaintenanceProposal · [MAINT] · daily-maintenance · run-maintenance · kiki-maintain · MAX 10 PROPOSALS · [SCHEMA APPROVAL REQUIRED] · P1/P2/P3 · DO NOT FABRICATE · BOUND TARGETHuman Approval: SOCKET MODE · [SCHEMA APPROVAL REQUIRED] · maint_approve · maint_deny · BLOCK KIT · reaction_added · white_check_mark · ProposalMapping · block_actions · approved · cancelled · status: todo

Zwischen Zuweisung und tatsächlicher Ausführung ein Pfad zum Beobachten und Wiederherstellen.

Arbeitssignale werden zu Profilen und Agentenvorgaben, und die Freigabe eines Wartungsvorschlags bleibt von der Zuweisung seiner Ausführung getrennt. Stoppt die Aktivität eines zugewiesenen Issues, wird mit Issue und Zuständigem erneut angefragt, und wiederholte Nichtantworten führen zu einem Limit, einem Cooldown und der Entscheidung eines Menschen.

Sie machen aus Arbeitssignalen Agentenvorgaben und verbinden Wartungsvorschläge, menschliche Freigabe, Zuweisung und die Wiederherstellung hängender Läufe als getrennte Schritte. Ich habe diesen Ablauf geplant und entwickelt.

Erste Aufzeichnung im Repository April 3, 2026 · Einsatz bei pinxlab bis May 26, 2026

Läuft als Plugin im Paperclip des Teams; ein MCP-Server übernimmt die Slack-Erfassung.

Karte des Ausführungsablaufs · nach nicht öffentlichen Implementierungsaufzeichnungen
Kiki-Signale · Freigabe · Wiederherstellung der AusführungArbeitsmuster werden aus zugänglichen Slack-Kanalverläufen in Unternehmensprofile und Vorgaben pro Agent extrahiert. Ein Agent für Wartungsanalyse betrachtet ein Zielprojekt und hinterlässt Vorschläge als nicht zugewiesene Backlog-Issues; jeder Vorschlag wird in Slack gepostet, wo ein Mensch ihn per Reaktion freigibt oder ablehnt. Sobald ein freigegebenes Issue einem Agenten zugewiesen ist, erledigt ein externes Ausführungssystem die Arbeit, und ein Stage-Reaper beobachtet die jüngste Aktivität. Stoppt die Aktivität, wird die Zuweisung mit Issue und Zuständigem erneut angefordert; erreichen aufeinanderfolgende Nichtantworten das Limit, enden die erneuten Aufrufe und der Fall geht an einen Lead oder Operator.Slack-SignaleZugänglicher KanalverlaufZugewiesener AgentExterne AusführungZielprojektInhalte nicht gezeigtMensch · freigeben, ablehnenSlack-ReaktionLead · OperatorNeu zuweisen · benachrichtigenSignalerfassungMusterextraktion · ohne BotsUnternehmenszustandZusammenführung der UnternehmensprofileAgentenzustandVorgaben pro AgentLaufbeobachtungJüngste Läufe · AktivitätWartungsanalysePO-Aufruf · eingegrenzter PromptIssue-TrackerVorschlag · BacklogAusführungs-Issue · todoPosten von VorschlägenZuordnung Nachricht ↔ IssueStage reaperStillstandsprüfung · HeartbeatWiederherstellungsaufrufIssue + ZuständigerZustand der NichtantwortenNichtantworten · pro IssueObergrenzeErneute Aufrufe stoppen · CooldownSignale → VorgabenExterne AusführungVorschlag → menschliche FreigabeWiederherstellung · Eskalation1 Kanalverlauf · Slack-Signale → Musterextraktion · ohne Bots12 Profilzusammenführung · Musterextraktion · ohne Bots → Zusammenführung der Unternehmensprofile23 neu erzeugen · Zusammenführung der Unternehmensprofile → Vorgaben pro Agent34 Vorgaben einspeisen · Vorgaben pro Agent → Zugewiesener Agent41Zielumfang2 Vorschlags-Issue · PO-Aufruf · eingegrenzter Prompt → Vorschlag · Backlog23Vorschlag posten4Slack-Nachricht5Reaktion6freigeben → todo7ablehnen → cancelled8Zuweisung1Laufprotokolle2letzte Aktivität3keine Antwort +14neue Aktivität → Reset5 erneuter Aufruf · Stillstandsprüfung · Heartbeat → Issue + Zuständiger56Issue + Zuständiger7nach 38neu zuweisen · benachrichtigen9nur Warnung

Signale → Vorgaben

Profile und Agentenvorgaben werden aus dem Slack-Verlauf erstellt. Vorgaben sind Kontext für Agenten und werden nicht als Ursache eines Vorschlags gezeichnet.

  1. Slack-SignaleDaten: KanalverlaufMusterextraktion · ohne BotsSignalerfassung

    Der zugängliche Kanalverlauf wird gesammelt, Bot-, Beitritts- und Austrittsnachrichten werden herausgefiltert. Originalnachrichten werden auf dieser Seite nicht gezeigt.

  2. Musterextraktion · ohne BotsSignalerfassungDaten: ProfilzusammenführungZusammenführung der UnternehmensprofileUnternehmenszustand

    Extrahierte Muster werden zu einem Profil-Patch, der in das Unternehmensprofil eingeht. Es sind heuristische Muster, keine Leistungsbewertungen von Mitarbeitenden.

  3. Zusammenführung der UnternehmensprofileUnternehmenszustandDaten: neu erzeugenVorgaben pro AgentAgentenzustand

    Vorgaben pro Agent werden aus dem zusammengeführten Profil neu erzeugt und gespeichert.

  4. Vorgaben pro AgentAgentenzustandAusführen · Urteil: Vorgaben einspeisenZugewiesener Agent

    Vorgaben gelangen in den Kontext eines Agenten, wenn er erstellt wird. Das heißt nicht, dass ein bestimmter Vorschlag aus einem bestimmten Slack-Signal stammt.

Vorschlag → Freigabe → Zuweisung

Ein Vorschlag existiert zuerst als nicht zugewiesenes Backlog-Issue, die Reaktion eines Menschen fordert eine Statusänderung an, und Zuweisung und Ausführung liegen beim externen System.

  1. ZielprojektDaten: ZielumfangPO-Aufruf · eingegrenzter PromptWartungsanalyse

    Der Wartungsjob ruft den PO-Agenten mit einem auf das Zielprojekt eingegrenzten Prompt auf. Quellinhalte werden nicht gezeigt.

  2. PO-Aufruf · eingegrenzter PromptWartungsanalyseDaten: Vorschlags-IssueVorschlag · BacklogIssue-Tracker

    Der Prompt verlangt Vorschläge nur mit verifizierten Pfaden, als nicht zugewiesene Backlog-Issues, und verbietet das Ausführen von DB-Migrationen. Er ist eine Anweisung an einen Produktagenten, kein deterministischer Durchsetzungsmechanismus.

  3. Vorschlag · BacklogIssue-TrackerDaten: Vorschlag postenZuordnung Nachricht ↔ IssuePosten von Vorschlägen

    Jeder Vorschlag wird in Slack gepostet und die Zuordnung von Nachricht zu Issue gespeichert. Bereits gepostete Vorschläge werden nicht erneut gepostet, und die gespeicherte Zuordnung behält die letzten 50.

  4. Zuordnung Nachricht ↔ IssuePosten von VorschlägenDaten: Slack-NachrichtMensch · freigeben, ablehnen

    Ein Mensch sieht den geposteten Vorschlag in Slack.

  5. Mensch · freigeben, ablehnenAusführen · Urteil: ReaktionZuordnung Nachricht ↔ IssuePosten von Vorschlägen

    Eine Reaktion auf die Nachricht findet das Issue über die Zuordnung. Eine automatische Freigabe gibt es nicht.

  6. Zuordnung Nachricht ↔ IssuePosten von VorschlägenAusführen · Urteil: freigeben → todoAusführungs-Issue · todoIssue-Tracker

    Bei Freigabe wird eine Anfrage gesendet, das wartende Vorschlags-Issue auf todo zu setzen, und Zuordnung und Thread-Hinweis werden aktualisiert. Dieser Handler markiert die Zuordnung als freigegeben, ohne den Antwortcode zu prüfen, daher ist es keine Fail-closed-Transaktion.

  7. Zuordnung Nachricht ↔ IssuePosten von VorschlägenAusführen · Urteil: ablehnen → cancelledVorschlag · BacklogIssue-Tracker

    Bei Ablehnung wird eine Anfrage gesendet, dasselbe Issue auf cancelled zu setzen. Das Issue existierte schon vor der Freigabe; die Freigabe legt es nicht an.

  8. Ausführungs-Issue · todoIssue-TrackerAusführen · Urteil: ZuweisungZugewiesener Agent

    Zuweisung und Ausführung eines todo-Issues liegen beim externen Ausführungssystem. Ein Issue auf todo zu setzen garantiert nicht, dass die Arbeit begonnen hat.

Stillstand → Wiederherstellung → Mensch

Für ein zugewiesenes Issue ohne Aktivität wird erneut mit Issue und Zuständigem angefragt; erreichen aufeinanderfolgende Nichtantworten das Limit, geht es an einen Menschen.

  1. Zugewiesener AgentBeobachtung · Bericht: LaufprotokolleJüngste Läufe · AktivitätLaufbeobachtung

    Die Läufe und jüngsten Signale des zugewiesenen Agenten werden als Beobachtungen aufgezeichnet. Aktivität ist kein Beleg für Abschluss.

  2. Jüngste Läufe · AktivitätLaufbeobachtungBeobachtung · Bericht: letzte AktivitätStillstandsprüfung · HeartbeatStage reaper

    Der Reaper betrachtet nur Issues, die nicht done, cancelled oder blocked sind und einen Zuständigen haben, und berechnet das Alter des letzten Signals und der Stage.

  3. Stillstandsprüfung · HeartbeatStage reaperDaten: keine Antwort +1Nichtantworten · pro IssueZustand der Nichtantworten

    Aufeinanderfolgende Nichtantworten werden pro Agent und Issue gezählt und im Zustand gespeichert.

  4. Jüngste Läufe · AktivitätLaufbeobachtungBeobachtung · Bericht: neue Aktivität → ResetNichtantworten · pro IssueZustand der Nichtantworten

    Neue Aktivität setzt den Zähler zurück.

  5. Stillstandsprüfung · HeartbeatStage reaperAusführen · Urteil: erneuter AufrufIssue + ZuständigerWiederherstellungsaufruf

    Ist der Heartbeat überschritten und der Zähler unter dem Limit, erfolgt ein Wiederherstellungsaufruf.

  6. Issue + ZuständigerWiederherstellungsaufrufAusführen · Urteil: Issue + ZuständigerAusführungs-Issue · todoIssue-Tracker

    Die Zuweisung wird mit dem Issue, dem zugewiesenen Agenten und einem erläuternden Kommentar erneut angefordert, und die HTTP-Antwort wird geprüft. Ein Legacy-Pfad greift auf einen einzelnen Weckaufruf zurück.

  7. Nichtantworten · pro IssueZustand der NichtantwortenFehlschlag · Limit: nach 3Erneute Aufrufe stoppen · CooldownObergrenze

    Erreichen aufeinanderfolgende Nichtantworten das Limit (standardmäßig 3), enden die erneuten Aufrufe. Das Limit hält nur, wenn State-Hooks den Zähler lesen und schreiben, und ein fehlgeschlagenes Speichern kann es schwächen.

  8. Erneute Aufrufe stoppen · CooldownObergrenzeAusführen · Urteil: neu zuweisen · benachrichtigenLead · Operator

    Weist nach Möglichkeit einem Lead neu zu und setzt in_progress nur dann auf todo zurück, wenn diese Funktion aktiviert ist. Andernfalls bleiben ein Kommentar und eine Best-Effort-Benachrichtigung, und nach dem Limit wird ein Cooldown aufgezeichnet.

  9. Stillstandsprüfung · HeartbeatStage reaperBeobachtung · Bericht: nur WarnungLead · Operator

    Dauert eine Stage zu lange, bleibt für Operatoren nur ein Warnkommentar. Der Status wird nicht automatisch geändert.

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung von Eingaben, Ergebnissen und Aufzeichnungen
  • Gestrichelt · Ausführen, Urteil, Anfrage
  • Lang gepunktet · Beobachtung und Berichte, getrennt vom Urteil
  • Kurz gestrichelt · Fehlschlag, Stopp, Limit
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · Code- oder Zustandsgrenze, benannt in der Kopfzeile
  • Innerer Chip · eine Komponente dieser Grenze
  • Gepunkteter Kasten · außerhalb dieser Grenze
  • Orange Umrandung · wo ein Modell entscheidet
  • Agentenaufruf · Wiederherstellungsaufruf
  • Zustand · Aufzeichnungen
  • Stillstandsprüfung · Obergrenze
  • Erfassung · Posten

Gezeichnet nach nicht öffentlichen Implementierungs- und Entwicklungsaufzeichnungen. Team-, Issue- und Slack-Kennungen sowie Originalnachrichten werden nicht gezeigt; Deployment, Container und Zugangsdaten liegen bei einem Verantwortlichen außerhalb dieses Plugins.

Eine Beobachtung
Bericht vom April 28, 2026: In einer manuellen Diagnose vor der Änderung wurde für ein Issue, das 67 Stunden nicht gelaufen war, die Zuweisung mit Issue und Zuständigem erneut angefordert, und innerhalb von 5 Sekunden stand ein neuer Lauf in der Warteschlange. Abschluss, mittlere Wiederherstellungszeit und Wirkung nach dem Rollout wurden nicht gemessen.
Grenzen der Freigabeverarbeitung
Anders als der Wiederherstellungsaufruf markiert die Freigabeverarbeitung die Zuordnung als freigegeben, ohne den Antwortcode zu prüfen. Sie wird nicht als atomare oder Fail-closed-Freigabetransaktion beschrieben.
Wann das Limit hält
Das Limit von 3 Aufrufen ist eine Implementierung, die hält, wenn State-Hooks vorhanden sind. Sie garantiert nicht genau eine Eskalation bei jedem Fehlschlag.