Overview
ACN’s discovery engine lets agents find services using natural language. Instead of browsing a catalog or reading API docs, an agent simply describes what it needs — and ACN returns the best matches, ranked by relevance, quality, and price.How Discovery Works
The discovery pipeline has four stages:1. Intent Parsing
An LLM analyzes the natural language query to extract:- Primary intent — What the agent is trying to accomplish
- Category signals — Which service categories are relevant
- Constraint signals — Implied requirements (speed, accuracy, price sensitivity)
2. Semantic Search
The parsed intent is converted into a vector embedding and matched against all registered endpoints using k-nearest-neighbor (k-NN) vector search. This finds services that are semantically similar to the request, even if they don’t contain the exact keywords. For example, “send a notification to a user’s phone” would match SMS services, push notification services, and messaging APIs — even though none of those descriptions contain the word “notification.”3. Structured Filtering
After semantic matching, results are filtered by any explicit constraints:| Filter | Description | Example |
|---|---|---|
category | Service category | data_intelligence, ai_ml, communication, blockchain, utility |
tags | Specific tags | ["email", "transactional"] |
max_price_per_call | Price ceiling in USDC | 0.01 |
min_uptime_pct | Minimum uptime | 99.5 |
method | HTTP method | POST |
4. Ranking
Results are scored using a weighted combination of:- Relevance score — How well the service matches the query (from semantic search)
- Quality metrics — Uptime percentage, average latency, error rate
- Usage signals — Total calls served (a proxy for trust and reliability)
- Price — Lower-priced services rank higher when relevance is equal
Discovery Response
Each result includes everything an agent needs to decide and execute:Caching
Discovery results are cached for performance:- Semantic results: 5-minute TTL
- Quality metrics: 1-minute TTL (fresher data for uptime/latency)
Rate Limits
| Authentication | Rate Limit |
|---|---|
| Unauthenticated (by IP) | 20 requests/minute |
| Authenticated (by developer) | 100 requests/minute |
Best Practices
Be specific in your queries
Be specific in your queries
“Send a transactional email with HTML support” returns better results than just “email.” The more context you provide, the better the semantic matching.
Use filters for hard constraints
Use filters for hard constraints
If you need a service under $0.01/call or with 99.9% uptime, use structured filters rather than mentioning it in the query text. Filters are applied as hard cutoffs.
Let agents choose dynamically
Let agents choose dynamically
Don’t hard-code provider IDs. Let your agent discover and choose the best provider at runtime. This makes your agent resilient to provider outages and price changes.
Cache discovery results in your agent
Cache discovery results in your agent
For repeated tasks, cache the discovery results on your side to reduce latency. The provider landscape doesn’t change every second.