A field guide for builders.
Are We Agent Yet? helps developers discover available solutions for general agent applications. Start with a task, explore the stack, and follow the evidence behind each assessment.
This is a curated reference, not a benchmark, certification or universal ranking. The right choice depends on your workload, integration budget and operating constraints. We publish no single numerical readiness score.
Different types. Different questions.
- Projects
- Public-source software with an identifiable implementation. Public source does not always mean an unrestricted open-source license.
- Standards & specifications
- Published specifications and protocol formats. Community formats are distinguished from formal standards-body approvals in the source notes. A specification is not a working implementation.
- Drafts & workstreams
- Proposals and active work that are not released standards. Draft status is independent of any software's readiness.
- Model families
- Families of models, rather than a verdict on every checkpoint. Capabilities, licenses and weight availability require model-specific checks.
The initial catalog contains 136 projects, 78 standards/specifications, 11 drafts/workstreams and 14 model families. We retain all 239 source entries and their original scope notes.
A verdict with a reason.
Readiness is an editorial inference from linked evidence, not a vendor certification. The first 13 assessments are desk reviews of developer-facing projects; we have not installed, benchmarked or security-audited those tools.
Documented usable functionality plus named deployment evidence or a documented operational track record. Publisher claims are attributed, and the label applies only to the reviewed component.
A public implementation, runnable documentation and identifiable integration requirements. This is enough to consider evaluating it, not a promise that it fits every production workload.
Evidence indicates a proof of concept, explicitly unstable interface or substantial missing functionality for the stated use case. Age or a low star count alone does not establish this label.
We have not gathered sufficient evidence for a verdict. This is neither a positive nor a negative judgment.
Specifications will require evidence about publication status, implementation compatibility and conformance. Model assessments will require checkpoint-specific licensing and capability evaluations. Those assessment types are not yet populated; the project rubric is not automatically applied to them.
Keep the dimensions separate.
- Maturity
- Documented functionality, version/release information, integration requirements and evidence supporting the readiness verdict.
- Adoption signals
- Named usage reports, documented integrations and community evidence. Publisher-reported usage is labeled. GitHub stars and forks are not substitutes for deployments; we do not invent usage counts.
- Developer experience
- Documentation, runnable examples, typed interfaces, setup requirements and debugging tools. Desk-review observations are not hands-on usability measurements.
- Maintenance
- Public change logs, releases and compatibility guidance. We state what was checked and leave response times and support commitments unassessed unless supported by evidence.
- Compatibility & access
- Languages, protocols, deployment dependencies and license boundaries. Hosted services, enterprise features and model weights can have terms separate from public code.
Each assessment includes primary-source links, constraints and an evidence review date. Interpret architecture implications as editorial analysis. A fresh review date does not mean every dimension has been independently verified.
Missing evidence isn't missing software.
Catalog coverage: no match means no entry in this catalog matches the chosen filters. It does not prove that no solution exists.
Assessment coverage: 13 of 239 entries currently have editorial assessments. Counts measure our review coverage, not an ecosystem readiness percentage.
Documented limitations: task guides and solution pages describe constraints supported by project documentation or explicitly identified architectural implications.
Task mappings show relevance inferred from the catalog taxonomy and reviewed tool capabilities. They are not verified interoperability claims. Compare related entries with care: an isolation primitive, a hosted sandbox and a policy engine solve different parts of a task.
A snapshot, with a paper trail.
The starting point is the bilingual Open Source Agentic AI Landscape, based on September 3–9 source snapshots, September 30 additions and the October 5 OpenFab addition. The source catalog has 239 entries; original poster artwork and its audit still reflect the 238-entry September edition.
Initial editorial evidence was reviewed on . Evidence links lead to live primary sources that can change. We do not collect live telemetry or update metrics automatically.
Help make the map better.
This edition is maintained through reviewed repository changes. To propose a correction or assessment, include the project name, task/category fit, official source URLs, dated observations, license/deployment boundaries and known limitations.
Maintainers can update the structured catalog and assessment files, run validation, and rebuild the site. Every editorial change should retain its evidence and review date. The repository README documents the editing workflow.
User submissions are planned for a later phase and will enter a review queue before publication. An online submission form is not available in this edition.