When you're plugging an LLM agent into an external API, you have three reasonable patterns: hand-rolled HTTP, AgentKit's action provider model, or LangChain's tool calling. They all work. They produce identical outputs against the same input.
So which one should you actually use?
I built the exact same agent three different ways — answering the same Kelly Criterion question — and the answer to "which one" depends on your stack, your team, and (most underrated) your wallet model. Here's the honest comparison.
The test case
Question: "I have a 55% win rate, $150 average win, $100 average loss. What's my Kelly fraction?"
Answer: f* = 17.5% (full Kelly), or 8.75% (half-Kelly — what most quant funds actually use).
The math doesn't care which integration computes it. Kelly is a 1956 formula that fits in a tweet:
f* = (p · b − q) / b
Where p = win probability, q = 1-p, b = avg_win/avg_loss.
What changes between integrations is everything around the math: how the agent discovers the tool, how it formats inputs, how it handles errors, and — for paid services — how it pays.
Pattern 1 — Direct HTTP
The minimum-viable integration:
curl -s -X POST https://api.quantoracle.dev/v1/risk/kelly \
-H "Content-Type: application/json" \
-d '{
"mode": "discrete",
"win_rate": 0.55,
"avg_win": 150,
"avg_loss": 100
}'
Response:
{
"full_kelly": 0.175,
"half_kelly": 0.0875,
"quarter_kelly": 0.0438,
"edge": 32.5,
"payoff_ratio": 1.5,
"recommended": "HALF_KELLY",
"ms": 8.2
}
Pros: zero dependencies. Zero auth setup (this API has a 1K-calls/day free tier). Works from any language. Easy to cache, easy to mock for tests.
Cons: you handle everything yourself. Schema validation, error retries, rate limit handling, payment if there are paid tiers. The LLM doesn't know about the endpoint — you're putting raw HTTP into your agent loop.
When this is right: you're building a deterministic backtest pipeline, a CI script, or any pre-prompted workflow where the agent doesn't need to discover tools at runtime. Or you're building a thin proxy that wraps a paid API for resale.
Pattern 2 — Coinbase AgentKit (TypeScript)
This is where it gets interesting if your agent has a wallet:
import { AgentKit, CdpEvmWalletProvider } from "@coinbase/agentkit";
import { quantoracleActionProvider } from "./quantoracle";
const walletProvider = await CdpEvmWalletProvider.configureWithWallet({
apiKeyId: process.env.CDP_API_KEY_ID!,
apiKeySecret: process.env.CDP_API_KEY_SECRET!,
networkId: "base-mainnet",
});
const agentkit = await AgentKit.from({
walletProvider,
actionProviders: [quantoracleActionProvider()],
});
// LLM picks `calculate_kelly` because the Zod schema's .describe()
// text matches "Kelly fraction" / "win rate" / "payoff"
const tools = await getLangChainTools(agentkit);
The LLM doesn't see raw HTTP. It sees an action called calculate_kelly with parameters documented via Zod schemas. AgentKit handles the network call and returns the parsed result.
The killer feature: the same agent can call paid endpoints (e.g. assess_portfolio_risk at $0.04 USDC) and AgentKit's wallet handles payment automatically via x402. The LLM doesn't write any payment code. No API key. No signup. No billing system. The wallet just needs USDC.
Pros: clean tool model for the LLM. Wallet-native payment (huge if you're building agents that need to pay other agents). Type-safe via TypeScript + Zod. Built-in tracing through LangChain.
Cons: TypeScript-only as of today. Adds the @coinbase/agentkit dependency tree. Wallet provisioning is one more thing to set up (though CdpEvmWalletProvider.configureWithWallet is basically two env vars).
When this is right: Coinbase-stack agents, x402-native agents, EVM or Solana wallets, autonomous trading bots that need to pay for premium tools, anything where wallet-native auth is the natural model.
Pattern 3 — LangChain (Python)
For when you're in the Python ecosystem and want broad tool access:
from langchain_quantoracle import QuantOracleToolkit
from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
# All 73 tools from this API (63 calculators + 10 composites)
tools = QuantOracleToolkit().get_tools()
# Or filter
tools = QuantOracleToolkit(categories=["risk", "stats"]).get_tools()
llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_messages([
("system", "Use the provided tools for any math."),
("human", "{input}"),
("placeholder", "{agent_scratchpad}"),
])
agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
response = executor.invoke({
"input": "I have 55% win rate, $150 avg win, $100 avg loss — Kelly?"
})
LangChain's toolkit pattern is the established way to give an agent a curated set of tools. Pydantic schemas describe each tool to the LLM. The toolkit handles HTTP, retries, and error wrapping.
Pros: Python-native (huge for the quant + ML crowd). Composes with LangGraph for stateful workflows. Works with any LangChain-compatible LLM (OpenAI, Anthropic, local Llama, etc.). Exposes all 73 endpoints by default — useful when you don't want to pre-curate.
Cons: no native wallet integration — if you want paid endpoints, you handle x402 separately. The breadth (73 tools) can confuse smaller LLMs that aren't great at narrowing from many options.
When this is right: Python-native pipelines, multi-tool agents (combining this API with web search, file ops, vector DBs), LangGraph workflows, anywhere you want broad tool access without curating a subset.
The decision rule
| Your situation | Use |
|---|---|
| Scripts / backtests / CI | Direct HTTP |
| Building on Coinbase / x402 / CDP wallets | AgentKit |
| Python, LangChain, or LangGraph workflows | LangChain Python |
| OpenAI custom GPT | GPT Actions (a 4th path I didn't cover here) |
| MCP client (Claude Desktop, Cursor) | MCP server (a 5th path) |
| Solana ecosystem, want sub-second x402 settlement | AgentKit with SolanaKeypairWalletProvider
|
All paths hit the same underlying API. The math is byte-identical across integrations for the same inputs. Pick by ergonomics and wallet model, not by capability.
Two patterns from production that combine these
These aren't mutually exclusive. In real systems you'll often use more than one:
Backtest in Python, deploy in TypeScript
You develop your strategy in a Jupyter notebook with langchain-quantoracle (all 73 tools available, easy to explore). When you find an edge worth productionizing, you re-implement the agent in TypeScript with AgentKit (curated 5-tool subset, wallet-native payments). Same API answers both. Your research notebook and your production agent agree because they're hitting the same engine.
Free tier for research, paid for production
The free tier (1K calls/IP/day) covers backtests across thousands of historical days. Once you've validated the strategy and want it running 24/7 as a paid signal service, you switch to the AgentKit + x402 pattern so the wallet pays per call. The economics scale linearly with usage instead of forcing a subscription decision.
What this isn't about
This isn't about which framework is "better." All three are excellent. AgentKit's wallet integration is unique value if you need x402; LangChain's tool ecosystem is unique value if you're orchestrating many tools; raw HTTP is unique value when you want maximum control.
It's also not about quant finance specifically. The same decision rule applies to any external API your agent might use — weather, web search, on-chain data, image generation. The frameworks differ in how they help your agent discover and pay for tools, not in what those tools can do.
My pick — and why
If I had to start from zero today:
- Python team, no wallet → LangChain. Most flexible. Most existing tools.
- TypeScript team with crypto-native agents → AgentKit. The wallet-paid x402 flow is genuinely magical when you have it working.
- Mixed team or no strong preference → start with direct HTTP for the first integration, then add a framework when you have a second one. The HTTP version is your reference implementation either way.
The wrong move is "framework first, problem second." All three integrations work because the underlying API is well-designed. The framework is a thin layer on top. Pick the thin layer that matches the rest of your stack.
The QuantOracle API (the one I used for these examples) is at quantoracle.dev — free tier of 1,000 calls per IP per day, no signup. All three integration paths are documented at the repo.
The AgentKit action provider files are here. The Python LangChain toolkit is pip install langchain-quantoracle. The OpenAPI spec for the direct HTTP path is at api.quantoracle.dev/openapi.json.
What integration pattern are you using for your agent? Always curious how others land on the trade-off.
Top comments (0)