Use cases
SeedSpec can support different creators and consumers without turning their approval, support, commercial, or governance models into protocol semantics.
One package format, different relationships
A specification may be authored inside an enterprise, published by a software vendor, developed by a consultancy, maintained by an open-source community, or shared directly. Each relationship adds different authority and expectations around the same inspectable package.
Internal enterprise libraries
Turn recurring organizational knowledge into approved, versioned starting points that teams can adapt without losing policy, provenance, or release expectations.
Explore this use case →Vendor-produced specifications
Give customers agent-ready solution knowledge built around the vendor’s own data model, APIs, extension points, examples, and operational guidance.
Explore this use case →Consultancies and agencies
Reuse proven product and domain thinking while adapting each implementation to the customer’s stack, systems, compliance requirements, and operating model.
Explore this use case →Two independent dimensions
- What gets produced
- A new application, an adapted feature, a configured SaaS product, a cross-system automation, or a composite solution.
- How the specification reaches the adopter
- Direct sharing, an internal library, vendor catalog, consultancy offering, or public collection supplies context around the package.
The protocol keeps those dimensions separate. Portability, independent verification, and neutrality apply to every package; the surrounding organization decides what it approves, supports, or recommends.
Where SeedSpec adds the most value
Capable agents can solve many common, well-bounded tasks without SeedSpec. The value grows when a result crosses systems, depends on unfamiliar or private platforms, contains important edge cases, carries security or regulatory consequences, or represents expertise worth reusing.