AI
The Personal Agentic Lab: 19 Agents, 73 MCP Tools
McMillin runs 19 agents daily from his home lab, 13 interactive and the rest cron-style service agents, backed by 73 MCP tools on a single local stdio server. Every agent gets a scoped subset of those tools, not the full list. Exposing all 73 to every agent wastes context and widens the attack surface. Tools are locked down by default; adding access requires an explicit grant. Max iterations per turn is capped at three or four, keeping costs predictable and preventing runaway sessions.
Automated Coding Pipelines and Human-in-the-Loop Tradeoffs
McMillin runs a cron job that fires a Claude Code command and pulls tasks from a custom task manager. When the queue empties, sub-agents spin up automatically, running security audits, test coverage checks, and code quality reviews, then generate new tasks.
“pretty much I have a kind of a self-sustaining code optimization ecosystem that will keep running until it maxes out my credit card and Claude uh cuts me off” — Brooks McMillin
That autonomy has a cost: less human in the loop. His hedge is weekly PR reviews and two Claude review bots that block automated commits until the code passes.
Capability Bounding: Scoping MCP Tools and Permissions Per Agent
Each of McMillin’s 19 agents gets an explicit allow-list of MCP tools and a permission tier — read, write, or admin — for each one. The task manager can search, message Slack, and send email. The security researcher agent gets read-only access to the RAG tools it needs. New tools land locked by default; you add them manually per agent. With 73 tools on the local stdio server, injecting the full list into every context wastes tokens and pulls agents off-task.
“that’s like a great example of how improved security also improves actual functionality” — Brooks McMillin
He demonstrated this in the permission denial demo: blocking memory write without write privileges (06:30): a chatbot running with read-only permissions tries to save memories, gets denied, and the error message is specific enough that the agent can explain exactly what permission it would need.
Agent Memory Isolation and Namespace Architecture
A flat Postgres table holding all agent memories sounds fine until your task manager starts citing a side-project goal, “optimize for $1,000 a month,” in unrelated planning sessions. That bleed led McMillin to key every memory entry to the agent’s class name, set at startup by the framework, not the LLM.
“LLMs have no control over what their namespace key is.” — Brooks McMillin
Memories scored below importance 8 stay out of context; agents search for them on demand. In the memory isolation demo: agent cannot read another agent’s namespace (12:52), the security agent’s lookup is caught by the LLM firewall before it reaches the namespace check, a tuning problem McMillin flags on the spot.
LLM Firewalls, Context-Aware Trimming, and Observability
The LLM firewall blocked a legitimate task, “include a server time field in every API response.” McMillin caught it two weeks later in the logs — along with a couple dozen others. Default sensitivity was too aggressive; security research queries will trigger it routinely. For log analysis, he added context-aware trimming (16:19): messages tagged as SSRF-blocked or permission-denied survive context pruning, so an attacker cannot bury activity by spacing events 200,000 tokens apart. Langfuse traces and Grafana dashboards cover the rest, catching accidental Opus usage and explaining overnight spend spikes.
“that’s like a great example of how improved security also improves actual functionality” — Brooks McMillin
Q&A
Are you looking for pull requests and changes, or is this just your personal project? Personal project only — he runs it with no pressure, and if he breaks it, he only affects himself. ▶ 19:51
You have one ever-expanding MCP server — is that a single boundary for all tools? Each agent spawns its own local stdio MCP server scoped to the tools and directories that agent is allowed to use, so it is not one shared boundary. ▶ 20:24
Have you thought about putting permission boundaries outside the context window using something like Envoy and OPA? He acknowledged the approach but said the setup is still immature — agents run on his desktop now, and he is actively migrating to K3s containers where he plans to add service-mesh controls. ▶ 21:31
Notable Quotes
pretty much I have a a kind of a self-sustaining code optimization ecosystem that will keep running until it maxes out my credit card and Claude uh cuts me off Brooks McMillin · ▶ 3:47
LLMs have no control over what their namespace key is Brooks McMillin · ▶ 12:27
that’s like a great example of how improved security also improves actual functionality Brooks McMillin · ▶ 18:21
other people might see it as a um implant Brooks McMillin · ▶ 9:58
Key Takeaways
- Scope every agent to only the MCP tools and permission levels it needs — least privilege cuts both attack surface and context pollution.
- Isolate agent memory to per-agent namespaces enforced outside LLM control; shared flat stores cause real cross-agent goal leakage.
- Deploy observability before you deploy agents — cost tracking and traces expose waste, model misconfigurations, and anomalous overnight spend.