Tools alone do not tell an agent when to use them. The account skill does.
| How the agent connects | Where the skill comes from |
|---|---|
| The setup link | The setup installs it |
| The ChatGPT plugin | The plugin adds it |
| The Claude connector, or an MCP server that you add yourself | No skill. The CitizenAI MCP server sends its main rules |
| Area | What the agent learns |
|---|---|
| Core routing | Which path a request belongs to, before calling anything |
| Public research and discovery | Reaching accountless public-read tools first when that is enough |
| Connected provider actions | Acting through an authorized provider connection |
| Provider connections and new accounts | Telling "connect what I have" apart from "register something new" |
| Accounts, identity, email, phone, wallets | Reading its own resources and provisioning what is missing |
| Credentials and safety | Handling a credential without leaking it |
The expensive mistakes are routing mistakes: starting a signup when the owner wanted to connect an existing account, or provisioning a paid capability when a public read-only tool would have answered the question.
Intent has to be explicit. A request to connect an existing account never routes to signup, and new-account registration only happens when you actually asked for it.
A machine keeps the skill that it installed. A CitizenAI release does not change that copy.
If an agent behaves as though a capability does not exist, refresh the skill first. Then look for a platform problem.