The row that replaces nothing: how SharpOS connects a client's accounts without owning them

Open r/PPC or r/GoogleAnalytics on any given week and the same fight is running: an agency that "refuses to provide access" to the Google Ads account, a business owner who discovered the agency "took billing ownership of the account, even though I never gave permission", and the calm reply underneath from someone who has seen it too often — the business should own the account and the agency should sit inside it as a manager. Every client already has the accounts. The only real question is who holds them. In part 1 of this series I called Integrations the row on our replacement ledger that replaces nothing. This is that row, paid in full: what SharpOS connects to, why it deliberately owns none of it, how the connection layer is built, and the five providers it cannot listen to. If you build anything multi-tenant that has to act inside a customer's accounts, the owning-nothing part is the bit worth stealing. TL;DR: SharpOS connects a client's Google, Cal.com, Resend, WhatsApp, Facebook, ElevenLabs and model accounts so automations and agents can act through them. The accounts stay the client's, the tokens sit with a broker keyed to the client's organisation, and the workspace stores one row that says "connected, as whom". Why "replaces everything" is the wrong promise for this row The all-in-one pitch usually ends with a login count: one place for calendar, mail, messaging, forms, the lot. For most rows on our ledger that promise is honest, because the thing being replaced is a tool the engagement uses internally. Nobody outside the engagement cares whether the weekly queue lives in Trello or in Boards. Calendars, mail delivery, WhatsApp numbers and model accounts are different. They are shared with the rest of the client's business, they carry the client's history, and in the Google cases they are the accounts the client will fight an agency over. A workspace that "replaces" them has either rebuilt Google Calendar badly or quietly moved the client's accounts under its own name. The first is a waste. The second is the hostage situation the r/PPC threads describe, with better UI. So row 12 says connect, and it means it. The client keeps paying Google, Cal.com, Resend, Meta, ElevenLabs, OpenAI or OpenRouter. SharpOS gets a grant to act, scoped to one organisation, revocable from a card, and no more. Connect is a grant. Replace is a custody transfer. What Integrations does instead Integrations is one page in the hub, gated on the Integrations feature flag and on the manager role. Viewers and editors never see it. A manager connects a provider from a card grid: OAuth providers go through a hosted consent screen and come back to the same page; key-based providers (Resend, ElevenLabs, OpenAI, OpenRouter) take the key in a dialog. Once a provider is active, its actions and any triggers it has become available to three consumers at once: the Automations canvas, the REST API, and the MCP server agents use. Today the grid holds Google Calendar, Google Sheets, Google Search Console, Google Analytics, Google Ads, Google Maps, Reddit, Hashnode, Dev.to, Resend, Facebook Pages, WhatsApp, ElevenLabs and Cal.com, plus the four social providers that predate the shared catalogue (Instagram, X, LinkedIn, GitHub), plus an AI providers card for OpenAI and OpenRouter keys, and the org's own SharpOS API and MCP credentials. Meta Ads has its own read-only grant and belongs to the Ads surface, so I'll leave it there. You can walk through the page as a fictional client here: showcase → Integrations. Nothing you click leaves the browser. The feature page is at sharphaw.digital/features/integrations. How it works A broker holds the tokens, keyed to the organisation. Provider connections run through Composio as the credential broker. It custodies the OAuth tokens and API keys, and every connected account is keyed to exactly one organisation. SharpOS never stores a provider's OAuth token; it stores a connection record: which provider, which organisation, its status (connecting, active, invalid or revoked), and the account it runs as, so the card can show who it acts as. When an automation node runs, the backend loads the organisation's active connection and executes the provider action as that organisation, so there is no path from one org's workflow to another org's calendar. The one exception is the AI providers card. OpenAI and OpenRouter keys are stored in SharpOS, encrypted, because the backend runs inference itself and a broker that proxies actions cannot proxy a streaming chat. Status reads expose a yes/no and an account label; the raw key never leaves the backend. Bad keys never persist. Pasting an API key triggers one real call against the provider. If it fails, the broker account is deleted and the save is refused, so a wrong key cannot sit there marked active for a week. Triggers are connection-scoped, and some providers have none. Google Calendar triggers are subscribed at connect time and delivered to one signed webhook. Cal.com offers no triggers through the broker, so the connection mints an unguessable address and a signing secret, registers a single Cal webhook carrying all four booking events, and retries after 1, 5 and 30 minutes if registration fails. The connection stays active throughout; a flaky registration should never take the action nodes down with it. Every inbound delivery is verified, matched against an active connection before any event fires, and deduplicated for 30 days. A "calendar event created → create calendar event" workflow cannot ping-pong itself, because created ids are remembered and their echoes dropped. Agents get strict inputs. The REST and MCP surfaces for these providers use strict schemas: a misspelled field from an agent caller is rejected outright, never silently dropped. A DEV post this month told the story of an agent that "posted successfully. To the wrong account." The connection model above is our answer to the first half; strict inputs are the answer to the second. What it doesn't do Five providers cannot be listened to. Reddit, Search Console, Google Analytics, Google Ads and Google Maps expose no usable trigger, so "when X happens" is built the other way round: a schedule drives the query node and downstream steps branch on the result. Google Sheets has triggers in theory, but each one needs a spreadsheet id at subscription time, which a connect-time subscription cannot supply. Google Ads has no reporting here, and no proxy escape hatch either. X and LinkedIn are text-only through the broker. Google Analytics reports go through a request proxy because the toolkit only covers the admin API. Connect, disconnect and provider selection are hub operations, on purpose; there is no REST endpoint that connects a client's Google account on their behalf. And there is no marketplace. Twenty-odd providers, chosen because a SharpHaw engagement needs them, sitting on a broker that is a platform prerequisite. The fair objection is that I've moved the dependency rather than removed it, and that's true: if the broker vanished tomorrow, every connection would need re-consenting through whatever replaced it. The client's accounts, though, would be exactly where they were, and that is the property I care about. If your business needs three hundred connectors and a directory to browse, keep a general iPaaS. This layer exists so a client's automations and agents can act inside the accounts the client already owns, and it stops where that job stops. Where it sits in the SharpHaw service Integrations is the plumbing under AI Automations: a booking lands in Cal.com, a workflow reads the calendar, an email goes out through the client's Resend domain, a WhatsApp template confirms it. The client sees all of it in their own workspace, as every SharpHaw subscription includes SharpOS. What they never see is a request to hand over an account. The question I'd put to anyone building the same layer: where do you draw the line between what your product should connect to and what it should absorb, and has a customer ever disagreed with you about which side something belonged on? This is part of SharpOS, surface by surface. Part 1, the ledger and the decision behind it: We replaced a 12-tool client stack with one workspace we built.