

.png)
.png)

Every revenue team has the same problem: too much data, spread across too many systems, arriving too late to change what happens next.
Von was built to fix that. An AI-powered revenue intelligence platform, Von connects into the systems sales teams live in: Salesforce, Gong, HubSpot, Google Drive among many others. But it doesn't stop at surfacing what's there. Its agents reason across all of it and take action: flagging deals that have gone quiet, updating records after calls, putting the right context in front of a sales leader ten minutes before they need it.
It is a revenue operation where AI isn't a dashboard someone checks, but a teammate that's already done the work. That's a meaningful shift in how B2B software operates. And it turns out, building it requires solving an identity problem that most platforms never have to face.
Revenue intelligence at this level of depth touches a lot of things. For Von, it meant that identity couldn't be a single login flow bolted onto the front of the product. It had to be the connective tissue running through all of it.
Auth across a multi-tenant platform. Von serves multiple enterprise customers from a single platform. Every user belongs to an organization. Every organization has its own roles, its own access rules, its own audit requirements. The system has to know who's who, what they're allowed to do, and keep a record of what happened.
SSO that enterprise customers actually expect. As Von saw enterprise adoption, IT departments entered the picture. And IT departments run Okta, Entra ID, JumpCloud, Google Workspace SAML. They expect to configure SSO once and have it work, typically through a dedicated portal. Von needed every enterprise customer to be able to authenticate through their own identity provider, without having to spend time building SAML/OIDC.
A token vault that keeps agents connected. Von's agents act on behalf of users inside Salesforce, Gong, Google Drive, and more. That means holding OAuth credentials for all of those systems, for every user, and keeping them current. Salesforce, for instance, doesn't always return token expiry information in its OAuth response, which means waiting for a 401 to trigger a refresh is too late. Gong uses subdomain routing between its application and API layers. Google Drive scopes have to be explicitly configured or upload and download operations fail silently. Each provider has its own rules. The credentials can't live in agent runtime code. They need a home that manages them end to end.
Tool calling that flows through identity. Von's agents don't call Salesforce or Gong directly. Every tool call routes through a proxy layer that checks identity before anything executes. The agent requests an action, the proxy resolves who the user is, retrieves a scoped token from the vault, and forwards the call with only the access that user authorized. No blanket credentials, or service accounts with admin access, but a traceable, revocable token tied to exactly what that person agreed to share. The agent never holds credentials and never knows how authentication worked. It calls a tool, gets a result, and the identity layer absorbs everything in between.
.png)
The challenge wasn't building any one of these. It was building all four so that they stayed coherent with each other. A user's permissions should govern what their agent can touch. An expired token shouldn't surface as a failed tool call at 12:01 AM. Adding a new integration shouldn't require re-architecting how credentials are stored.
The answer was in finding one foundation that covers all of it.
Scalekit gave Von that foundation. Full-stack auth for users and organizations. Embedded SSO for enterprise customers. An agent auth layer with a centralized token vault and delegated access baked in. All of it on a single identity model.
That architectural choice didn't just clean up the code. It changed the pace at which Von could move.
When a new enterprise customer needed SAML through their Okta instance, the configuration slotted into the same model that already governed user access and agent delegation. It didn't require a separate integration.
When the integrations roadmap expanded through early 2026, adding Zendesk, Snowflake, Gmail thread tooling, Gong Engage, Salesloft, and Outlook Calendar, each new connector inherited the same token management pattern. The work was connecting the provider. The identity machinery was already there.
Consider what happens when a Von agent gets a task: surface everything relevant about a deal that a sales leader is walking into tomorrow.
The agent needs to pull the opportunity record from Salesforce, read the associated call recordings from Gong, check recent email threads, and cross-reference activity history. It's doing all of this on behalf of a specific person, inside systems that person is connected to, under the permissions that person was granted.
At the identity layer, that sequence requires four things to be true simultaneously. The credentials for each system have to be valid. They have to be scoped to what the user actually authorized, not a broad service account. They have to stay current without any human intervention. And the agent itself cannot hold any of them directly, because agents don't have login sessions and shouldn't have standing access to sensitive systems.
Von's architecture handles all of this through a clean separation. The agent requests what it needs. The identity layer retrieves a valid, scoped token for each system from the vault, refreshes anything that has aged, and surfaces only what the agent is authorized to use for that user in that moment. The agent executes. Nothing sensitive persists in the agent's context after the call completes.
This pattern holds whether Von is connecting to Salesforce, Gong, Google Drive, Zendesk, Snowflake, or any other system on the roadmap. Each provider has its own credential format, its own token lifecycle, its own authentication quirks. The agents don't know about any of that. They call a tool, they get a result, and the identity layer absorbs everything in between.
That separation is what makes it safe to run agents at scale across an enterprise customer base. And when those customers ask for evidence during security reviews — traceable sessions, auditable access, centralized credential management — the model produces it without anything being built specifically for compliance. It's just how the system was designed to work from the start.
.png)

.png)
.png)
