You ask for a recruiting tracker. Nothing exotic: somewhere to hold applicants, a few hundred rows of sample data to try it on, and an answer to who is still active. The agent goes quiet for a while and comes back with the thing standing up. Look at what it actually did and there are four different doors. One protocol to look around the environment and read quickly. A command-line tool to create the project. A Python library to push the sample rows in. A query to pull the answer back out. You chose none of them, and you never learned their names. Your sentence had no tools in it. Neither did the reply.

You name the destination, not the route

A freight forwarder takes an instruction shaped like yours. Five hundred crates, Osaka, by the twelfth. Nobody asks you whether you would prefer sea or air, because that is not a question you are being paid to answer. The forwarder already knows that the long leg goes by ship if the date allows and by plane if it does not, that the last few kilometres are a truck either way, and that there is a clearance step in the middle no consignment gets to skip. Many carriers, one sentence from you.

A domain skill is written the same way. It carries the phases the domain actually has — find out what environment this is, authenticate, set up the project, change the schema, load data in bulk, ask a question of it — and, for each phase, which channel does that job well. Quick reads go over the protocol built for quick reads. Creating the project goes through the command line, which is where creation lives. Five hundred rows go through the SDK, because that is a loop and loops belong in code. The final answer goes through a query. The knowledge is stored as instructions and worked examples rather than wired into one product, so the same routing survives being carried to a different agent.

One carrier for every leg costs you

The instinctive mistake is to send everything by the same channel — usually the first one you set up, or the one whose output you find easiest to read. It rarely errors. It just charges you. A protocol that returns a single record in a blink is a poor way to push five hundred of them, and the command line that creates a project is a clumsy way to ask it a question. Cost, latency and what is even possible differ leg by leg, and a skill that ignores that is paying freight rates for a parcel.

The second mistake sits at the human end. If the person has to name the skill, or pass an internal flag, or know which module handles bulk loading, you have handed back the distance you meant to close. Discovery and routing are the skill’s job. That is also why the description at the top of a bundle is a routing rule and not a brochure — it should say when to use this and when not to, in words another model can act on.

The paperwork thins, the warehouse does not

Long jobs run out of room in the conversation well before they run out of work, and the fix is compaction: older history gets summarised so the session can keep going. Anything living only in the transcript thins out with it, which is why a skill that is really one long prompt degrades over an afternoon.

Layers are what save it. The procedures sit in the bundle, read only when the work calls for them. The execution state sits in a durable shell — a container that installs its dependencies once, keeps the files it made, and writes finished output to a handoff directory the next call picks up. That is the bonded warehouse: goods sit there between legs, and they are still there after the day’s paperwork has been condensed into one line. Only the conversation is what compaction is allowed to touch. Powerful routing deserves a matching narrowness elsewhere, so the network stays on an allowlist and the credentials stay out of the bundle.

Ask for the outcome. The skill is the short way from there to what has to happen.