# Course Specification: Build Your Own Swarm Bot Army **Slug / task key**: `swarm-bot-army` **Added**: 2026-10-06 by claude_cli at the user's request (the user's brief is condensed below; every requirement kept) **Audience of the course**: normal, non-technical people who already use several AI agents as a team (Build Bots Better Stages 3/4) **Every agent builds its own version, blind** (hub #13 / D18). Shared: this brief and the facts below. Yours: design, wording, exercises and the working swarm. ## Facts about what Build Bots Better already has (Stage 3/4), usable in every version - Communication: the Conversation Hub (`bots/conversation_hub/hub.py`, table `BOTS.dbo.communications`): every agent reads its inbox, posts, resolves. - Independent work + competition: every agent builds every course blind (hub #13); versions are compared, never copied. - Grading: peer grading queue, one grader at a time per task until an A (`grades.py turns/queue`), plus an honest adversarial self-audit (sql/014). - Task board: `grades.py tasks` (not_started / in_progress / completed per task x agent); `inbox` prints COURSE GAPS. - Usage: each agent reports plan usage daily (`grades.py usage`); at 90%+ it leaves the grading queue until its reset (hub #35). - Memory: DEV_LOG tables per database, educational/ docs, per-agent memory files, INCIDENT threads in the hub. - Identity: each agent has its own SQL login, so every record is attributable. - What is NOT there yet (the course adds it): a coordinator that turns a mission into tasks, measured skill profiles, automatic bot selection by skill + cost, dependency-aware parallel execution, automatic failure recovery, and a mission dashboard. ## Honesty requirements - Any simulated/practice bots must be labelled as practice; skill scores must come from real observed tests, never from reputation. - Costs: show only measured usage, or clearly labelled estimates. Never make paid usage a required step. - Autonomous never means unsupervised: approvals, budgets, retry and runtime limits are part of the build. --- ## The user's brief (every requirement, condensed from the paste) ```text COURSE TITLE: "Build Your Own Swarm Bot Army" IMPORTANT: This course is designed for NORMAL, NON-TECHNICAL PEOPLE. Do NOT assume the learner understands: AI agents, multi-agent systems, APIs, orchestration, distributed systems, agent frameworks, message buses, vector databases, swarm intelligence, autonomous agents. Those concepts can be introduced gradually, but explain everything in plain English first. The learner should finish the course understanding the concepts AND having actually built a working Swarm Bot Army. THE BIG IDEA Build Bots Better already teaches people how to use multiple AI systems as an AI team. The learner has progressed through: STAGE 1 Single AI Bot; STAGE 2 Multiple AI Bots; STAGE 3 AI Team; STAGE 4 AI Competition. The learner is now ready for: STAGE 5 Swarm Bots; STAGE 6 Autonomous Swarms. This course should NOT spend significant time reteaching Stages 1-4. Briefly establish that foundation and then focus heavily on the transition: AI TEAM -> AI COMPETITION -> SWARM -> AUTONOMOUS SWARM. The ultimate goal is: a human gives the swarm a MISSION. The swarm determines: what needs to be done, what skills are required, which bots are best suited, which tasks can happen simultaneously, which bot should perform each task, how the bots communicate, how progress is monitored, how failures are handled, how results are tested, how results are graded, whether something needs to be repaired, when the mission is actually complete. The human should eventually be able to say "Here is the mission." rather than "Bot A, do this. Bot B, do that. Bot C, check this." THE DRONE SWARM ANALOGY Use the concept of a swarm of drones as a simple mental model. Do NOT teach military tactics or weapons. Use the analogy only to explain coordination. A person controlling 100 drones individually is NOT really using the intelligence of a swarm. A swarm operates more like: MISSION -> INDIVIDUAL UNITS -> OBSERVE -> COMMUNICATE -> COORDINATE -> ADAPT -> COMPLETE MISSION. Translate that concept into AI. An AI TEAM means humans largely organize the bots. An AI SWARM means the bots can organize work around a shared mission. An AUTONOMOUS SWARM means the human can provide a mission and the swarm can execute most of the workflow independently within defined boundaries. THE COURSE'S CORE QUESTION "Can we give a group of AI bots a mission and have them figure out how to accomplish it?" Stage 5: "Yes, with swarm coordination." Stage 6: "Yes, with autonomous execution and human oversight." BUILD BOTS BETTER'S EXISTING ADVANTAGE Build Bots Better already has a working multi-AI environment. The bots are already capable of: communicating, performing independent work, creating builds, competing, grading each other's work, recording activity, communicating through a shared system, producing measurable results. Therefore, DO NOT design this course as though we are starting from zero. We are evolving an existing AI TEAM / AI COMPETITION system into a SWARM. The course should explicitly show: "Here is what we already have." "Here is what is missing." "Here is how we add it." THE MAJOR NEW SWARM COMPONENTS (the course MUST teach and implement these) 1. SWARM COORDINATOR - manages the mission: receiving the mission, breaking it into tasks, determining required skills, requesting qualified bots, assigning work, monitoring progress, detecting failures, requesting replacements, coordinating verification, determining when the mission is complete, reporting results to the human. The coordinator should NOT necessarily perform all the work itself. COORDINATOR = mission manager; BOTS = workers/specialists. 2. SKILL SETS - every bot has a capability/skill profile (coding, debugging, research, writing, data analysis, image generation, image editing, video generation, video editing, web research, planning, testing, fact checking, SQL, file management, automation, documentation, creative work, social media, etc.). Do NOT assume the initial ratings are correct. The swarm should learn them. 3. SKILL DISCOVERY / BOT TESTING - one of the most important innovations. The swarm gives bots TEST TASKS (e.g. "Create a promotional image for Build Bots Better", "Research this topic and provide five verified findings", "Create a short video", "Write a Python script", "Debug this broken application"). Several bots attempt each; the swarm evaluates quality, speed, accuracy, completeness, usefulness, reliability, tool usage, errors, cost/usage where available, and records the result. The swarm gradually learns WHO IS GOOD AT WHAT, producing a dynamic BOT SKILL PROFILE. (Example numbers in the brief - Claude Coding 94 / Debugging 97, Grok Images 96, Qwen Local/private 98 - are examples only.) The actual system generates its own scores from real tests. Rankings are NOT permanent; bots are retested periodically; scores are based on observed performance, not reputation or assumptions. 4. SWARM MEMORY - teach INDIVIDUAL BOT MEMORY vs SWARM MEMORY. Swarm memory retains previous missions, successful and failed strategies, agent performance, skill scores, task results, discoveries, decisions, lessons learned, recurring problems, successful workflows, verification results. Example: Mission #17 Bot A failed at video generation; in Mission #18 the coordinator should know that and consider the swarm's historical performance. 5. USAGE MONITORING - tokens, API usage, model usage, time, task count, failures, retries, tool calls, image/video generations, estimated cost, successful and unsuccessful tasks. The real question is "Which bot is the best choice for THIS task considering quality, speed, reliability, and cost?" (Bot A 95%/$0.50/2 min vs Bot B 93%/$0.05/20 s: the swarm may reasonably choose B.) Swarm intelligence includes resource management. 6. SWARM MONITORING DASHBOARD - mission status, active/available bots, current/queued/completed/failed/blocked tasks, bot status, skills, performance, usage, token usage, estimated cost, messages, errors, retries, verification status, overall mission progress. Understandable to a non-technical human: "What is my swarm doing right now?" 7. DYNAMIC TASK ASSIGNMENT - not permanent roles. MISSION -> TASK -> REQUIRED SKILLS -> AVAILABLE BOTS -> BOT PERFORMANCE HISTORY -> USAGE/COST -> SELECT BEST BOT -> ASSIGN TASK. The same bot may get different roles on different missions. 8. PARALLEL WORK - recognise tasks that can happen simultaneously vs those that wait for dependencies (example mission: "Create a YouTube educational video": research, script, images, video, title, description, fact-check). 9. FAILURE RECOVERY - bots crash, time out, misunderstand, produce bad/incomplete/unusable output, lose tool access. FAILURE DETECTED -> UNDERSTAND FAILURE -> RETRY? -> REASSIGN? -> CHANGE APPROACH? -> VERIFY -> CONTINUE. The mission should NOT automatically fail because one bot fails. 10. COMPETITION + SWARM - for an important task the coordinator sends a TEST TASK to several qualified bots; they work independently; the swarm evaluates; the winner becomes the preferred agent for the actual mission. TEST -> COMPETE -> GRADE -> SELECT -> EXECUTE. 11. THE SWARM LEARNS WHO IS GOOD AT WHAT - a "BOT TALENT DATABASE" (skills, reliability, average speed, average cost, success rate), so the learner can see "X is currently our best debugger". The system must discover actual performance. 12. HUMAN OVERSIGHT - HUMAN DEFINES THE MISSION. SWARM EXECUTES. HUMAN MONITORS. SWARM REPORTS. HUMAN APPROVES IMPORTANT ACTIONS. AUTONOMOUS does not mean UNSUPERVISED. Boundaries: spending limits, allowed tools, allowed websites, data access, release permissions, destructive actions requiring approval, maximum retries, maximum runtime, maximum cost. 13. THE 6 STAGES - 1 Single bot, 2 Multiple bots, 3 AI team, 4 AI competition, 5 Swarm bots (bots dynamically organize around a mission), 6 Autonomous swarm (human provides the mission, swarm manages execution within defined boundaries). Spend about 10-15% reviewing Stages 1-4 and 85-90% building Stages 5-6. COURSE PROJECT - "Give Your Swarm a Mission." The learner provides MISSION, OBJECTIVE, CONSTRAINTS, AVAILABLE RESOURCES, SUCCESS CRITERIA, APPROVAL RULES. The swarm then: 1 understands the mission, 2 breaks it into tasks, 3 identifies required skills, 4 checks available bots, 5 checks bot skill history, 6 checks usage/cost, 7 determines parallel tasks, 8 assigns tasks, 9 executes, 10 communicates, 11 monitors, 12 handles failures, 13 tests results, 14 grades results, 15 repairs failures, 16 verifies completion, 17 reports back to the human. NON-TECHNICAL LEARNING STYLE - extremely practical: SHOW -> EXPLAIN -> DO -> TEST -> SEE RESULT -> NEXT STEP. The learner should watch the bots perform the work. Simple analogies: restaurant kitchen, construction crew, emergency response team, air traffic, drone swarm, sports team, factory, movie production crew. Don't make the learner understand the technology before letting them see it work. TEACHING PHILOSOPHY - "Don't become a better typist for AI. Become a better manager of AI." PROMPTING BOTS -> MANAGING BOTS -> DESIGNING TEAMS -> BUILDING SWARMS -> MANAGING MISSIONS. COURSE OUTPUT REQUIRED - a complete course specification including: 1 title, 2 subtitle, 3 course promise, 4 target audience, 5 prerequisites, 6 what the learner already has at Stage 3/4, 7 learning objectives, 8 modules, 9 lessons in every module, 10 hands-on exercises, 11 bot demonstrations, 12 swarm architecture, 13 skill system, 14 skill testing system, 15 bot ranking system, 16 swarm memory, 17 usage monitoring, 18 cost monitoring, 19 mission monitoring, 20 coordinator design, 21 task assignment, 22 task dependencies, 23 parallel execution, 24 failure recovery, 25 competition/testing system, 26 verification system, 27 human approval system, 28 dashboard requirements, 29 final capstone, 30 graduation criteria. For every major feature: WHAT IT IS, WHY IT MATTERS, HOW IT WORKS, HOW THE LEARNER SETS IT UP, HOW TO TEST IT, WHAT CAN GO WRONG, HOW TO FIX IT. VERY IMPORTANT: THE COURSE SHOULD TEACH THE SETUP. Show the learner how to actually build it, in small, testable steps. After each major setup step: STOP, TEST, VERIFY, then continue. The learner should never build 15 things and discover at the end that something broke on step 3. FINAL TEST - a real mission the swarm has never seen. The human provides only MISSION, CONSTRAINTS, SUCCESS CRITERIA. The swarm determines WHO, WHAT, WHEN, HOW, IN WHAT ORDER. The learner watches. The swarm must demonstrate: skill discovery, bot selection, task decomposition, parallel work, communication, memory, usage monitoring, failure recovery, competition where appropriate, testing, grading, verification, final reporting. Final question: "Could a human give this swarm a mission tomorrow and trust it to figure out how to execute the work without micromanaging every bot?" If YES, the learner has completed the course. FINAL COURSE MESSAGE - ONE BOT -> MULTIPLE BOTS -> AI TEAM -> AI COMPETITION -> SWARM -> AUTONOMOUS SWARM, and: "You don't need to become an AI programmer. You need to learn how to build, manage, test, and supervise an AI workforce." ``` Full brief lives at educational/courses/BUILD_YOUR_OWN_SWARM_BOT_ARMY.md (sections 1-30). grok_bot BUILD_029 authored 2026-10-06 blind from that brief.