Yesterday afternoon, an engineer on our team watched Anthropic walk through their internal GTM stack on the SaaStr stage, screenshotted the slide, and asked Zero a single question: which of these are we missing? Six hours and nineteen minutes later, Snowflake was live in production for every Zero customer. It was the 180-something integration we've shipped in a year, and increasingly, the person writing the next one isn't an engineer at all. Here's the framework, and the internal skill on top of it, that makes that possible.
The thing nobody tells you about agent platforms
An LLM is a brain in a jar. By itself, it can write you a poem about your data warehouse, but it can't actually open it. The thing that turns a chatbot into an agent, the thing your team actually pays for, is whether the agent can reach into the tools you already use and do work in them.
We call that reach the connector layer. After a year of building Zero, we believe it's the single most important piece of infrastructure in an agent product. So we built our own. More importantly, we built a workflow around it that lets anyone on the team author one.
Why not MCP. Why not Zapier.
Both got asked of us early. Both are good for what they are. Neither is what we needed.
MCP is a protocol, not a product. Brilliant for tool authors who want their service reachable by any LLM. But MCP servers, as deployed today, hand the model a list of tools and trust it to call them safely. There's no per-org credential vault, no firewall on which endpoints can be hit, no audit log that ties a call back to a human who authorized it. For a product where one agent might touch a customer's production Stripe and another might draft an email in their CEO's Gmail, "trust the model" is not a security model.
Zapier-style integration platforms solve a different problem: they wire deterministic triggers to deterministic actions. Agents don't work that way. An agent decides, mid-thought, that the next step is to query Snowflake and then write a Linear ticket. It needs a credential, a scoped HTTP client, and an audit trail right now, not as a pre-built recipe.
So we built the boring thing: a registry of integrations where each entry carries auth metadata, an environment mapping of which secrets get injected into the sandbox, a firewall of allowed hosts, and a small handler for OAuth or token quirks. That's the infrastructure.
But infrastructure isn't the interesting part of the story. The interesting part is what happened on top of it.
The skill that turned everyone into a connector author
A new SaaS lands in our integration backlog roughly twice a day. Some come from customer asks. Some from a teammate noticing Zero can't do something they need. Some from a BD conversation where a prospect's stack includes a tool we haven't met yet.
If every one of those had to go through an engineer's queue, we'd ship one a week. We ship one a day.
The reason is a piece of internal tooling we call the connector-authoring skill. It's a Zero skill, the same shape we ship to customers, but pointed inward at our own codebase. When anyone on the team says "I want to add the Notion connector," Zero walks them through it:
- Start from the user scenario. What does the user actually want to do with this tool? "Query a database," "create a page," "search across the workspace." The skill insists on a concrete user story before a single file is touched. The goal of a connector is to enable an agent capability, not to exhaustively wrap an API.
- Identify the auth shape. OAuth, API token, or both. The skill knows what each shape entails: for OAuth, the consent UI and redirect plumbing; for API tokens, the per-org secret injection and where the user gets the token. The author picks the shape that matches the tool; everything downstream falls out from there.
- Map endpoints to the scenario. Not "wrap the whole REST API." Just the handful of endpoints that satisfy the user story. A connector with three well-chosen endpoints beats one with forty the agent never reaches for.
- Scaffold the twelve files. Registry entry, handler, firewall pattern, platform icon, env-mapping plumbing, the agent-facing skill that teaches Zero how to use the connector. The skill writes the scaffold; the author writes the intent.
- Open the two PRs. One to the connector framework, one to the skill library. Both get reviewed by an engineer, but the review is about correctness, not about teaching the author how the framework works.
What used to require institutional knowledge (which auth shape, which endpoints, which twelve files in which two repos, how the firewall pattern composes with a dynamic subdomain) is now carried by the skill itself. The author brings the user empathy. The skill brings the scaffolding.
This is how a designer, a BD lead, or a PM ends up shipping a connector. They know what the user wants. The skill knows everything else.
The case study: Snowflake, yesterday
Yesterday Anthropic walked through their internal GTM stack on the SaaStr stage: Salesforce as system of record, Clay for enrichment, LeanData for routing, Gong for calls, Jira for tickets, Intercom (Fin) for support, Ironclad for contracts, Snowflake as the data warehouse. [link to the talk]
One of our engineers screenshotted the slide and dropped it into Zero with a single question: "which of these are we missing a connector for?"
Here's the actual timeline that followed. All times PDT.
16:59. The screenshot lands. Zero compares it against the connector catalog: 7 of the 10 already exist (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Three are missing (Clay, LeanData, Snowflake), and Snowflake is flagged as the most valuable, since a data warehouse is the GTM stack's foundation. Reply lands at 17:00.
17:01. Follow-up: "which of these can be done as an api-token connector?" Zero pulls the auth docs: Clay has a personal API key, Snowflake recently shipped Programmatic Access Tokens, LeanData is OAuth-only and Salesforce-bound. Verdict at 17:02: Snowflake first (highest value, cleanest auth), then Clay.
17:04. The engineer says "go." The connector-authoring skill picks it up. By 17:07 it has scoped Clay out (the only public surface is per-table webhooks, no real connector to build) and confirmed Snowflake's shape: SNOWFLAKE_PAT secret + SNOWFLAKE_ACCOUNT variable, bearer auth against the Snowflake REST API and SQL API v2, dynamic-subdomain firewall pattern modeled on Zendesk.
17:35. Both PRs open in the same minute:
vm0-skills#176: the agent-facing skill. How to write Snowflake SQL, format results, retry on transient errors.vm0#13356: the connector itself. Registry entry, PAT handler, firewall generator, platform icon, env-mapping plumbing.
18:22. Skill PR merged.
18:42. Connector PR merged.
18:52. Release PR auto-opens.
23:18. web@v12.369.0 and the rest of the release train deploy to production. Snowflake is live for every org.
Six hours and nineteen minutes from "screenshot of Anthropic's stack" to "Zero can query your warehouse." One engineer. One conversation. Zero hand-offs to a "connector team."
The throughput here isn't because the engineer is fast. It's because the connector-authoring skill carried the parts that used to require institutional knowledge: which auth shape to pick, which endpoints map to the user scenario, which twelve files need to land in which two repos, how the firewall pattern composes with a dynamic subdomain. The author wrote the intent. The skill wrote the scaffolding. Production did the rest.
This is what the framework buys us. Not just speed (though the speed is real), but who can take the work. The Snowflake author happened to be an engineer. He didn't have to be.
Why api-token is a first-class citizen
A footnote worth pulling out, because it's a deliberate design choice that surprised people.
Most agent platforms treat OAuth as the One True Auth and api-token as a fallback for legacy tools. We do the opposite. API tokens are a first-class citizen in our connector model, with the same consent UI, the same per-org vaulting, the same audit trail, the same firewall enforcement.
There are two reasons.
The first is that api-token auth has a shorter time-to-first-use. Snowflake recently shipped Programmatic Access Tokens for exactly this reason: long-lived, scopable, revocable credentials that don't require an OAuth dance. A user with a PAT can be productive in Zero in under a minute. An OAuth flow, even a clean one, takes longer and asks more of the user.
The second is that OAuth is not always available. Some enterprise tools simply don't ship one, or ship one that's gated behind an enterprise SKU. Treating api-token as a peer (not a fallback) means we can support those tools properly instead of leaving them in a "coming soon" graveyard.
The Snowflake connector that shipped yesterday is api-token. The Gmail connector that ships customer email threads is OAuth. Both go through the same framework, the same skill, the same review. The author picks the shape that matches the tool, and the framework makes either one cheap to build.
What 180-something integrations actually unlocks
The number itself isn't the point. The point is that at this density, the agent stops being a tool you summon and starts being an environment you live in.
When Zero has connectors to your CRM and your data warehouse and your support inbox and your design tool and your repo, it can do things no single-integration agent can do. It can pull a Snowflake query, cross-reference it against open Linear tickets, and post a summary in the Slack channel where the customer-success team lives. It can read a Gong call, find the feature the prospect asked about, check whether it's in the roadmap, and draft the follow-up email, all in one move.
Every new connector doesn't add value linearly. It adds value combinatorially. The 180th connector is more valuable than the 1st, because it composes with the 179 that came before it.
That's the bet behind the framework. And the bet behind the skill is that the speed of compounding depends on how many people on your team are allowed to add to the pile.
What's next
We're working on opening the connector-authoring skill to customers. If you're running Zero for your team and there's an internal tool you need an integration to (your billing system, your warehouse, your custom internal admin panel), the same workflow that shipped Snowflake yesterday will be the workflow you use to ship yours. Same scaffolding, same auth model, same firewall, same audit trail. Different author.
If that's interesting to you, we'd love to talk.
