When SaaS Products Onboard Agents

This week, Resend announced an official Claude Code plugin. At first glance, that sounds like a small product update. Another plugin. Another integration point. Another changelog entry you skim once and then forget.

You probably should not.

The interesting part is not Resend. The interesting part is the package format. Resend is not just shipping an API, an SDK, or documentation. The plugin bundles an MCP server, Resend skills, React Email context, best practices for SPF, DKIM, DMARC, and deliverability, a skill for agent handling of inbound email, and CLI support.

In other words: Resend is no longer just onboarding developers. Resend is onboarding the agent.

The same pattern is now visible in several places across the Claude plugin directory. Vercel gives Claude Code access to deployments, logs, domains, and environment variables. Supabase offers SQL, migrations, TypeScript types, logs, and Edge Functions as an agent workflow. Figma provides design context, tokens, component information, and Code Connect mappings. GitHub connects issues, pull requests, actions, releases, and security findings to the agent.

This is more than a more convenient API integration.

APIs were interfaces for machines. Documentation was the interface for humans. Plugins and skills are becoming the interface for agents.

That shifts an old power question. SaaS vendors used to compete over which API developers would integrate first. Then over which SDK would land in the stack. Then over whose documentation would show up in Google or Stack Overflow. Now a new layer is emerging: which action model does the agent receive when someone says, “Deploy this,” “review the PR,” “build the template,” or “set up the database”?

That sounds abstract. It is not.

An agent that has learned Vercel as the default deployment path will behave differently from an agent that first has to infer the right move from project context, infrastructure rules, and existing scripts. An agent with Resend best practices built in will build email differently from one that pieces together general advice from the web. An agent that can pull Figma tokens directly will have a different sense of design consistency than one interpreting a screenshot.

That is the upside. Less friction. Less context loss. Less random implementation.

But of course there is a bill.

Whoever provides the skill provides more than access. They provide framing. The agent does not learn “how email works” in some neutral sense. It learns “how email works with Resend.” It does not learn “how frontend deployment works” in general. It learns a preferred path through Vercel. That is not automatically bad. Defaults are useful. Without defaults, most systems never get used.

But defaults are never innocent.

This is app-store logic, only deeper in the work process. Not: which app do I install? But: which operational habit does my agent come with? Whoever owns that layer does not just sit inside the tooling. They sit inside the decision flow.

For companies, that gets uncomfortable. On paper, it sounds perfectly rational to equip agents with the best official plugins. In practice, it creates a new shadow standard. Teams install a plugin because it saves work. More prompts then follow that path. Processes get built around that path. And eventually, switching is no longer just a tool change. It means changing learned behavior.

Lock-in rarely starts with one big contract. More often, it starts with convenience that becomes a little more plausible every day.

So the question for AI transformation is not: “Which plugins exist?” The better question is: “Which defaults are our agents allowed to have?”

Because once agents start doing operational work, their context is no longer a documentation appendix. It is process architecture.

And process architecture is not something you should hand over completely to the vendor. At least not if you are paying attention. It is convenient, though. Which is exactly why it will happen.