EN
Transparent face derivative of the Kiki cat image supplied by the author
Back to the hall

Kiki

Work signals and agent execution

So that a proposal becomes the assignee's execution.

A Paperclip plugin and a Slack collector that help a team run its AI agents.

2026.04 — 2026.05

pinxlab AI R&D freelance · workflow planning and development, investigating stalled execution and designing the recovery path

  • PluginImplemented · Paperclip
  • MCP serverImplemented · Slack collector

Between assignment and actual execution, a path to observe and recover.

Work signals become profiles and agent directives, and approving a maintenance proposal is kept apart from assigning its execution. When an assigned issue’s activity stops, it is requested again with the issue and assignee, and repeated non-response goes to a limit, a cooldown and a person’s judgment.

They turn work signals into agent directives and connect maintenance proposals, human approval, assignment and the recovery of stalled runs as separate steps. I planned and developed this flow.

First repository record April 3, 2026 · pinxlab engagement through May 26, 2026

Runs as a plugin inside the team's Paperclip; an MCP server handles Slack collection.

Execution flow map · from private implementation records
Kiki signals · approval · execution recoveryWork patterns are extracted from accessible Slack channel history into company profiles and per-agent directives. A maintenance-analysis agent looks at a target project and leaves proposals as unassigned backlog issues; each proposal is posted to Slack, where a person approves or declines it with a reaction. Once an approved issue is assigned to an agent, an external execution system does the work and a stage reaper watches recent activity. If activity stops, the assignment is requested again with the issue and assignee; when consecutive non-responses reach the limit, re-calls stop and the case goes to a lead or operator.Slack signalsAccessible channel historyAssigned agentExternal executionTarget projectContents not shownPerson · approve, declineSlack reactionLead · operatorReassign · notifySignal collectionPattern extraction · no botsCompany stateCompany profile mergeAgent statePer-agent directivesRun observationRecent runs · activityMaintenance analysisPO call · scoped promptIssue trackerProposal · backlogRun issue · todoProposal postingMessage ↔ issue mapStage reaperStall check · heartbeatRecovery callIssue + assigneeNon-response stateNon-responses · per issueLimitStop re-calls · cooldownSignals → directivesExternal executionProposal → human approvalRecovery · escalation1 channel history · Slack signals → Pattern extraction · no bots12 profile merge · Pattern extraction · no bots → Company profile merge23regenerate4 directives in · Per-agent directives → Assigned agent41 target scope · Target project → PO call · scoped prompt12 proposal issue · PO call · scoped prompt → Proposal · backlog23post proposal4Slack message5reaction6approve → todo7decline → cancelled8assignment1run records2last activity3no reply +14new activity → reset5re-call6issue + assignee7after 38reassign · notify9warning only

Signals → directives

Profiles and agent directives are built from Slack history. Directives are agent context and are not drawn as the cause of any proposal.

  1. Slack signalschannel historyPattern extraction · no botsSignal collection

    Accessible channel history is collected and bot, join and leave messages are filtered out. Original messages are not shown on this page.

  2. Pattern extraction · no botsSignal collectionprofile mergeCompany profile mergeCompany state

    Extracted patterns become a profile patch merged into the company profile. These are heuristic patterns, not employee performance scores.

  3. Company profile mergeCompany stateregeneratePer-agent directivesAgent state

    Per-agent directives are regenerated from the merged profile and stored.

  4. Per-agent directivesAgent statedirectives inAssigned agent

    Directives enter an agent’s context when it is created. This does not mean a particular proposal came from a particular Slack signal.

Proposal → approval → assignment

A proposal first exists as an unassigned backlog issue, a person’s reaction requests a status change, and assignment and execution belong to the external system.

  1. Target projecttarget scopePO call · scoped promptMaintenance analysis

    The maintenance job calls the PO agent with a prompt scoped to the target project. Source contents are not shown.

  2. PO call · scoped promptMaintenance analysisproposal issueProposal · backlogIssue tracker

    The prompt asks for proposals with verified paths only, as unassigned backlog issues, and forbids running DB migrations. It is an instruction to a product agent, not a deterministic enforcement mechanism.

  3. Proposal · backlogIssue trackerpost proposalMessage ↔ issue mapProposal posting

    Each proposal is posted to Slack and the message-to-issue mapping is stored. Proposals already posted are not posted again, and the stored map keeps the latest 50.

  4. Message ↔ issue mapProposal postingSlack messagePerson · approve, decline

    A person sees the posted proposal in Slack.

  5. Person · approve, declinereactionMessage ↔ issue mapProposal posting

    A reaction on the message finds the issue through the mapping. There is no automatic approval.

  6. Message ↔ issue mapProposal postingapprove → todoRun issue · todoIssue tracker

    On approval, a request is sent to move the pending proposal issue to todo, and the mapping and thread notice are updated. This handler marks the mapping approved without checking the response code, so it is not a fail-closed transaction.

  7. Message ↔ issue mapProposal postingdecline → cancelledProposal · backlogIssue tracker

    On decline, a request is sent to move the same issue to cancelled. The issue existed before approval; approval does not create it.

  8. Run issue · todoIssue trackerassignmentAssigned agent

    Assignment and execution of a todo issue belong to the external execution system. Moving an issue to todo does not guarantee that work started.

Stall → recovery → person

An assigned issue whose activity stopped is requested again with the issue and assignee; when consecutive non-responses reach the limit, it goes to a person.

  1. Assigned agentrun recordsRecent runs · activityRun observation

    The assigned agent’s runs and recent signals are recorded as observations. Activity is not evidence of completion.

  2. Recent runs · activityRun observationlast activityStall check · heartbeatStage reaper

    The reaper looks only at issues that are not done, cancelled or blocked and that have an assignee, and computes the age of the latest signal and stage.

  3. Stall check · heartbeatStage reaperno reply +1Non-responses · per issueNon-response state

    Consecutive non-responses are counted per agent and issue and stored in state.

  4. Recent runs · activityRun observationnew activity → resetNon-responses · per issueNon-response state

    New activity resets the count.

  5. Stall check · heartbeatStage reaperre-callIssue + assigneeRecovery call

    If the heartbeat is exceeded and the count is below the limit, a recovery call is made.

  6. Issue + assigneeRecovery callissue + assigneeRun issue · todoIssue tracker

    The assignment is requested again with the issue, the assigned agent and an explanatory comment, and the HTTP response is checked. A legacy path falls back to a single wake call.

  7. Non-responses · per issueNon-response stateafter 3Stop re-calls · cooldownLimit

    When consecutive non-responses reach the limit (3 by default), re-calls stop. The limit holds only when state hooks read and write the count, and a failed save can weaken it.

  8. Stop re-calls · cooldownLimitreassign · notifyLead · operator

    Reassigns to a lead where possible, and moves in_progress back to todo only when that feature is enabled. Otherwise leaves a comment and a best-effort notification, and records a cooldown after the limit.

  9. Stall check · heartbeatStage reaperwarning onlyLead · operator

    When a stage lasts too long, only a warning comment is left for operators. Status is not changed automatically.

Every connection at the same weight. Pick a flow to highlight only its path, with numbered steps.

  • Solid · direction of input, results and records
  • Dashed · run, judgment, request
  • Long dots · observation and reporting, apart from judgment
  • Short dashes · failure, stop, limit
  • Heavy black line · the selected flow; numbers give the order
  • Box · code or state boundary, named in its header
  • Inner chip · a component of that boundary
  • Dotted box · outside that boundary
  • Orange outline · where a model decides
  • Agent call · recovery call
  • State · records
  • Stall check · limit
  • Collection · posting

Drawn from private implementation and development records. Team, issue and Slack identifiers and original messages are not shown; deployment, containers and credentials belong to an owner outside this plugin.

One observation
April 28, 2026 report: in a manual diagnosis before the change, one issue that had not run for 67 hours had its assignment requested again with the issue and assignee, and a new run was queued within 5 seconds. Completion, mean recovery time and post-rollout effect were not measured.
Limits of approval handling
Unlike the recovery call, approval handling marks the mapping approved without checking the response code. It is not described as an atomic or fail-closed approval transaction.
When the limit holds
The 3-call limit is an implementation that holds when state hooks are present. It does not guarantee exactly one escalation under every failure.