AgentSwarms-fyi/agentswarms

What Runs, tool calls, tokens and cost are recorded in execution_traces, swarm_runs and swarm_run_steps, and shown in the app's own Traces and Analytics pages. There is no way to get any of it into the monitoring stack an operator already runs. Why it matters Anyone self-hosting this next to other services wants one place to watch. Right now AgentSwarms is a blind spot in their dashboards, and its alerting sits in a separate silo from everything else they operate. Where to start src/utils/observability/otelExport.server.ts — a stub exists; check what is there before designing src/utils/observability/recordGatewayUsage.server.ts — the single choke point every model call passes through, so the natural place to emit src/routes/api/health.ts — the pattern for an unauthenticated operational endpoint Acceptance criteria OTLP span export for runs and their steps, with parent/child structure preserved (a swarm run is the parent of its node steps) A /metrics endpoint in Prometheus te

What Deep-mode document generation asks the model for an entire 20–30 slide plan as a single JSON object, up to 16k output tokens. It works on strong models and is fragile everywhere else: one truncation or one malformed brace loses the whole document after a minute of generation. Why it matters This is the main reason document generation fails on smaller and free-tier models — which is most self-hosted instances. It also makes every failure total: there is no partial deck. Where to start src/lib/docGen/plan.ts — planPptx() / planDocx() / planXlsx() build the single large request src/routes/api/bi.ts — enforces the completion cap, and records a parse failure with the token count and both ends of the payload, which is how you tell truncation from malformed output src/lib/docGen/biData.ts — materializePptxWithBI() already runs per-visual work through a bounded pool; the same shape suits batched planning Suggested approach: ask for an outline first (titles, layouts, the analyt

What A notebook can be published as a callable API (POST /api/notebook/run), and swarms can run on a schedule — but a notebook cannot. Every recurring notebook job needs an external cron calling the endpoint. Why it matters The obvious case is the nightly report: a notebook that queries data, calls an agent, writes output. Today that needs infrastructure outside the platform, which rather defeats the point of a self-contained one. Where to start Mirror swarm_schedules rather than inventing a parallel mechanism: the swarm_schedules migration for the table shape the existing cron route that fires due swarm schedules src/routes/api/notebook.run.ts — the execution path exists; a schedule only has to trigger it notebook_api_keys.entrypoint — the same entrypoint convention should apply Acceptance criteria Per-notebook schedule (cron expression, or a daily/weekly picker) with a timezone Runs through the existing cron entry point Runs are attributable — reuse notebook_runtime_ses

Corrected after filing. The original text claimed the canvas runtime had no parallel execution. That was wrong — it has had bounded-parallel levels for some time. The real gap is narrower and is described below. What The canvas runtime (src/lib/swarmRuntime.ts) already runs a level's nodes through a bounded worker pool (MAX_PARALLEL_NODES = 4). Two things separate it from the headless executor (src/utils/swarmExecute.server.ts), and both are worth closing: 1. Parallel writes are committed in completion order, not level order. Each node mutates ctx[outVar] and lastOutput directly as it finishes. When two nodes in the same level write the same variable, the winner is whichever model replied first — so the same swarm on the same input can produce different output on different days. lastOutput has the same problem: an unconnected downstream node sees whichever parallel node happened to finish last. 2. A level containing a condition, router or approval drops to fully sequential. if (ha

What kb_chunks.embedding is vector(1536) and src/utils/tools/embedding.server.ts hard-validates that width. Any model that cannot emit 1536 dimensions is unusable, however good it is. Why it matters Hit in practice, not theoretical. Several strong embedding models are natively 768, 1024 or 4096 and do not support the OpenAI dimensions truncation parameter — including most local models people want for self-hosting (nomic-embed-text is 768, mxbai-embed-large is 1024). Today the embed fails with a dimension mismatch and the only fix is a different model. The hard part You cannot simply widen the column. Vectors from different models are not comparable, so one index cannot hold two spaces — searching model A's chunks with model B's query vector returns confident nonsense rather than an error. The bookkeeping already exists: the provider and model are recorded per document in knowledge_documents.metadata (embedding_provider / embedding_model), and retrieval embeds the query with whateve