Lesson 22.622.6 What travels: your skills, connectors and plugins

Part B. Bringing the plugin and the connector. Three concepts, then Sitting 2, where the worker gets its skill, its connector and one open network door.

In everyday life. A consultant moving from one client's office to another packs her laptop, her notebooks and her phone list. She does not pack the office's door badge, its printer settings or the sign on her old desk. Some things are hers and travel. Others belonged to the room. In this concept, her notebooks and phone list are your skills and connector, and the badge and printer settings are commands and hooks.

What you will learn. Which parts of the plugin you built in Chapters 16 to 19 a hosted worker can use as they are, which parts stay behind, and where a check that stayed behind must move.

Why it matters. A check that ran on your laptop does not run on someone else's servers. If it was the only thing stopping a harmful tool, the hosted worker has no such stop until you move it.

One request, start to finish. Chapter 16's plugin holds an invoice-triage skill, the Monday report a person starts by name as /ap-triage, and the plugin's manifest. The project's settings file never lets the coding agent edit data/, and since Chapter 17 it allows the connector's four tools by name. Chapters 17 to 19 added the connector. The builder asks what the hosted worker can take:

1. The skill travels. It is a folder with a SKILL.md file, written to the Agent Skills open standard (Chapter 16), and the platform loads it into each session.
2. The connector travels. It is declared by its address, https://ap.brightline.example/mcp in production (https://ap-staging.brightline.example/mcp in the lab's staging), and the session calls it over MCP, exactly as the coding agents did.
3. The command does not travel. A command is something a person starts by name in a coding agent, as /ap-triage is. In the portal, the person's question is the start.
4. The settings file does not travel. It told the coding agent on the builder's laptop which tools it may run, and what it may never edit. In the hosted worker, there is no laptop.
5. The manifest does not travel. It told a coding agent how to install the bundle. This hosted worker takes no bundle, and is configured by its definition instead.

Why does what you built in Chapters 16 to 19 still work?

Nothing in Chapters 16 to 19 was built for one coding agent only. The skill is a folder written to the Agent Skills open standard, and the connector is a server that speaks MCP at one address. Every runtime in this chapter can load a skill and call an MCP connector, so the hosted worker uses them as they are: the same SKILL.md, the same four tools, the same sign-in checks, the same database rules. What changes from runtime to runtime is how you attach them and how the person's token reaches the connector, not the skill or the connector themselves. This is why the book built to open standards from the start. A skill or connector you build once serves a coding agent on your laptop, the AI apps people chat in, and a hosted worker inside a customer's own product. For a builder who sells skills and connectors, a hosted agent is one more place they are worth something.

What travels, and what stays behind?

A hosted worker takes the parts of a plugin that are defined by an open standard and meant to run anywhere: skills, written to Agent Skills, and connectors, which speak MCP. On some runtimes you can hand over the whole plugin bundle, and the runtime loads its skills and its connector settings from it. On others you add each skill and each connector to the agent definition yourself. Either way, the same files are used. Some parts do not travel, because they belong to one AI app's way of working: commands, hooks and settings files. Where a runtime does not load the whole bundle, the plugin's own manifest stays behind too. This matters most for the settings file. If its list of four allowed tools was the only thing that stopped any other tool, then the hosted worker has no such stop. That check now has to live somewhere that does travel: in the permission policy for each tool (22.8), or in the connector itself, which in this book has no write tools at all. The same is true of Lab 21's callback that decided flag_invoice, and of a hook that logged each call (21.5): both were your code, running in your own process. A hosted worker has no process of yours to run them in.

And Chapter 21's own tool?

flag_invoice, Lab 21's one tool with an effect, which holds an invoice's payment, was a function in your own program (21.4), so it does not travel either. A hosted platform can offer a tool like it as a custom tool: the platform never runs it, the session pauses and hands each call to your product, and your product runs it and sends back the result. It is the approval shape again: the run pauses, and your code answers the call. The hosted AP worker leaves flag_invoice out for now, so it has only read tools. A tool with an effect needs a record of who approved what, and Chapter 24 builds one, on an approvals table.

How do you choose tools on a connector?

A connector's server lists its tools, and its operator may add more later. A hosted worker should turn on only the tools it needs, by name, and leave the rest off. Then a fifth tool that appears on the server next month stays off until someone reviews it. The lab turns on exactly four: find_vendor, list_open_invoices, get_purchase_order and search_policy.

What happens to a very large tool result?

A tool result can be too large to hand to the model whole, such as an export of every invoice for a year. Some platforms write a result over a set size to a file in the session's sandbox, and give the model a short preview and the file's path. The model can then read the parts it needs with its file tools. The lab's tools return pages (Chapter 17), so this rarely happens, but a worker's file tools must be on for it to work.

At work. In Lab 22, Task 5, Claude Code uploads skills/invoice-triage/ as a skill and attaches it to agents/ap-worker.md. In Task 6, it declares the connector by its staging address and turns on only the four read tools. The builder asks: "What did the settings file allow, and where does that check live now?" Claude Code answers: it allowed the connector's four tools, by name. The agent definition now turns on only those four tools by name, so a new one cannot run until it is reviewed.

The operating rule: reuse your skills and connectors unchanged, and load the whole plugin where the runtime can. Move every check a hook or a settings file made into a policy or the connector.

Figure 22.10. Skills and connectors travel. Commands, settings files and the manifest stay with the host they were made for.