Process Street runs a lot of our client delivery. It is where workflows, checklists, and onboarding live for several of the firms we work with. So when I started reading and writing Process Street programmatically, I treated the connection as a one-time wiring job: plug into the API, move on.

It was not a one-time job. We have reworked that connection through three stages, each one built on the one before it. Each stage solved a real problem the previous one could not, and the progression is the lesson.

Stage One: The MCP Server

Process Street already ships a connector for Claude. It is an MCP server: you add it from the customize panel in Claude Desktop, or wire it in as an MCP on Claude Code. I could not use it. It logs into one organization at a time, and I work across several client organizations at once, sometimes more than one inside a single session. North, our agent on the operations lane, does the same. A connector that can only hold one organization open is a non-starter when the whole reason you are connecting is to deliver across many. That single limit is what put me on this path.

So I rebuilt theirs. The connector is a Model Context Protocol server, and MCP is the clean answer to “how does an agent call this tool”: a server exposes the API as a set of tools, the agent points at it, and it can list workflows, read tasks, create runs. The rebuild did the one thing the shipped connector would not: it carried credentials for every client organization, so a single agent could move across all of them without logging out of one to reach another. Lincoln Bauduin at Process Street walked us through how to rebuild the connector to hold more than one organization, and that approach is what stage one became. It worked, and it taught me two things fast.

First, a connection has a cost even when it is idle. A server registered globally loads into every session the moment it opens, and each load reaches out to introduce itself and list its tools. Most of the sessions I open never touch Process Street. They are building a website, reviewing code, running research. Every one was still shaking hands with the Process Street server on startup. That connect traffic alone climbed into the tens of thousands of requests a day, none of it doing any actual work.

Second, we had no place to put control. The agent talked to the API more or less directly. We wanted per-client key handling, the ability to hand one agent read-only access and another full access, and a single choke point we could reason about. An MCP server gives you tools. It does not, by itself, give you a control plane.

Stage Two: The Gateway

So we built one. It sits between us and Process Street as a single service that every request flows through.

The gateway bought us three things the raw MCP could not.

A control plane. Every operation, all 149 of them, goes through one place. The MCP had already made multiple organizations reachable from one agent, but it kept every client’s keys within the agent’s reach. The gateway is where per-client credentials get attached to the right request instead, so an agent working on one client’s account never sees another client’s keys. The keys live in the gateway and never travel to the agent at all.

Capability tiers. We can issue an agent a credential that is physically read-only. Not a polite request to behave, but a credential the gateway refuses to write with, enforced on the server side before any request reaches Process Street. An agent doing a read-only audit gets a read-only credential and cannot mutate client data even if it tries. That boundary lives in the gateway, not in the agent’s good behavior.

Load on demand. Because the gateway is one service we control rather than a server baked into every session, we made it opt-in. Sessions that need Process Street load it. The thousands that do not, do not. The idle-connection tax went away. The gateway also gave us a command-line path that runs the same operations from a script or a scheduled job, which matters because a lot of our Process Street work runs unattended.

This is the version that taught us the difference between connecting a tool and operating one. The MCP connected the tool. The gateway let us operate it on our terms: who can do what, with which credentials, paying what cost.

Stage Three: The Plugin

The gateway was solid. The agents using it were not, consistently.

The tooling was right, but the knowledge of how to drive it correctly was scattered. It lived in a note here, a memory there, a comment in an old commit. An agent that happened to load the right note got it right. An agent that did not repeated a mistake someone had already solved.

The most expensive example was a pagination bug. One Process Street endpoint returns only the first twenty tasks of a workflow, and its “next page” link comes back empty, so a long workflow looks complete when it is not. I found it the slow way, mid-build, debugging in circles on a real client’s account. We filed it with Process Street. The fix on our side was a single rule: use a different endpoint that paginates correctly. But that rule was only useful if the next agent actually had it in hand.

So the third stage is not a new connection at all. It is a Claude Code plugin that packages the operating knowledge. It does not reimplement the gateway or the command-line path, it wraps them. With it loaded, an agent picks the right surface on the first try, lists a workflow’s tasks through the endpoint that actually works, and reads every known trap from one catalog instead of rediscovering it.

The part I am proudest of is the write path. When an agent hits a new wall, it logs the lesson into the plugin’s catalog in a fixed format, so the thing learned once is never learned again, by any agent. The pagination bug went in as the first entry. The plugin gets a little smarter every time it gets used.

The Actual Lesson

The tempting story is that we got it wrong twice and right the third time. The truer story is that each stage was the right move for what we knew at the time, and each one exposed the problem the next stage solved. The MCP proved the connection and surfaced the cost and control problems we did not know we had. The gateway answered those, and it is still the engine underneath everything. The plugin answers a problem only the gateway could expose: once the plumbing is solid, the bottleneck moves from “can the agent reach the tool” to “does the agent know how to use it well.”

Integration with a SaaS tool is a surface you keep shaping, not a wiring job you finish once. Each stage here was a response to a limit the previous stage made visible. You cannot see the control problem until the connection works, and you cannot see the knowledge problem until the control is solid.

We build our own infrastructure first so our clients inherit the conclusions instead of the detours. This is one of the detours, documented. The next time we wire an agent into a tool a client depends on, we will not assume it is done when the connection works. We will assume we are at stage one.

If you are wiring an agent into a tool your delivery depends on, that is the work we do at Varde Labs. Book a call and we will help you find which stage you are actually at.