Speconaut v1: the first tool in an API platform
Practical tools through APIs, starting with answers from your own knowledge.
The product is the tool
Speconaut is an API tools platform. The purpose is to give an application a useful capability without requiring its developer to build and operate a large specialist backend for every new feature.
The first tool is Speconaut AI, a knowledge-answering service built around owner-provided source material. Its job is to retrieve relevant evidence, answer a product question, and retain useful context for the next question. It is one tool in the platform, not the entire future catalog.
Speconaut AI is a service name, not a claim that Speconaut trained a proprietary foundation model. The service connects retrieval, model calls, source references and usage handling behind an integration contract. You integrate the capability rather than build those parts separately.
What the first version brings together
The core starts with a store: a scoped collection of product or topic knowledge. A store does not have to be a retail checkout. It can represent a catalog, a project collection, or a focused reference set that an application needs to answer questions about.
Source-backed answers and comparisons use the facts supplied for that collection. Follow-up context helps keep a conversation about the same items without making the previous answer a substitute for evidence. Multilingual query planning helps relate a user's phrasing to relevant source candidates; it is not a guarantee that every language or query resolves perfectly.
The workspace separates Products, Sources and Missing. Product discovery and source maintenance are different tasks. Missing is a reviewable backlog, not an automatic verdict that an item is unavailable for sale. An unanswered question can point to a content gap, a naming mismatch, or an unavailable index.
Sources stay separate from search readiness
The authoritative layer is the source material, not a generated answer or one giant prompt. Directory V3 selects bounded metadata candidates and then the relevant sources. A published generation keeps retrieval tied to a consistent view of the collection.
Saving a file is not the same as making it searchable. The current pipeline still needs publication and verification. The useful check is not only whether a build completed, but whether a representative question returns the expected item and supporting source.
This design keeps the retrieval path bounded. It does not establish a tested million-item capacity or imply that incremental ingestion is complete. Those claims require their own scale, recall and operational measurements.
Working core, controlled access
Version 1 describes the implemented service core and its integration work. It is not an announcement that unrestricted customer signup, every API route, or production billing is available.
Local engineering checks cover account flows, source workflows, request and token metering, and usage deductions in an isolated test wallet. Real Google SMS transport and the local three-day remembered-device flow were also exercised. Engineering tests are not a model-accuracy benchmark or a production availability guarantee.
Source management remains an operator preview outside the isolated test environment. Real deletion stays gated on recoverable storage and permissions. Customer-to-store authorization, production recovery, billing activation and deployment still require their own review. The documentation availability section is the place to check these boundaries.
How an application connects
The first integration is an authenticated request to the account's assigned API base. The answer contract accepts a question and optional follow-up context. Credentials belong in the application's server-side code or a small serverless function, not in a public page.
The workspace provides account, key and usage surfaces. A successful account login is not proof that a particular API tool or permission is provisioned. The API reference describes the implemented contracts and the distinction between account keys and operator source-management access.
Explore the API reference or follow the source-to-answer guide.
More tools, not more infrastructure to assemble
The next direction is image, audio, file conversion and document tools. Each should be a focused capability with understandable inputs, outputs, errors and costs. Some tools may use AI; others may be deterministic processing. Calling an operation a tool does not mean every request should be billed as model tokens.
These groups are planned, not available in v1. No endpoint, price or release date is promised for them yet. The aim is a useful API catalog that can serve different kinds of applications, while keeping each tool's lifecycle and billing explicit.