Connections

A business does not live inside one app. Books are sold on a store, pins are posted to Pinterest, ads run on an advertising platform, documents sit in a drive, images come from a generation service, performance numbers come from a dozen dashboards. Connections are how WilsonOS reaches all of that — and the rules around them are what make it safe to let an agent act out there on your behalf.

What a connection is

A connection is a named link to an external system, reached through an API, a connector protocol, or a command-line tool. Each one declares:

Property	Meaning
Account scope	Which account, and for which brand(s). A Pinterest connection for Code Pineapple is not RiseBlox’s.
Permissions	What the granted credential allows on the other side.
Reads	What the system can pull: performance, listings, comments, files.
Actions	What the system can do: publish, schedule, upload, send.

Connections are catalogued with these properties, so “what can Scout actually do on Pinterest?” has a written answer.

Kinds of connections

• Publishing platforms — where approved work goes out: Pinterest, video platforms, a store listing, email. Publishing records the external identifier that comes back, so results can be matched to what shipped.
• Advertising accounts — read performance, and act on campaigns through the channel engine’s proposals.
• Generation providers — image, video, voice. Reached only through the media door.
• Workspace tools — documents, calendars, mail, spreadsheets — for reading briefs, sending deliverables, and scheduling.
• Research and analytics — keyword and audience research, competitor discovery, channel statistics.

Two rules that make agents safe out there

Same operations, two interfaces. A person clicks Publish; an agent calls a tool. Both use the same underlying service and the same permission checks. Exposing an operation to agents never creates a second, weaker path.

One door per capability, and the key stays behind it. An agent’s runtime never holds a provider’s real credential. It calls a gateway with a short-lived, scoped credential of its own; the gateway checks the scope, injects the real key, makes the call, and logs it against the run in flight. If a provider is not routed through a gateway, a scheduled run must name it explicitly in its scope — there is no “inherit everything from the machine”.

Why routing is prescribed

An audit of ad-hoc scripts in the pipeline found a large fraction calling provider APIs directly, bypassing the catalogue. Every one of those was a render with no receipt, a post with no recorded identifier, or a cost nobody could attribute. Prescribed routing is what keeps the picture complete.

Adding a connection

Adding a connection is configuration plus a catalogue entry: the account, the scope, the reads and actions it supports, and which gateway routes it. It does not change the work loop, and it does not automatically create production records — a new data source goes through the four-step intake in Extending WilsonOS before its data is trusted.

What a connection is not

• Not a source of truth. A connector exposes operations and data; the registry and the brand’s records remain canonical.
• Not a licence. A connection with publish rights still publishes only a version a person approved.
• Not brand-blind. Every action carries the brand it was taken for; a connection scoped to one brand cannot be used for another.

live The connection catalogue, the media and provider gateways, scoped credentials for runtimes and scheduled runs, and recorded external identifiers on publish are live. direction Per-brand enforcement at the gateway (today brand is logged on every call, not yet refused) is scheduled.

Related

Media generationThe best-developed example of a gateway.

Artifacts & publishingWhat happens when an approved version goes out.

How agents runWhy a runtime never sees a real key.

FoundationsConnections as one of the three planes.