Agentic Customization

Agentic Customization is weighted 4.1%, close behind Tool Implementation, and should produce two questions or so. It is the sub-skill about shaping an agent rather than building one: given a coding agent or an assistant that already works, how do you make it behave the way a particular team, repository or task requires?

The organising question is not what a customisation does but what triggers it. Some material is always present, because it lives in the standing instructions read at the start of every session. Some is fetched by the model when it judges the situation relevant. Some is invoked by a person on purpose. Some fires on an event whether anybody wanted it to or not. Four trigger types, and matching a requirement to the right one is what most questions here reduce to.

The pressure that makes this a genuine design problem is that always-present material is not free. Every instruction and every definition occupies the window on every request, competes for attention with the actual task, and is paid for again and again. A configuration that began as a helpful paragraph and grew into four pages of accumulated rules makes the agent worse at everything, and that failure never announces itself.

Customise by loading less, later, and on purpose.

What the exam tests here

• •Matching a requirement to a trigger type: always loaded, model invoked, user invoked or event driven
• •How a skill's short description acts as the trigger while its body loads only when needed
• •Subagents as a separate context and a separate capability set, not merely as a way to run things at once
• •Why standing instructions carry a recurring cost, and what genuinely belongs in them
• •Configuration scope, and which settings should be checked in for a team rather than kept personal

Four ways a capability gets pulled in

Sort every customisation by what causes it to be present. Standing instruction files are unconditional: read at the start, applied to everything, paid for on every request. Skills are model invoked, with a name and a one-line description sitting in context while the body loads only when the model judges the situation relevant. Commands a person types are user invoked, so nothing is spent until somebody asks. Hooks are event driven and run regardless of anybody's judgement.

The mapping is usually obvious once stated. A convention applying to every file in the repository is a standing instruction. A detailed procedure needed for one kind of task is a skill. A routine somebody runs deliberately is a command. A rule that must hold whether or not the model agrees is a hook.

Progressive disclosure is the whole trick

A skill is a folder holding instructions and, optionally, supporting files and scripts. Its metadata carries a name and a description, and in the ordinary case only that metadata is present; the instructions load when the description matches what is happening. That structure lets a repository carry a large body of specialised procedure at close to zero standing cost.

Two consequences follow. The description is load-bearing, since it is the only thing visible when the decision is made, so it should say when the skill applies rather than what it contains. And the body can be as long as the task genuinely warrants, because its cost falls only on the sessions that use it, which inverts the usual instinct to keep written guidance terse.

Subagents partition context and capability

Delegating to a subagent gives the work a fresh window, its own instructions and its own set of permitted tools, and returns a result rather than a transcript. Both halves matter. The context half means a task that reads a great deal and concludes a little, such as searching a large codebase or reviewing a long document, leaves none of its raw material behind in the parent.

The capability half is the one people miss. Because a subagent has its own tool allowlist, delegation is also a way to run a step with less authority than the parent holds: a reviewer that can read but not write, a researcher that can fetch but not execute. That makes it a least-privilege mechanism as much as a context one, and scenarios mentioning both bulk and a risky capability are usually pointing here.

Standing configuration is a recurring bill

An instruction file is read every session and consumes window on every request within it, so its content should be the small set of things true regardless of the task: how this repository is laid out, what the test command is, conventions applying everywhere, what must not be touched. Anything conditional belongs somewhere that loads conditionally.

Scope matters too. Configuration checked into the repository is shared, versioned and reviewable, which is what team conventions and project facts need. Configuration kept at the user level is personal preference and should not be imposed on colleagues. When a requirement says everyone working here must, it belongs in the repository; when it says I prefer, it does not, and mixing the two produces files nobody trusts.

Where candidates go wrong

Common questions