I spent three hours yesterday configuring a new agent. Not building it. Just configuring it. Defining the SOUL.md. Picking the right toolsets. Wiring up the skills. Setting the gateway channel. Getting the profile right. Again.
That was the fourth time I'd done it this month. Each agent took slightly longer than the last because the fleet had grown and I'd learned more. More tools to think about, more interaction patterns to consider, more footguns to avoid. The configuration surface area kept expanding faster than my ability to hand-craft each one.
So I stopped. I built a config pack.
The Problem
When you have two agents, hand-assembly is fine. You know both of them intimately. You remember exactly which skills Harbor has and which ones Ledger doesn't. Every configuration decision is deliberate and informed.
At five agents, it becomes a tax. At eight, it's a drain. You're not making creative decisions anymore. You're copying blocks of YAML from one profile to another, hoping you didn't miss the toolset that three other agents have but this one doesn't because nobody told you about it.
The real cost isn't the time. It's the inconsistency. Agent #7 doesn't have the logging skill because you forgot. Agent #4 has a different SOUL.md structure because you wrote it on a Tuesday when you were trying a new format. The fleet drifts. Standards slip. Bugs creep in through the configuration seams.
What a Config Pack Is
A config pack is a directory of template files that defines a complete agent personality, toolset, and behavior profile. It's not a framework or a DSL. It's just a set of files you copy and fill in. The innovation is deciding which files matter and what structure they should have, then standardizing on it.
A pack has four pieces:
-
SOUL.md template: the agent's identity, scope, behavioral rules, and operating principles. This is the hard part. A good SOUL.md is the difference between an agent that drifts and one that stays in its lane.
-
Skill set manifest: which skills the agent loads, in what order, with what priority. Not every agent needs every skill. A config pack makes the defaults explicit so you only override what you need to.
-
Toolset configuration: which tools the agent can reach: terminal, browser, web search, specific APIs, file system access. This is the security boundary and the capability boundary in one. Getting it wrong means either a neutered agent or an over-privileged one.
-
Profile structure: the config.yaml skeleton: model, provider, gateway settings, cron jobs, memory provider. The stuff that wires the agent into the infrastructure.
None of this is revolutionary. Template directories have existed since the first sysadmin got tired of typing the same Apache config twice. The value is in the curation: knowing which defaults work for a content agent versus a finance agent versus an operations agent, and encoding that knowledge into a package you can instantiate in 30 seconds.
How It Actually Works
The workflow is boring by design:
cp -r packs/content-agent quill/- Open SOUL.md, fill in the agent's specific scope and behavioral rules
- Adjust the skill set manifest: does this agent need the email skill? The trading skill?
- Set the toolset config: what can this agent actually touch?
- Wire up the gateway channel and cron schedule
- Deploy
That's it. Five minutes of customization on top of a proven foundation. The pack provides the guardrails. You provide the specifics.
The key insight is that 80% of agent configuration is the same across agents in the same class. Content agents all need web search, file system access, a gateway channel, and a strict publishing boundary. Finance agents all need market data sources, position tracking, and a no-execution safety rail. By encoding that 80% into a pack, you free up your brain to focus on the 20% that actually differentiates the agent.
What I Learned From the Fleet
Over eight agents and three months of production use, a few patterns hardened into rules:
Pack per agent class, not per agent. I don't have a "Harbor pack." I have a "coordinator pack" that Harbor and Mimir both inherit from. When I improve the coordinator pack, both agents get better. Packs are taxonomies, not one-offs.
The SOUL.md is the pack's contract. Everything else is implementation detail. If two agents have different SOUL.md structures, they're different classes even if they share every other file. The SOUL.md defines what the agent is. The rest defines what it can do.
Toolsets are the blast radius. A content agent with terminal access can accidentally delete the vault. A finance agent with the trading skill can accidentally execute a trade. Every tool you add expands the blast radius. The pack's toolset defaults should be the minimum viable set. Agents can request more, but they start constrained.
Skills decay. A skill that made sense in month one becomes irrelevant by month three. Config packs need maintenance. When you remove a skill from a pack, every agent that inherited it loses it on next deploy. This is a feature, not a bug. Centralized deprecation.
Over-configuration is the silent killer. The first version of the coordinator pack had 14 separate config files. By version three, it was down to four. Every config knob you add is a decision surface that can be wrong. The best config pack is the one with nothing to configure because the defaults are right.
The Simplest Thing That Works
Here's the thing about agent config packs: they're not a product. They're not a SaaS idea. They're not even clever.
They're just the thing you build after the third time you realize you're spending more time configuring agents than using them. They're the natural byproduct of running a fleet long enough to notice the patterns.
If you're running two agents, you don't need config packs. Keep hand-assembling. You'll learn more that way. If you're running five, you have enough data to design your first pack. If you're running eight, you should have built one three agents ago.
The threshold isn't a number. It's when you catch yourself saying "I know I configured this on the last one, let me just copy the file" for the third time. That's the signal. Listen to it.
Read next: AI Agent Handoffs Need Receipts and How My AI Agent Org Evolved as the Work Got Real.