multi-agent-orchestration-architect

Designs multi-agent orchestration systems with BullMQ job chains, LLM routing, and tool registries.

1|Updated Aug 25, 2026
One-click install
npx skills add https://github.com/sabiscore/swarmxq --skill multi-agent-orchestration-architect-sabiscore
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: multi-agent-orchestration-architect
Source: https://github.com/sabiscore/swarmxq/tree/main/.ai/skills/multi-agent-orchestration-architect
Command: npx skills add https://github.com/sabiscore/swarmxq --skill multi-agent-orchestration-architect-sabiscore

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires bullmq, ioredis, effect.

What problem does it solve? Building multi-agent AI systems fails most often at routing correctness, state integrity, and failure isolation. This Skill provides architectural patterns for agent registries, job queues, LLM fallback routing, tool authorization, and prompt injection defense so these problems are solved structurally rather than patched per feature. ## Core Features & Use Cases - Agent Registry and Contracts: Define each agent role with an explicit model, fallback model, tool allowlist, timeout, and versioned system prompt before writing any implementation code. - BullMQ Job Architecture: Structure agent work as stateless jobs with correlation IDs, retry policies, separate Redis connections, and per-role worker concurrency limits. - LLM Router with Fallback: Wrap every model call in a timeout, automatic fallback to a secondary model on rate limits, input sanitization against prompt injection, and token usage metrics. - Use Case: When building a system where an orchestrator agent decomposes a user request into sub-tasks executed by coder, researcher, and evaluator agents, use this Skill to design the pipeline state machine, tool dispatch authorization, and OpenTelemetry tracing before writing agent code. ## Quick Start Ask the AI to design the agent registry and BullMQ job architecture for a multi-agent pipeline with an orchestrator, coder, and evaluator role.

Frequently Asked Questions about multi-agent-orchestration-architect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a multi-agent orchestration system with LLM routing?

Start by defining an agent registry where each role has an explicit contract: primary model, fallback model, tool allowlist, timeout, and versioned system prompt. The orchestrator decides routing; agents never route themselves, and all state lives in the job payload or database.

How do I add fallback models and timeouts to LLM agent calls?

Wrap each LLM call in a hard timeout using the agent spec's timeoutMs, then catch timeout and rate-limit errors to retry against the fallback model. Emit token usage metrics for every invocation so fallback frequency is observable.

How do I prevent agents from calling unauthorized tools?

Use an explicit tool registry with a dispatch layer that checks the agent's allowedTools allowlist before executing any tool. Validate tool inputs against a schema, and never use wildcard tool permissions in the agent registry.

Does BullMQ require separate Redis connections for queues and workers?

Yes, BullMQ requires separate ioredis connections for the Queue, Worker, and QueueEvents instances. Sharing a single connection causes blocking commands to interfere with each other and leads to stalled or lost jobs.

How do I defend LLM agents against prompt injection?

Sanitize all user input before it enters any agent's context: cap length, strip system: prefixes, and remove ChatML or Llama instruction markers. Keep user input in the user turn only, never interpolated into the system prompt.

Why should agents be stateless between turns?

In-memory agent state breaks under retries, worker restarts, and horizontal scaling. Keeping all state in the BullMQ job payload or database lets any worker resume any task and makes pipelines recoverable after failure.