The Loadout Pattern: Handing the Wheel to an Autonomous LLM A developer introduced the loadout pattern, which inverts conventional LLM integration by letting an autonomous LLM drive a system on its own initiative. The pattern separates a toolbox (all available tools) from a loadout (the curated subset for a specific mission), enabling the model to decide which tools to use at each step. This approach shifts the system from executing fixed procedures to equipping the LLM as a 'suit' that the brain wears. Conventional automation executes a procedure — code runs a fixed sequence of steps and decides nothing; same input, same path, every time. The loadout pattern keeps the steps but moves the deciding to the model. At each step the brain — an autonomous LLM — judges : what matters, which tool to reach for, whether to act at all. It's handed a purpose and the latitude to pursue it, and it drives — choosing its own tools as it goes. Code executes; the brain decides. Those tools come as a loadout — a curated, self-describing set drawn from a shared toolbox — and the brain is observed at the interface it calls, not by the side effects it leaves behind. The model is the driver; your system is the suit it wears. Everything below is how to build that. Most LLM integrations bolt a model intoyour code. This is about the opposite: letting the modeldriveyour system — equipping itself, on its own initiative, with aloadout: the curated, self-describing set of tools it picks for each mission. The system stops being the program that calls an LLM, and becomes thesuitthe LLM wears. Audience: engineers building agentic/automation systems. There's code, and there's a bit of philosophy — because the philosophy is what makes the code shaped the way it is. Two words, kept distinct the whole post hinges on this : atoolbox or catalog iseverytool you own — the whole armory. Aloadoutis the curated subset a routine equipsfor one mission— what it actually suits up with. The entire MCP server is a toolbox; a loadout is the handful of tools one routine is handed at wake. In a typical LLM integration the model lives inside your process. Your code calls it: answer = agent.invoke {"input": "What changed in the market overnight?"} This is great for human-triggered work: a person asks, the system fetches and answers. The human is the caller; nothing happens until they show up. The LLM is a component — a function your program calls and pays per token to use. This post is about the other mode: the LLM doing the work on its own initiative. A routine wakes on a schedule and gets on with it — digesting overnight news every hour, posting a morning briefing, watching a queue, reconciling a ledger. No one asked; the routine is its own caller. Wake the model on a cron — say, a headless Claude Code session every hour — and it is no longer a component inside your program. It's outside , periodically taking the wheel and deciding what to do. The line that matters isn't human-vs-cron — and it isn't even steps-or-no-steps. It's executing versus deciding : a script runs its steps and decides nothing, while the brain — even when it That inversion changes what your system should be. Three layers, and it matters which is which: Here's the leverage that falls out of this: you don't hand-author JARVIS's intelligence. It comes from the model — and it improves when you swap in a better model, not when you write more code. What you build is the suit — what the brain can sense, remember, and do. So the central question of the whole system becomes: how do we equip the brain well — give it the right loadout — and let it reach for the right tool at the right moment? When you first wire a cron-woken routine, you write a prompt "skill" that mixes two very different things: the mission what to judge, the actual work and the mechanics raw curl , database queries, hardcoded IDs . A real before-state: news-digest skill before 1. Query Mongo for new headlines since the watermark: docker exec db mongosh app --eval 'db.news.find {publishedAt:{$gt: ...}} ...' 2. Decide which are new stories vs updates vs noise. ← the actual mission 3. Post the briefing: curl -X POST http://localhost:9000/notify -d '{"type":"SIGNAL", ...}' Then create a Notion page: data source id "