Project Info
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: The agent queries AgentDex about a topic. 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. 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. 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
The connection to Redis Cloud was a problem that made us use Redis locally instead Determining our architecture to utilize the sponsors and solve YC's problem statement
Accomplishments 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
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.
AgentDex
A speculative pre-fetching research pipeline built on Fetch.ai uAgents and RedisVL. AgentDex predicts which topics a researcher will ask about next and pre-warms them in the background — so the second query returns instantly from cache instead of waiting for a full crawl.
The analogy is CPU branch prediction or browser link prefetching: AgentDex bets on your next question before you ask it.
Demo
dev_agent queries "atoms" → cold run → Wikipedia crawl + Claude classification
speculative worker pre-warms: electrons, protons, periodic table
dev_agent queries "electrons" → *** WARM HIT *** → served instantly from Redis
Architecture
| Agent | File | Role |
|---|---|---|
orchestrator | agents/orchestrator_agent.py | Checks Redis cache; dispatches primary + speculative workers; two-stage speculation (vector KNN → Claude filter) |
primary_worker | agents/primary_worker.py | Crawls Wikipedia via Browserbase/Playwright; classifies with Claude; populates cache |
speculative_worker | agents/speculative_worker.py | Pre-fetches predicted follow-up topics concurrently; discarded on timeout |
dev_agent | agents/dev_agent.py | Demo client — sends atoms → electrons to show cold run then warm hit |
Speculation pipeline
- Exact cache check — Redis hash lookup by topic key; return immediately if warm
- Semantic cache check — embed query, KNN search; if nearest neighbor distance <
SEMANTIC_HIT_THRESHOLD(default0.15), serve from cache without crawling - Primary worker dispatch — crawl + classify the requested topic
- Speculative expansion — Redis KNN returns similar topics → Claude filters to genuine "next question" candidates → dispatch speculative workers for each
Setup
# Install Python dependencies
pip install -r requirements.txt
# Install Playwright browsers
playwright install chromium
# Copy and fill in environment variables
cp .env.example .env
# Run the pipeline
python main.py
Environment variables
| Variable | Required | Purpose |
|---|---|---|
ANTHROPIC_API_KEY | Yes | Claude API calls (classification + speculation filter) |
BROWSERBASE_API_KEY | Yes | Browserbase session for Wikipedia crawling |
BROWSERBASE_PROJECT_ID | Yes | Browserbase project |
REDIS_URL | Yes | Redis connection — use redis://localhost:6379 for local Redis Stack |
SENTRY_DSN | No | Error reporting in speculative_worker |
SPECULATION_BUDGET | No | Max speculative topics per query (default 3) |
SPECULATIVE_TIMEOUT_SECS | No | Timeout for each speculative fetch (default 30) |
SEMANTIC_HIT_THRESHOLD | No | Cosine distance for a semantic cache hit (default 0.15) |
Local Redis Stack (required for vector search)
Redis Cloud free tier uses TLS 1.0/1.1 which is incompatible with Python 3.13 / OpenSSL 3.x. Run Redis Stack locally instead:
docker run -d --name redis-stack -p 6379:6379 redis/redis-stack-server:latest
Then set REDIS_URL=redis://localhost:6379 in .env.
Shared modules
| Module | Purpose |
|---|---|
shared/redis_client.py | RedisVL vector index — embed, set_warm, get_warm, search_nearest_with_scores, all_topics |
shared/pipeline.py | I/O — crawl_topic (Browserbase), classify_and_structure (Claude), filter_speculative_candidates (Claude), research_topic |
shared/cache.py | Re-exports get_warm, set_warm, all_topics from redis_client |
shared/messages.py | uAgents message models: TopicQuery, ResearchRequest, ResearchResult |
shared/config.py | Seeds, address slots, and tuning constants |
MCP server — external agent access
mcp_server.py exposes the AgentDex pipeline as an MCP server. Any MCP-compatible agent can use it without joining the internal uAgents Bureau.
How it fits in
┌─────────────────── Bureau (main.py) ───────────────────┐
│ dev_agent ──TopicQuery──► orchestrator ──► workers │ ← internal, uAgents protocol
└────────────────────────────────────────────────────────┘
External developer agent
└── mcp_server.py (stdio) ──► shared/pipeline.py ← external, MCP protocol
└──► shared/redis_client.py
The Bureau and the MCP server share the same Redis backend, so topics pre-warmed by the speculative pipeline are immediately available to external agents via get_cached_topic and search_similar_topics.
Tools
| Tool | Parameters | What it does |
|---|---|---|
research_topic | topic: str | Crawls Wikipedia, classifies with Claude, stores in Redis cache. Returns JSON with summary, key_facts, related_concepts, mcp_tools. |
get_cached_topic | topic: str | Direct Redis lookup. Returns cached JSON or {} if not warm. |
search_similar_topics | query: str, k: int = 5 | Semantic KNN search. Returns [{topic, distance}] sorted by cosine distance. |
list_warm_topics | — | Lists all topics currently in the Redis cache. |
Claude Desktop / Claude Code
Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/):
{
"mcpServers": {
"agentdex": {
"command": "python",
"args": ["/path/to/AgentDex/mcp_server.py"],
"env": {
"ANTHROPIC_API_KEY": "...",
"BROWSERBASE_API_KEY": "...",
"BROWSERBASE_PROJECT_ID": "...",
"REDIS_URL": "redis://localhost:6379"
}
}
}
}
Claude will then call research_topic, search_similar_topics, etc. as native tools.
Python agent (MCP client)
from mcp import ClientSession
from mcp.client.stdio import stdio_client, StdioServerParameters
params = StdioServerParameters(
command="python",
args=["/path/to/AgentDex/mcp_server.py"],
env={"ANTHROPIC_API_KEY": "...", "REDIS_URL": "redis://localhost:6379", ...},
)
async with stdio_client(params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# Cold research — crawls Wikipedia + caches result
result = await session.call_tool("research_topic", {"topic": "black holes"})
# Warm lookup — instant if already cached
cached = await session.call_tool("get_cached_topic", {"topic": "black holes"})
# Semantic search across everything in the cache
similar = await session.call_tool("search_similar_topics", {"query": "event horizon", "k": 5})
Direct Python import (same repo)
If the developer's agent runs in the same Python environment, MCP is optional:
from shared.pipeline import research_topic
from shared.redis_client import get_warm, search_nearest_with_scores
result = await research_topic("quantum entanglement")
similar = await search_nearest_with_scores("spooky action", k=5)
Validation
python scripts/test_person_a.py
Tests the full Redis pipeline: upsert → warm lookup → KNN search → Claude speculation filter → import compatibility. Requires local Redis Stack and ANTHROPIC_API_KEY.
Analysis
View
Metric
- 7
- 5
- 5
- 1
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- AnthropicIn code
- FastAPIIn code
- PythonIn code
- RedisIn code
4 of 4 appear in the indexed code.
AI coding agents
- Claude CodeConfig · Commits
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
92 KB
Source files
22
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
codebyemily/AgentDex
24 files · 92 KB · @ 16867bf
Structure
Application logic
18 files · 75%Domain rules, services and shared utilities.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python82%
- Markdown18%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
requirements.txt
pypi · 13- anthropic
- browserbase
- fastapi
- mcp
- numpy
- playwright
- python-dotenv
- redis
- redisvl
- sentence-transformers
- sentry-sdk
- uagents
- uvicorn
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.