Every project and opportunity links back to its original GitHub source.
Radar Methodology
AI Agent Radar is a discovery and research aid built from public GitHub data. These rules explain what enters the Radar, how rankings are calculated and where human validation is still required.
Methodology version 1.0 · Last updated September 6, 2026
Projects cannot buy placement or a higher Radar Score.
Signals are labeled as evidence, not proof of quality or market demand.
How projects enter the candidate pool
The system searches GitHub for AI-agent, MCP server, agent framework and multi-agent system repositories. Searches deliberately mix established projects with smaller, recently active repositories.
Required signals
- Explicit agent, agentic, autonomous or equivalent identity
- Multiple action-oriented capabilities, strong autonomy or agent infrastructure
- A public, non-archived GitHub repository
Common exclusions
- Standalone foundation models without agent workflows
- Single-purpose content generators without autonomy
- Thin compatibility layers and adjacent products
- Repositories that no longer match the active search criteria
A 100-point discovery signal
Adoption25 points
Log-scaled GitHub stars and forks. Scale matters, but cannot dominate the whole score.
Maintenance20 points
Based on time since the repository’s latest push: 7, 30, 90 and 180-day activity bands.
Project quality20 points
Declared license, useful description, topic coverage, open-Issue activity and homepage metadata.
Agent relevance20 points
How directly the name, description and topics describe agents, autonomy, workflows or MCP.
Demand evidence10 points
Qualified open Issues and their discussion or positive-reaction engagement.
Momentum5 points
Observed star growth between Radar scans, log-scaled to reduce viral distortion.
Radar Score helps prioritize investigation. It is not a security audit, benchmark result, hands-on review or endorsement.
How potential needs are filtered
Ten candidate repositories are scanned every six hours on a rotating schedule. Open Issues must contain problem, request, workflow, integration, performance, documentation, security or similar demand language—and have at least two comments or two positive reactions.
Dependency dashboards, release checklists, automated updates, CI failures, build-status tracking and test-matrix maintenance are excluded. The opportunity page publicly reports how many current repositories have completed an Issue scan.
When one signal becomes a pattern
Emerging1 repository
Cross-project2 independent repositories
Recurring3+ independent repositories
Pattern ranking also considers the number of Issues, comments and positive reactions. Repetition raises confidence that a problem is broader, but still does not prove willingness to pay.
What the Radar cannot tell you
- Stars can reflect attention rather than production adoption.
- Open Issues overrepresent developers who use GitHub and choose to post publicly.
- A long-open Issue may be difficult, low priority or outside a project’s scope—not necessarily a business opportunity.
- Automated text classification can misclassify projects and problem themes.
- Repository metadata can change between scans.
Before building, read the original discussion, interview affected users and test a narrow solution. The guided validation briefs exist for exactly this reason.