desplega-ai/agent-swarm

Intent A worker makes 89 sequential API calls between process start and its first GET /api/poll. On a local Docker worker this costs about 1 ms per call and nobody notices. On a remote runtime (E2B through a tunnel) each call is a few hundred ms, so boot takes about 16 s longer than needed. This matters for the on-demand worker work (draft PR #2045), where per-task runtimes pay the boot cost on every task. Make worker boot fast and cheap: fewer calls, no repeats, batched where possible. Proposal & trade-offs Measured in the #2045 spike (E2B, fresh DB with seeded skills). Breakdown: Phase Calls What it does Entrypoint 6 MCP servers, repos, setup script, skills, agent-fs credentials, resolved config Runner, before register 10 keys/available, GET /api/config x4 (scopes), 5 prompt renders Register 7 POST /api/agents (201), 5 renders, POST /api/agents again (200) Runner setup 6 credential status, session cleanup, orphan recovery, /me, profile PUT, MCP servers again Prompts 5

Intent A Slack thread buffer flush batches several messages into one task, but the pre.task.create payload identifies only one of them. An extension that wants to act on each message (react, mute, log, attribute to a sender) can reach only the last one. It must parse prose out of the description to get the rest of the text, and cannot get their timestamps at all. Found while building the slack-reply-gate extension template (#2023, see its README "Known limits"): it mutes only the last message of a multi-message flush, and the others keep their acceptance reaction. The gap is in the event payload, not that extension. Mechanism, at 62da4015, in slackFlush (src/slack/thread-buffer.ts): slackTriggerMessageTs is items.at(-1)!.ts, the last message. slackUserId is originalRequesterId, the sender of the first message (line 300). With mixed senders, the user and timestamp point at different messages. The text of every message is present, joined with --- under a [Thread follow-up — N message(

Intent When a pre.task.create extension blocks a task created by the Slack thread buffer flush, the block surfaces as an uncaught error in the logs. A block is an intended outcome, not a failure. Operators reading logs see a false error, and the flush has no way to report or react to the block. Found while building the slack-reply-gate extension template (#2023, see its README "Known limits"). The gap is in the extension system's call sites, not that extension. Mechanism, at 62da4015: prepareTaskWithSiblingAwareness in src/tasks/sibling-awareness.ts turns a block into throw new TaskCreationBlockedError(...) (line 164). createSlackTaskWithFiles (src/slack/inbound-files.ts, line 285) does not catch it, and neither does slackFlush (src/slack/thread-buffer.ts). The error reaches the generic doFlush catch in src/tasks/additive-buffer.ts (lines 98 to 102), which logs onFlush threw for key=... at error level. Other call sites already treat a block as an outcome: the Slack mention path (src/

Intent An extension cannot veto a Slack thread follow-up that is steered into a running task. Steering is a second delivery path next to task creation, and no pre-hook covers it. Any extension that gates or filters inbound Slack messages (a reply gate, a spam or PII filter, a rate limiter) silently loses coverage whenever the thread already has a task in progress. Found while building the slack-reply-gate extension template (#2023, see its README "Known limits"). The gap is in the extension system, not that extension. Mechanism, at 62da4015: src/slack/handlers.ts buffers a non-mention thread reply and returns early (the return; // Don't process further at line 585). pre.slack.route is dispatched later (line 595), so buffered follow-ups never reach it. slackFlush in src/slack/thread-buffer.ts (from line 151) calls requestSlackThreadSteering first. When it returns a result, the flush posts the steering ack and returns. createSlackTaskWithFiles, and with it pre.task.create, never runs. r

Intent Operators need to move only suitable short glue scripts to QuickJS while other scripts keep native execution. SCRIPT_EXECUTOR currently selects the executor server-wide. Split from #1953 following #1951 (merged). Original item 6. Proposal & trade-offs Pointers: src/be/scripts/db.ts, src/be/scripts/run-saved.ts, src/http/scripts.ts, src/http/x.ts, src/scripts-runtime/loader.ts, src/scripts-runtime/executors/registry.ts, and src/be/migrations/. Decide whether the override belongs on scripts or script APIs, define precedence, and expose it in the appropriate management surface. Persistent selection may require a migration; retaining the global default keeps existing deployments compatible. Acceptance criteria A saved script (or explicitly documented script-API override) can select native or quickjs. Unset overrides inherit global SCRIPT_EXECUTOR; existing scripts retain behavior. Invalid executor names are rejected and execution surfaces follow documented precedence. Any migration