AgentDex

Inspiration

We were inspired by YC's Summer 2026 Requests For Startups, "Software For Agents" blog by Aaron Epstein:

Agents need a completely different foundation. Instead of visual interfaces like forms, buttons, and dashboards, they need machine-readable interfaces like APIs, MCPs, and CLIs. Agents also need thorough documentation, to enable them to discover, sign up for, and instantly start using new tools programmatically, without needing a human in the loop.

Here is the problem:

When an agent does multi-step research, it works serially: think → search topic A → read → think → search topic B → read. Every related sub-topic only gets discovered, browsed, and structured after the agent's reasoning arrives there — even when the adjacency was predictable from the start. Research about atoms is reliably going to touch electrons, protons, and basic chemistry; research about a company's filings is reliably going to touch its competitors and sector. That predictability is currently wasted — nothing acts on it until the agent stumbles into the next topic itself.

Solution

AgentDex sits beside the dev's agent as a concurrent research assistant, not just a request/response API:

1. The agent queries AgentDex about a topic.
2. AgentDex immediately starts the normal pipeline for that exact topic — browse (Browserbase), structure (Claude + redis vector store), generate an MCP server — and returns it as fast as possible.
3. At the same time, AgentDex computes which other topics sit in close vector proximity to the one just asked about, and kicks off the same pipeline for the top few candidates in parallel, without blocking the agent's current answer.
4. If the agent's next question lands on one of those candidates, the interface is already built — the agent gets a warm, structured answer instead of triggering a cold pipeline run.

The pitch in one line: your agent never has to wait for the obvious next question — by the time it asks, AgentDex already bet on it and did the work in the background.

How we built it

• Browserbase does the actual legwork: fetching and rendering real pages for every research worker, whether it's answering the question that was asked or betting on the one that's coming.
• Claude wears two hats: it turns messy page content into something an agent can actually call, and it makes the one judgment call this whole idea lives or dies on, deciding which similar topics are genuine next-question bets and which are just vector-space lookalikes. Skip that step and you've built an expensive nearest-neighbor toy, not a research assistant.
• Redis, via RedisVL, holds the growing map of everything AgentDex has ever researched and how it all relates: the proximity graph that makes the bet possible in the first place.
• MCP turns every researched topic, asked-for or speculative, into a live, callable interface, with a thin REST mirror riding along for anything that still wants a plain HTTP endpoint.
• Sentry watches both the path you asked for and every parallel bet running quietly in the background. Concurrency means more ways for things to break, so we wanted to see the moment something did.
• Every speculative bet runs on a leash: a cap on how many candidates get researched, a confidence bar a candidate has to clear before we spend real research budget on it, and a timeout so a slow bet never blocks the answer you actually asked for.

Challenges we ran into

1. The connection to Redis Cloud was a problem that made us use Redis locally instead
2. Determining our architecture to utilize the sponsors and solve YC's problem statement

Accomplishments that we're proud of

• Watching a question get answered by work that finished before the question was asked: a real, timestamped, no-cache warm hit.
• Seeing AgentDex make an actual difference in deep research time.

Considerations

Good fit: domains with a known, fairly stable concept graph — science/technical research (atoms → electrons → chemistry), company research (a firm → its named competitors → its sector), documentation research (an API endpoint → its sibling endpoints).

Bad fit: domains where "related" doesn't mean "likely to be asked next" — vector proximity is a similarity measure, not an intent predictor, and conflating the two is the main way this idea fails quietly.

Pay a small embedding cost on every query to avoid a large crawl cost on every paraphrased hit.

What's next for AgentDex

• Letting real usage train the relevance filter instead of a static prompt, tracking which bets actually get asked and which get wasted, so the system gets sharper the more it's used instead of staying frozen at hackathon quality.
• Giving AgentDex memory across sessions, so the bet it makes today is informed by every bet it's made before.

Built With

• browserbase
• claude
• fastapi
• fetch
• python
• redis
• redisvl
• uagents