DEV Community: quantoracledev

AgentKit vs LangChain vs Direct HTTP — picking the right integration for paid agent APIs

quantoracledev — Thu, 14 May 2026 01:24:30 +0000

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.

How to Give Your LangChain Agent Reliable Quant Finance Math (in 10 minutes)

quantoracledev — Mon, 20 Apr 2026 14:12:18 +0000

TL;DR

Large language models are great at reasoning about finance and noticeably unreliable at doing finance math. Ask an LLM to price an option and the price it returns can drift across runs. Ask for the Greeks and the higher-order ones (vanna, charm, speed) frequently come back wrong or inconsistent.

This is a known failure mode — and it's not specific to any particular model. The fix is standard engineering: call a dedicated calculator. This post walks through how to give any LangChain agent access to 73 deterministic quantitative finance endpoints (options pricing, Greeks, risk metrics, portfolio optimization, Monte Carlo, backtests, etc.) via one line of code. First 1,000 calls/day are free — no signup.

The problem in 30 seconds

# What you hope happens
response = llm.invoke("Price a European call: spot=100, strike=105, 6 months, 20% vol, 5% rate")
# "$4.58" ✓

# What actually happens in production
# - Price may land close, but drifts run-to-run
# - Delta, gamma, vega often reasonable; vanna, charm, speed, color frequently wrong
# - Numerics that depend on chained reasoning (IV solver, barrier options, path-dependent) degrade further

The math is deterministic. The model isn't. For anything agent-driven — backtests, risk management, paper trading, analysis pipelines — you need same-input-same-output calculations.

The fix: QuantOracle

QuantOracle is a REST API with 63 pure quant calculators plus 10 "composite" workflows (strategy backtests, portfolio rebalance plans, options strategy optimizers, hedging recommendations, full risk tearsheets). All citation-verified against Hull, Wilmott, Bailey & Lopez de Prado.

1,000 free calls/IP/day, no API key
Paid tier uses x402 micropayments in USDC on Base or Solana ($0.002–$0.10/call)
Deterministic: same inputs always produce the same outputs
MCP server, LangChain toolkit, OpenAI GPT, and plain REST all supported

Hook it into LangChain in one line

pip install langchain-quantoracle langchain-openai langchain

from langchain_quantoracle import QuantOracleToolkit
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate

# Load every QuantOracle tool — all 73 endpoints become LangChain tools
tools = QuantOracleToolkit().get_tools()

llm = ChatOpenAI(model="gpt-4o")
prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a quant analyst. Use QuantOracle tools for all financial math — never compute in-context."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

That's it. Your agent now has Black-Scholes, 22 portfolio risk metrics, Kelly sizing, 13 technical indicators, Monte Carlo, strategy backtests, and 60+ others.

Example 1: Price an option with Greeks

result = executor.invoke({
    "input": "Price a European call with spot=100, strike=105, 6 months to expiry, "
             "20% annualized vol, 5% risk-free. I want the price, delta, gamma, vega, and theta."
})

The agent picks the right tool (options_price), calls it, and returns:

Price: $4.58
Greeks:
  Delta: 0.4612
  Gamma: 0.0281
  Theta: -0.0211 (daily)
  Vega:  0.2808

These are the exact Black-Scholes values. Reproducible across runs.

Example 2: Full risk analysis from a returns series

result = executor.invoke({
    "input": "Here are daily returns: [0.01, -0.02, 0.03, 0.005, -0.01, 0.02, -0.015, 0.025, "
             "0.01, -0.005, 0.015]. Give me a complete risk breakdown."
})

The agent calls the risk_full-analysis composite (one API call that replaces 7 individual ones) and returns:

Risk Tearsheet (11 periods):
  Sharpe: 2.83
  Sortino: 4.59
  VaR (95%): -0.03
  Max Drawdown: -0.03
  Kelly leverage: 10.65x
  Hurst: 0.50 (neutral — random walk)
  CAGR: 122.98%

Same inputs always produce the same output. No drift, no hallucinations, no flaky Sharpe calculations.

Example 3: Backtest a strategy

result = executor.invoke({
    "input": "Backtest a 20/50 SMA crossover on this price series: "
             "[100, 101, 102, ...]. Initial capital $10000, 5 bps commission."
})

The agent calls backtest_strategy (a composite endpoint that replaces ~10 individual calls) and gets back: Sharpe ratio, Calmar, max drawdown, win rate, list of trades, equity curve, and a buy-and-hold benchmark comparison.

When to use composites vs individual calculators vs batch

The toolkit exposes three tiers of tools, each for a different situation:

Individual calculators (options_price, risk_portfolio, stats_hurst-exponent, ...) — fine-grained control, one concept per call. Free tier.
Composite workflows (backtest_strategy, portfolio_rebalance-plan, options_strategy-optimizer, hedging_recommend, risk_full-analysis, ...) — bundle 5–15 calculator calls into one round trip with a purpose-built output. Paid-only ($0.015–$0.10 each), but dramatically cheaper and faster than hand-chaining the pieces.
Batch endpoint (POST /v1/batch) — run up to 100 arbitrary calculator calls in a single HTTP request. Ideal for parameter sweeps, walk-forward backtests, or any workload where latency dominates cost. Price is the sum of the individual prices — no markup. First batch call per IP is free; subsequent batches are paid via x402.

Rule of thumb:

One calculation → individual calculator
Named workflow (risk analysis, backtest, hedge selection) → composite
Many small calculations at once → batch

A single backtest run that would be 200 HTTP calls one at a time becomes 2 batch calls. If your agent iterates, batch usually wins on both latency and cost.

Filter by category to keep tool lists small

A common LangChain pitfall: 73 tools in the prompt confuses smaller models. Filter by category:

# Options-only agent
tools = QuantOracleToolkit(categories=["options", "derivatives"]).get_tools()

# Risk/portfolio-only agent
tools = QuantOracleToolkit(categories=["risk", "portfolio", "stats"]).get_tools()

# Crypto-focused agent
tools = QuantOracleToolkit(categories=["crypto", "simulate"]).get_tools()

Available categories: options, derivatives, risk, indicators, simulate, portfolio, fixed-income, fi, stats, crypto, fx, macro, tvm, trade, pairs, backtest, hedging.

Past the free tier

After 1,000 calls/day (per IP), the API returns HTTP 402 with an x402 payment requirements header. If you're using an x402-capable HTTP client (e.g. AgentCash, Coinbase AgentKit), payments are automatic — USDC on Base or Solana, $0.002–$0.10 per call. Otherwise the toolkit raises an exception and you can add a payment layer yourself.

Why this matters for agentic systems

When an agent makes 50 tool calls during a backtest, every calculation has to be right. An LLM that's 85% accurate on Black-Scholes doesn't produce a backtest — it produces noise. Moving all math to a deterministic calculator means:

Reproducible results (your next run produces the same Sharpe)
Cacheable (you can memoize by input hash)
Auditable (you can replay any step)
Fast (sub-millisecond per calculation on the server)
Cheap (orders of magnitude less than equivalent LLM tokens)

This pattern — LLM for reasoning + deterministic APIs for compute — is the one thing that actually works for production agent systems. Pick it up now and you don't have to rebuild once your agent starts taking real actions.

Links

API docs: https://api.quantoracle.dev/docs
Tool discovery: https://api.quantoracle.dev/tools
x402 discovery (Base + Solana): https://api.quantoracle.dev/.well-known/x402
GitHub: https://github.com/QuantOracledev/quantoracle
Pypi: langchain-quantoracle
MCP server: npx quantoracle-mcp (npm)
OpenAI GPT: https://chatgpt.com/g/g-69d9c28bddb481918e674e2f9d9f3e97-quantoracle

Free tier is generous, no signup required, MIT licensed. If you're building an agent that touches financial math — options pricing, portfolio analytics, risk, backtests — try it before rolling your own.