December 5, 2025

Building integrations used to mean weeks of tedious data plumbing: implementing OAuth flows, writing custom code for each API endpoint, and wrestling with SDKs. We found a faster way using AI agents, curl, and a security-conscious architecture that keeps user credentials out of the LLM context window.

CW

Chris Wood

Founder of qckfx

The Problem

We’re building qckfx, a search tool for developers that queries across code, databases, and third-party services. Early on, we faced a classic chicken-and-egg problem: we needed integrations to get the product in front of users, but building hundreds of detailed integrations felt like months of work before we could even start iterating.

Our Approach: API Agents

Today, qckfx uses an AI coding agent SDK similar to Claude Code, developed in-house. Our architecture consists of a routing agent, a primary search agent, and specialized sub-agents for third-party integrations and code search. The sub-agents run in sandboxed E2B containers, where they use curl to query third-party APIs directly.

Why curl instead of SDKs? Two reasons. First, every SDK has its own patterns and conventions, and you’d need to teach the LLM each one individually. Second, many platforms have APIs but no SDK at all. Curl is universal: if there’s an API, the agent can call it.

When a user queries qckfx, the relevant sub-agent (powered by Claude Haiku 4.5) hits the third-party APIs, gathers information, and synthesizes an answer. Most queries complete in under two minutes.

Keeping OAuth Tokens Safe

Handing an OAuth token directly to an agent is a bad idea. It becomes part of the context window and gets sent to the LLM provider. Instead, we run a proxy server inside each E2B container. The agent makes requests to the proxy, which attaches the user’s OAuth token and forwards the request to the third-party API. The LLM never sees the token and is unaware it exists.

User OAuth tokens are stored encrypted at rest in our database and injected into the container at runtime during proxy setup.

Handling API Hallucinations

What happens when the agent hallucinates an endpoint that doesn’t exist? It gets an HTTP error and learns. If we see recurring mistakes, we add guidance to the system prompt. This feedback loop has proven effective—the agents get better at each integration over time.

We haven’t yet implemented runtime API spec fetching, though it’s possible. For now, we rely on the LLM’s existing knowledge of major APIs, supplemented with hints and examples in our prompts. This is a tradeoff: less setup work, but occasional hallucinations that require prompt tuning.

Agent-to-Agent Communication

When you have multiple agents working together, passing results between them efficiently gets tricky. Output token limits and context window constraints make naive approaches expensive. Here’s what we landed on:

1. While querying, the sub-agent writes progressive updates to a markdown file on the sandbox filesystem
2. When the sub-agent completes, control returns to the parent agent
3. The parent reads the sub-agent’s notes using its file-reading tools

The parent blocks until the sub-agent finishes, but we batch sub-agent calls so multiple integrations can run in parallel rather than serially.

This pattern has several advantages: it sidesteps output token limits, lets the sub-agent use the document as a thinking tool (revising and refining as it goes), and gives the parent control over how much context it pulls in. Our file_read tool supports line ranges, so the parent can skim or dive deep as needed. The file is also greppable, letting the parent search for specific information without reading the whole document.

Structured Output for Traditional Integration

Our use case is open-ended search with text output, but this architecture also supports structured responses. You can use structured output to build your own API interface on top of an API agent, bridging AI-driven integration with traditional code paths.

Results

API agents let us spin up integrations significantly faster than manual implementation. The longest part is now registration: setting up the app in the third-party developer portal, configuring OAuth scopes, and doing it twice for dev and prod environments.

Still, we built and deployed integrations with Google Sheets, Docs, Slides, and Drive (four integrations total) in under three hours. Having them all under the Google umbrella helped, but the pattern generalizes.

---

We’re continuing to iterate on this approach. Future work includes runtime API spec fetching and indexing for faster query response. If you’re building something similar, we’d love to hear about it.