Building With the Claude Agent SDK and OpenAI Agents SDK: A TypeScript Developer's Guide to Integration Layers

Two of the most widely adopted ways to build production agents in TypeScript right now are Anthropic's Claude Agent SDK and OpenAI's Agents SDK. Both give you a working agent loop out of the box, both lean on typed schemas for defining tool inputs, and both save you from hand building the call the model, check for a tool request, run it, and feed the result back cycle that used to eat the first two weeks of every agent project. Where the two SDKs start to diverge is in how each one expects you to wire up the actual integrations your agent needs, whether that is Gmail, Slack, a CRM, or an internal company API. This guide walks through how tool definitions differ between the two SDKs, how to connect a programmable integration layer to each one, and what that means for a TypeScript developer trying to keep credentials, permissions, and tenant isolation consistent no matter which SDK the agent is built on.

How Claude Agent SDK and OpenAI Agents SDK Handle Tool Definitions Differently

At a glance, defining a custom tool feels almost identical in both SDKs. Both give you a helper function for creating a tool, both expect a name, a description, and a typed schema describing the input, and both hand the model a clear picture of what the tool does and when to use it. The real differences show up in how that tool gets registered and executed once it is defined.

Claude Agent SDK wraps every custom tool in what is essentially an integration server that runs inside your own application rather than as a separate process. This means a tool you write yourself and a tool coming from an external source speak the exact same protocol, so Claude sees them identically at call time regardless of where the logic actually lives. This design also means lifecycle control tends to run through a hooks system, letting you inspect or intervene before and after a tool call happens.

OpenAI Agents SDK takes a more direct route. Tools are attached straight onto an agent's list of available tools, without an intermediate wrapping step. This keeps the setup lightweight, and it pairs naturally with the SDK's other core idea, which is handing off a task from one specialized agent to another mid conversation. Instead of a hooks system, OpenAI Agents SDK leans on guardrails, which validate input or output around a tool call and can pause or redirect a run when something does not look right.

Both approaches give you strong typing on the arguments a tool receives, and both make the tool's description the single most important piece of context the model uses to decide when to reach for it. The practical difference for a developer building integrations is less about which SDK is better and more about which lifecycle primitives, hooks on one side, guardrails and handoffs on the other, your permission and approval logic needs to plug into.

Connecting a Programmable Integration Layer to the Claude Agent SDK

Because Claude Agent SDK treats custom tools as part of an in process integration server, connecting a programmable integration layer like Corsair becomes a matter of exposing each plugin as a tool inside that server rather than writing separate authentication and API logic for every provider by hand.

In practice, this means each tool your agent calls, whether it is sending a Slack message or reading a calendar event, delegates the actual work to Corsair behind the scenes. Corsair resolves which tenant the request belongs to, checks whether the requested action is allowed to run automatically or needs a human to approve it first, and only then makes the underlying API call. The tool itself stays thin, acting as a bridge between what Claude asks for and what Corsair actually executes.

The hooks system becomes a natural home for approval logic. A hook that runs immediately before a tool executes is a sensible place to check whether the action Claude is about to take needs review, mirroring the same permission modes Corsair already applies to each integration on its own. Because everything runs in the same process, tenant context can be resolved right at the moment a tool is called rather than cached earlier in the conversation, which matters for longer running sessions where stale credentials could otherwise slip through. Just as important, the raw token or API key never needs to appear anywhere in what the model actually sees. The tool handler talks to Corsair, gets back a clean result, and passes that along, keeping every credential out of the model's context entirely.

Connecting a Programmable Integration Layer to the OpenAI Agents SDK

The pattern looks a little different with OpenAI Agents SDK, mainly because there is no wrapping step before a tool becomes available to an agent. Tools live directly in the agent's configuration, so connecting Corsair here usually means calling into it from inside each tool's execution logic rather than through a separate server layer, although the SDK does support pointing at an external integration server if a team wants to share that layer across multiple agents or frameworks.

Tenant context matters even more here because of how OpenAI Agents SDK handles handoffs. A single task might move between several specialized agents before it finishes, so tenant identity needs to travel with the run itself rather than living in some shared state that could get crossed between requests. Passing tenant information through the same context object the SDK already provides keeps that boundary intact as a task changes hands.

Guardrails end up serving roughly the same purpose that hooks serve on the Claude Agent SDK side. A guardrail can check a tool's input before it runs and stop or redirect the process if the action looks like it needs a closer look, which lines up well with Corsair's own approval settings per integration. For teams supporting agents on both SDKs at once, it is worth asking whether integrations should be duplicated as separate tools for each framework or whether both can point back to the same underlying integration server, since keeping that logic in one place tends to save a meaningful amount of maintenance work as more integrations get added over time.

Both Claude Agent SDK and OpenAI Agents SDK give TypeScript developers a serious head start on the agent loop itself, but neither one was built to solve multi tenant credential isolation, permission enforcement, or the ongoing lifecycle of OAuth tokens on its own, and that is exactly the layer a team still has to bring themselves. Corsair fills that gap directly, an open source TypeScript integration layer that plugs into either SDK while keeping tenant isolation, permissions, and encrypted credential storage handled underneath. Whichever SDK your team builds on, or if you are supporting both at once, the integration layer beneath it should not force you to duplicate that logic twice. Corsair keeps that layer single and open source, no matter which agent framework is calling it.

Corsair.dev Read the docs →