Launched this week
AgentKey
One-stop live data marketplace for your agent
1.1K followers
One-stop live data marketplace for your agent
1.1K followers
AgentKey is a plugin that connects your agent to live external data in one command. Install it into Claude Code, Codex, OpenClaw, or any MCP-based agent and instantly unlock access to search, web pages, social platforms, finance, e-commerce, business and crypto data. No integrations. No setup. Auto failover keeps workflows running.
AgentKey
Makes sense — the pooled balance and QoS shaping clearly need the proxy server-side, and provenance staying in the transcript is exactly what keeps it auditable for me. Follow-up: is local mode with my own upstream keys on the roadmap at all, or is the server-side pool load-bearing enough that hosted-only is the long-term shape?
AgentKey
@noctis06 Yeah, this has come up a few times now, so we're looking at it.
The pool works well and the providers behind it are solid, so hosted isn't going anywhere as the default. But we've heard enough people say they already pay for some of these APIs and would rather bring their own key for those. Fair ask. Likely lands as a per-provider override, so you keep the routing and failover either way.
Per-provider override is the right call - keeping routing and failover while letting me bring a key for the providers I already pay for is the best of both. Two things I would want to know before wiring it in: if my own key hits a rate limit or 5xx, does failover fall back to the hosted pool for that provider automatically, or does a BYO provider opt out of the pool entirely? And does spend on my own key still surface in the same unified usage view, or split into separate billing I have to reconcile myself?
@yanshuo The "agent can reason and act but can't see the live internet" framing is a sharper way to put this than I've seen elsewhere most of the pain in wiring agents to real tools isn't the reasoning, it's exactly the plumbing you're describing: five providers, five auth schemes, five failure modes to handle separately.
The part I'd actually push on: once there are 20+ capabilities behind one marketplace, and the agent is choosing between several plausible tools for a given task, what happens when it picks a plausible-but-wrong one? Not a crash, just a confidently wrong choice that still returns a result. Is that visible anywhere today, or does it just look like a normal successful call downstream? That's usually where these marketplace-of-tools systems get hard, once the agent is choosing on your behalf instead of you wiring the one specific tool you already knew you wanted.
Hey the token math on tool discovery is honestly the most concrete detail in the whole pitch. Going from roughly 35,000 tokens to about 1,500 by training a retrieval layer instead of dumping every endpoint definition into context is a real architecture decision, not just a marketing line, and it's the kind of problem that quietly breaks a lot of MCP integrations once they scale past a handful of tools for sure.
But when the retrieval model picks the wrong endpoint for an ambiguous request, is that visible anywhere, or does a wrong pick just look like a silent bad result downstream?
AgentKey
@uddipta Silent wrong pick is exactly the failure mode that matters, so honest answer: the retrieval layer never executes anything on its own. It returns a shortlist of candidates with descriptions into the agent's context, the agent picks one, pulls the full schema for that tool, then calls it. Ambiguity usually shows up as a weird shortlist in the transcript, not a hidden wrong hop, and the agent can just re query with better phrasing. The remaining gap is real though: if the agent picks a plausible but wrong candidate, that does land as a bad result downstream. Today you'd trace it through the console call log. Surfacing the retrieval ranking itself is on the list, this thread has basically been writing our observability roadmap for us.
AgentKey
@uddipta Honest answer: right now a wrong pick mostly just looks like a normal result. Explicit errors are easy, the agent sees the failure and retries. Silent bad picks are the hard case and you put your finger on exactly where we're weakest.
The way we think about it, discovery is a loop: find the tool, judge it, call it, then feed the outcome back so the next pick is better. We have the first three. The feedback part is where the real work is, and it's barely started.
The thing that makes it tractable is that we sit in the middle of every call, so we can actually measure this. Which endpoints get picked for which phrasings, where results get thrown away or re-queried, which providers quietly underperform on ambiguous requests. None of that is exposed yet and honestly our own dashboards are thin. But that's the path: make the wrong picks visible in the data first, then drive the rate down.
Good question. Not many people get this far into it.
the social media data tier is the part I'd want more detail on - scraping platforms like X or LinkedIn directly usually runs into their ToS, and enforcement can hit the scraper's IP/account rather than the end user. when AgentKey serves social data, who's actually taking on that platform-side risk, is it abstracted away by using official APIs where available, or is it scraping under the hood and you're the one absorbing the ban risk
AgentKey
@galdayan We don't scrape under the hood. Social data comes from established vendors, some official APIs, some their own infrastructure, and managing that platform relationship is their core business. What we control is the user side, read-only access, no account linking, no credentials. Upstream enforcement lands upstream, not on you.
AgentKey
@galdayan Hi Gal, Thank you for your question. AgentKey is basically the capability marketplace for agents, handling tool discovery, execution, and payments. The truth is, users could already use other vendors to get this data. However, for ordinary users who aren't developers, this is very difficult. That's why we want to solve the problems most people encounter. These services are provided by professional Data Provider, RapidAPI and other devs, so there's no safety risk. And just so you know, the data APIs they offer just pull from the public web, not private stuff. Hope that helps!
@yanshuo that's actually the real answer to my question then - if the ban risk sits with the official API/vendor relationship and not with me as the end user, that's a fundamentally different liability model than "we scrape and hope." appreciate you and lxcong both spelling out where the enforcement actually lands.
"No integrations, no setup" is the dream for anyone who's wired up 6 APIs by hand. The question I'd have as a builder: when a source changes or rate-limits, the auto-failover keeps the workflow running — but does the agent know it fell back to a different source, or does data quality silently shift underneath it? For anything touching finance/crypto that provenance matters a lot. Curious how you surface which source actually answered.
AgentKey
AgentKey
@david_marko The agent knows, because it did the falling back itself. A dying source surfaces as an explicit failure, the agent gets same capability candidates and calls a different named tool. And that's also the answer to your last question: tools are named provider first, so which source answered is literally in the name of the call sitting in the transcript. For finance and crypto that's the property you actually want, provenance baked into the call rather than bolted on as metadata. Console logs keep the full trail, and a first class fallback marker for consumers downstream of the agent is the piece still on the list.
The marketplace framing is what I keep coming back to here. I build in the marketplace space myself, and the hard part is never listing supply, it's trust: when an agent pulls live data from a seller I've never vetted, how does AgentKey handle a source that's stale or quietly wrong? Ratings after the fact don't help an agent that already acted on bad data. Curious whether there's any freshness or accuracy guarantee baked in before the sale, or if it's caveat-emptor and the agent has to sanity-check.
AgentKey
AgentKey
@chielephant You've put your finger on the reason the marketplace isn't open yet. Today every source in the catalog got there through us: providers are vetted before they're listed, so there's no seller in there we haven't looked at. That covers entry. In rotation, health stats catch the operational failures, a source that starts erroring or lagging sinks in ranking on its own. What I won't claim is an accuracy guarantee on the values themselves. Quietly wrong is the hardest failure in this business, and anyone selling a guarantee against it is being optimistic. The practical ex ante defense is corroboration: with equivalents sitting behind the same key at per call prices, having the agent read a second source for anything high stakes is cheap, and that's what careful builders here already do. Opening self serve supply before that trust layer is productized would be doing it backwards, which is why curation comes first.
The "agents can reason but can't see the live internet" framing is right, and folding search + social + finance + crypto behind one MCP install instead of wiring each integration is the real time-save. My setup question: does every data call route through AgentKey's hosted proxy — so my agent's query params pass through your servers — or can it run with my own upstream provider keys locally? And when auto-failover swaps sources mid-workflow, can I see which provider actually served a given response, or is provenance abstracted away?
AgentKey
@noctis06 Hosted, yes, by design, failover, QoS shaping and one balance only work because the provider pool lives server side, so params do pass through us, fair to weigh that. Local mode with your own upstream keys isn't there today. Provenance isn't abstracted though: the agent picks the named replacement tool itself, so the serving provider is in the transcript, and every call is in the console log. Per-call fallback markers are the on the list item.
How are you handling the token rotation and revocation lifecycle for these agent identities? If an agent gets compromised or exhibits drift, what's the mechanism to kill its active session immediately without invalidating the entire user's OIDC context, or is there a 'session-in-session' architecture that lets us selectively revoke the agent's access while keeping the human user logged in?
AgentKey
@mahendra1290 Simpler than the architecture you're describing, and here the simplicity is doing the work. An agent never borrows your login. Your console session and the agent's credential are separate objects entirely: the agent holds an API key, you hold the OIDC session, and neither derives from the other. So the selective kill you want is just key revocation, immediate, and your own login never notices. Rotation is the same story: mint a new key, move the agent over, revoke the old one. What we don't have yet is drift detection that auto-kills a key, today the signal is per-call spend visibility and the kill switch is a human decision.