
Pipedream built something genuinely large: 3,000+ pre-built connectors, a low-code workflow builder alongside a pro-code SDK, and Connect — a real product for embedding agent tool-calling into a customer-facing product. It's not a small operation catching up on features; it's one of the broadest catalogs in this category, with 5,000+ customers before anything else changed.
Something did change, though, and it's the first thing worth understanding before comparing features: in November 2025, Workday signed a definitive agreement to acquire Pipedream, and the deal has since closed — Pipedream's team is now part of Workday, alongside Workday's other recent acquisitions (Sana, Flowise). This isn't a rumor anymore. It's the current state of the product, and it changes the actual question worth asking.
Workday's own language about the acquisition is explicit: Pipedream exists to connect "trusted HR and finance data" to more than 3,000 business applications, making Workday "the new front door for work." That's coherent for Workday. It's a different question for a team building an independent agent product with no relationship to HR or finance data.


Scalekit's bet is the opposite of Pipedream's breadth-first, workflow-automation heritage: authorization as the foundation, connectors built depth-first on top of it, and no larger corporate parent's roadmap sitting between your product and the infrastructure it depends on.
Where it directly answers Pipedream's biggest gaps: every tool call resolves a credential from an AES-256 encrypted, per-tenant vault, verifies scope against per-connector, per-org configuration before the call ever reaches the API — a primitive Pipedream doesn't have at all, regardless of the acquisition. And the roadmap answers to nobody's HR-and-finance platform strategy.
Virtual MCP Servers scope a single endpoint down to exactly the tools an agent role needs, with a fresh session token per run resolving to the right person's credentials — one definition serving every customer, not a workflow built per integration the way Pipedream's visual builder requires. This approach connects directly to how tool calling authentication for AI agents needs to work at production scale.
Where the trade-off runs the other way: Pipedream's 3,000+ connectors are six times Scalekit's 500+, and its low-code visual builder lowers the bar for less-technical team members to build integrations — Scalekit has no equivalent visual-builder path; everything runs through code and configuration. If raw catalog breadth or a non-engineer-friendly building experience is the binding constraint, that gap is real.
Observability: the full delegation chain — agent, connector, scope, tenant, action, result — logs natively and streams to your own SIEM or data warehouse.

Deployment: cloud-managed, VPC, or fully on-prem/air-gapped.

Developer experience: native adapters for LangChain, Google ADK, Anthropic, OpenAI, Vercel AI SDK, Mastra, Claude Managed Agents, and OpenClaw; per-user authenticated MCP URLs; one-command coding-agent plugin install via the Skills CLI.
"We can keep adding tools without ever rebuilding how credentials or tool calling work." — Venu Madhav Kattagoni, Head of Engineering, Von
Best fit: production agent products where per-tenant authorization, connector depth, and an independent, purpose-built roadmap matter more than raw catalog size or a visual-builder UX.

Where it beats Pipedream: time-to-first-tool-call — Composio's tools are built agent-native from the start rather than workflow-automation connectors repurposed for agents, and the SDK-only path is simpler than choosing between Pipedream's two paradigms.
Where Pipedream wins: raw catalog size (3,000+ vs. Composio's 1,000+) and the low-code visual option for less-technical builders, which Composio doesn't offer at all.
Neither solves: per-tenant authorization at the platform level — this is a gap shared by both, just for different architectural reasons.
Best fit: prototypes and single-tenant products where speed to a working integration matters more than governance depth or catalog breadth.

Where it beats Pipedream: the strongest observability story in this category (full request/response, OpenTelemetry export) against Pipedream's workflow-level rather than agent-native logging, plus full code ownership without Pipedream's two-paradigm complexity — one consistent code-first model instead of choosing between visual builder and SDK.
Where Pipedream wins: catalog breadth (3,000+ vs. Nango's 700+ APIs) and the low-code option for teams that don't want to write TypeScript functions for every integration.
Best fit: teams wanting full code ownership and strong observability, comfortable authoring integration logic themselves rather than using a visual builder.

Where it beats Pipedream: governance and DLP maturity — PII scanning, audit logs, per-tool-pack rules — plus enterprise compliance certifications (SOC 2, ISO, HIPAA, GDPR) that Pipedream's workflow-automation heritage doesn't foreground the same way.
Where Pipedream wins: raw catalog size by a wide margin (3,000+ vs. Merge's 220+) and broader category coverage beyond Merge's HRIS/ATS/CRM/ticketing focus.
Best fit: teams already invested in Merge's Unified API, layering on agent capabilities — prioritizing governance over Pipedream's breadth. For a deeper look at this option, see our Best Merge.dev Alternatives for AI Agent Connectivity breakdown.

Where it beats Pipedream: a more polished white-labeled end-user connection UX — a genuine strength for ISVs — and tool schemas without Pipedream's low-code/pro-code duality to navigate.
Where Pipedream wins: catalog size (3,000+ vs. Paragon's 1,000+) and a more mature workflow automation layer beyond simple tool calls.
Best fit: ISVs where end-user connection UX is a differentiator and pre-built tools cover the integration surface, without needing Pipedream's workflow breadth.
For teams evaluating all the options in this category, our Best Composio Alternatives for AI Agent Tool Calling guide covers overlapping platforms in more depth, including observability and governance trade-offs. Similarly, understanding how tool calling auth changes when you move from single-tenant to multi-tenant is essential context for any of these decisions. And if you're thinking about the deeper credential architecture, who holds the token across agent tool-calling patterns is worth reading before you commit to a platform.
The catalog Pipedream built is real, and 3,000+ connectors isn't a number to dismiss. The question worth asking honestly in 2026 isn't whether Pipedream's technology works — it's whether building a multi-year agent product on infrastructure whose roadmap now answers to a much larger company's HR-and-finance platform strategy is the foundation you want, versus a purpose-built platform with no larger parent's priorities sitting between you and what ships next.
For teams evaluating agent observability alongside tool-calling infrastructure, agent tool observability covers the patterns and failure modes that emerge in production. And for a broader view of the auth architecture that underpins all of this, the agent tool calling auth production patterns guide is a useful reference.