A capability has three faces, and only one changes per vendor
A capability has three separate faces, and only one of them is different for every organization that installs it.
"How is this different from a custom chatbot integration?" is really a question about how much has to be rebuilt every time a capability moves to a new organization or a new vendor. Kav's answer is architectural: a capability is defined as three separate faces, and the split between them is the whole product.
Semantic — what the model reads
A summary, when to use it, when not to, disambiguation and multilingual synonyms. Identical for every organization that has this capability.
Contract — the input and output
A typed JSON Schema for what goes in and what comes out. Every prompt, eval, flow, rule and portal screen anywhere in the platform is written against this schema and nothing else — again, identical for every organization.
Execution — the only face that's yours
The connector instance, the specific operation, the request template and the response mapping to a specific vendor's system. This is the one face that changes when a city swaps its billing vendor, or a business swaps its CRM.
Why the split matters more than it sounds
Swap a vendor, and only the execution face changes. The prompts, the rules, the flow diagrams and the tests that were written against the contract stay exactly as they are — which is the actual difference between building forty products and building one.