From a General Agent to Explicit Capabilities

The situation

The first version of an agent often starts with a broad instruction such as "help the user manage this business" or "act like an experienced operator." That can work surprisingly well in a demo because the model fills in a lot of gaps. The problem appears when the same agent is expected to audit a website, draft outreach, inspect a customer record, prepare a proposal, update a CRM, analyse a support case, and make all of those behaviours consistent across different users and different days.

The naive solution

Keep expanding the system prompt. Add more rules, more examples, more edge cases, more tool descriptions, and more reminders about what the agent should do in each situation. When something goes wrong, add another paragraph to the prompt.

The hidden constraint

A giant prompt hides architecture inside prose. Different instructions start competing with each other, irrelevant context is loaded into every run, permissions become difficult to reason about, evaluation becomes vague, and nobody can answer a simple question such as "what exactly changed in the invoice-review capability last week?" The model may still perform well, but the business no longer has a manageable system.

The decision

Treat recurring capabilities as explicit skills. In this guide, a skill is a named package of behaviour with a clear purpose, inputs, instructions, allowed tools, required context, output expectations, failure conditions, and approval rules. The model still provides the reasoning, but the business defines the operating envelope.

The implementation

I would start by looking at repeated tasks rather than at prompts. If the agent repeatedly performs a recognisable job such as "qualify a lead", "analyse a support ticket", "prepare a website audit", or "draft a renewal summary", I would pull that behaviour into its own skill definition. The skill should be understandable without reading the entire agent implementation. I want to be able to describe what it does, what it can touch, what a successful result looks like, and when it must stop and ask for help.

The tradeoff

Explicit skills create more structure to maintain. There are more names, contracts, versions, tests, and routing decisions than there are in one universal prompt. I accept that overhead because it converts invisible behavioural complexity into something the team can operate deliberately.

The evidence I would look for

I would expect engineers and operators to be able to point to the exact skill responsible for a business behaviour. Failures should cluster around a capability I can improve independently, and changing one skill should not unexpectedly change unrelated agent behaviour.

The reusable lesson

When an agent repeatedly performs a recognisable job, make that job a first-class capability. The aim is not to make the model less intelligent; it is to make the surrounding business system more explicit.

The consultant's questions

• Which recurring agent behaviours are currently buried inside one large prompt?
• Can the team name the capability responsible when a particular workflow fails?
• Which instructions are being loaded on every run even though they only apply to one type of task?
• If I changed one business rule today, could I identify exactly which capability needs to change?