# AI development toolkit for the team Feb 2026 – present · Lead · Internal tool I built the shared workspace the development team uses to work with AI coding agents (Claude Code, with basic Codex support), so every developer starts with the same codebase knowledge, workflows and safety rails. The whole team adopted it at first; it later branched into environment-specific setups, and about four developers still use the original. **Scale:** 20 agent definitions · 67 skills in 13 plugins · 3 MCP servers · 9 hooks - Knowledge as skills: a catalog of skills per repository, technology, process and operation, which agents load on demand instead of carrying everything in their prompt. - skill-discovery (BM25), web-crawl (documentation RAG) and persistent memory on an extended open-source server. - A conductor workflow: a planning session delegates to role agents (investigator, architect, developer, reviewers, tester) in a fixed order with review gates. - Hooks recall memories at session start, capture the user’s corrections, and block destructive commands and pushes to protected branches. - Per-agent disposable AWS environments built on floci, an open-source emulator. **Stack:** Claude Code, MCP, BM25, RAG, Docker **My role:** Lead: designed and built the workspace, its agents, skills, hooks and MCP servers. Teammates added a few skills of their own. ## Context Instead of one giant prompt, knowledge lives in skills that agents load on demand, and one planning session delegates the work to role agents in a fixed order, with review gates. Two needs came later: memory that carries corrections from one session to the next, and a way for several agents to test real backend code at the same time without sharing one cloud account. ## Timeline - **Feb 2026:** The workspace, the conductor and its agents; skill-discovery. - **Mar 2026:** web-crawl and the memory server. - **Jul 2026:** Memory through the Claude CLI, for subscription sign-in. - **Aug 2026:** Safety hooks; basic Codex support. - **Sep – Oct 2026:** Per-agent AWS environments on floci. ## Architecture A conductor session plans and delegates; role agents pull skills, documentation and memory through three MCP servers, and test against their own AWS sandbox. - **Developer:** Conductor session (Plans and delegates; never writes the code) - **Agents and hooks:** Role agents (Investigator, architect, developer, reviewers, tester); Hooks (Memory recall and capture, safety guards) - **MCP servers and sandboxes:** skill-discovery (BM25 over the skill catalog); web-crawl (Documentation, searched by meaning); Memory (Facts and preferences across sessions); AWS sandbox (One per agent, on the floci emulator) Flows: 1. Conductor session → Role agents: Delegates in a fixed order, with review gates and send-back 2. Conductor session → Hooks: Session events: start, prompt, tool use, stop 3. Role agents → skill-discovery: Search and load the skills a task needs 4. Role agents → web-crawl: Search crawled documentation 5. Hooks → Memory: Recall at session start; store the user’s corrections 6. Role agents → AWS sandbox: Deploy and test real backend code, in isolation ## Inside the system ### Knowledge as skills - 67 skills in 13 plugins, 62 of them mine: per repository, technology, process and operation. - Skills inherit: a repository skill pulls in its technology skills. - skill-discovery ranks them with BM25 and reloads when skill files change. ### A conductor, not one long context - 20 agent definitions, run as Define, Staff and Execute: investigate and clarify, give each agent its skill manifest, then build with forward flow and send-back. - Requirements and functionality reviews run in parallel, then flows review, testing and refinement. - Sub-agents start blank, so every spawn prompt carries its skills and constraints. ### Memory across sessions - Extends an open-source memory server (its core is not mine): a Claude-subscription provider and local embeddings, so no extra API keys. - A 16-tool MCP server and 6 lifecycle hooks: recall at session start, capture corrections, record failed commands that were later fixed. - A consolidation agent merges duplicates and promotes repeated lessons into skills. ### Safety rails - Hooks keep rm inside the workspace and block pushes to protected branches, with explicit flags that turn a deny into a question for a person. - Evidence grading: every bug an agent reports is marked confirmed (reproduced) or a conclusion (inferred). ### Parallel agents, real backends - Tooling on the open-source floci emulator (floci itself is not mine) gives each agent its own disposable copy of the AWS backend. - 15 template transform rules and 6 deploy profiles; 121 test files. ## Hard problems ### More knowledge than a prompt can hold **Problem.** Repository, technology and process knowledge for a large codebase is far more than an agent can carry in its prompt. **What I did.** - Split the knowledge into skills, with frontmatter and inheritance. - A BM25 skill-discovery MCP server with 5 tools, reading skills straight from disk. **Result.** Each agent loads the repository, technology and process skills its task needs, and nothing else. ### Several agents deploying at once **Problem.** Agents testing real backend code at the same time would collide in one shared cloud account. **What I did.** - One emulator container per agent, each with its own ports, caches and locks. - The real infrastructure templates rewritten to run locally: cloud-only networking removed, unsupported resources stubbed. - Three planes: real credentials only read templates; deploys and data use fake ones. **Result.** Several agents deploy and test on one laptop without touching the shared account. Built in about four weeks. ### Autonomy without accidents **Problem.** Agents with a shell in a monorepo of submodules can delete or push what they should not. **What I did.** - Pre-tool hooks deny rm outside the workspace, and pushes to protected branches, including by refspec, delete or mirror. - Escape hatches that turn a deny into a prompt for a person. **Result.** A destructive command needs a person, by default. ## Decisions - **Context:** chose on-demand skills, found by search, over one long system prompt. Agents start small and pull what the task needs; the catalogue can grow without crowding every session. - **Memory and emulation:** chose extend open-source projects, over write a memory server and an emulator from scratch. The cores exist and are maintained. The team needed the integration: subscription auth, hooks and per-agent isolation. - **Skill search:** chose bM25 keyword ranking, over an embedding index. Skill names and descriptions are short and specific, and keyword ranking needs no model to run. ## Outcomes - Adopted by the whole team at first; about 4 developers still use the original (owner-stated). - 20 agent definitions, 67 skills in 13 plugins, 3 MCP servers and 9 hooks. ## Limits - There is no retrieval-quality or productivity benchmark; the claims are about the architecture.