Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ollybrinkman
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
ollybrinkman
7mo ago
The "experience as the real asset" point resonates deeply. I've been building agent orchestration systems and the difference between junior and senior use of AI tools is stark. Juniors prompt "build me X" and get fr
2.
▲
by
ollybrinkman
7mo ago
This maps directly to the shift happening in API design for agent-to-agent communication. Traditional API contracts assume a human reads docs and writes code once. But when agents are calling agents, the "contract" needs to be mac
3.
▲
by
ollybrinkman
7mo ago
We just tested our x402 payment infrastructure with real micropayments on Base L2. Replace API keys with pay-per-call. Agents send USDC on Base, gateway validates payment, proxies to backend, returns data. Tested $2.27 USDC across 50+ API c
4.
▲
by
ollybrinkman
7mo ago
The age of AI agents needs infrastructure to match. Right now, most agents are bottlenecked by API access — every integration requires a human to set up accounts, manage API keys, and handle billing. We're working on this at the infras
5.
▲
by
ollybrinkman
7mo ago
Interesting approach to security testing. One angle we've been exploring: what if the authentication layer itself was the guardrail? With x402, every API call requires a signed payment. No API keys to steal, no credentials to leak. The
6.
▲
by
ollybrinkman
7mo ago
This is a great approach. We built something complementary — Apiosk is an API gateway where AI agents pay per request using USDC on Base via x402. The idea is the same: use HTTP 402 as real payment infrastructure, not just a status code tha
7.
▲
by
ollybrinkman
7mo ago
Interesting to see budget enforcement paired with x402. We've been building in the same space — Apiosk ( https://apiosk.com ) approaches it from the server side: a gateway that enforces per-request x402 payments so API provid
8.
▲
by
ollybrinkman
7mo ago
Openness at the OS level matters less if the platform layer above it is closed. Even on Android you're dependent on Google Play Services for payments, push notifications, and maps — all closed. The real battle is at the API and payment
9.
▲
by
ollybrinkman
7mo ago
The deeper issue here is that centralized identity verification creates honeypots. You hand over real identity data to verify yourself, and now that data lives in LinkedIn's systems indefinitely. The alternative direction is zero-knowl
10.
▲
by
ollybrinkman
7mo ago
The challenge with layering on top of LLM agents is payment — agents need to call external tools and services, but most APIs still require accounts and API keys that agents can't manage. The x402 standard (HTTP 402 + EIP-712 USDC signa
11.
▲
by
ollybrinkman
7mo ago
The MCP ecosystem crystallizes this problem perfectly. When you connect an agent to an MCP server, you're not granting scopes — you're granting capabilities. Most MCP server implementations don't differentiate between 'l
12.
▲
Show HN: Apiosk – Self-service API marketplace with per-request USDC payments
(apiosk.com)
1 points
by
ollybrinkman
7mo ago
|
0 comments
13.
▲
Show HN: Apiosk – Pay-per-request API gateway with USDC (no API keys)
(apiosk.com)
1 points
by
ollybrinkman
7mo ago
|
0 comments
14.
▲
Replacing API keys with payments (HTTP 402 / x402)
(apiosk.com)
2 points
by
ollybrinkman
8mo ago
|
1 comments
15.
▲
by
ollybrinkman
8mo ago
Hi HN — I’m building a payment-native API gateway for AI agents and developers. API keys and subscriptions don’t work well for autonomous software: they require accounts, secrets, and prior trust before a single request can be made. This ga