AnovaGrowth Developer Resources
Public developer resources and a practical research notebook for applied AI systems: source grounding, human review, evaluation, and deployment decisions.
Machine-readable resources for agents and integrators
Start with the agent instructions or concise site guide, then read the OpenAPI contract before using a documented operation. These resources describe the public AnovaGrowth surface without embedding credentials or inventing private access.
Last updated
AnovaGrowth OpenAPI Specification
The machine-readable contract for documented operations, typed parameters, response schemas, and explicit authentication declarations.
AnovaGrowth Agent Instructions
When to use AnovaGrowth, where to start, how to navigate the public resources, and which boundaries agents must respect.
AnovaGrowth Agent Manifest
A compact inventory of AnovaGrowth capabilities, services, and machine-readable resources.
AnovaGrowth Site Guides
Concise and full markdown guides for retrieval systems that need company, service, and research context.
When to use AnovaGrowth
AnovaGrowth is a fit when a business needs a narrow, reviewable AI agent for lead follow-up, support, or recurring operations; a workflow audit to decide what to automate first; custom software or an integration between existing systems; or a service-business website connected to intake and follow-up.
Call sequence: read the agent instructions, choose a best-fit page from the site guide, read openapi.json before any documented API call, and follow its typed schemas and authentication declaration. Do not invent endpoints, credentials, webhooks, MCP servers, products, pricing, or completed external actions.
A defensible record before a system ships
Every build should keep source context, release checks, cost considerations, and deployment notes visible to the people responsible for it.
Evaluation record
Illustrative workflow · not a live deployment result
Intake
Mapped
sources documented by build
Evals
Gated
checks required before release
Latency
Measured
reported per deployed workflow
What We're Building
Custom Model Training
MethodsFine-tuning methods to evaluate when a domain task and enough approved examples justify a custom model.
Agent Architecture
PatternsMulti-step agent patterns with visible tool use, source context, human review, and clear ownership boundaries.
RAG Systems
MethodsRetrieval patterns that ground AI in approved company data and make the supporting context inspectable.
Voice AI
ResearchVoice-agent research for phone interactions, including latency, escalation rules, consent, and review requirements.
Self-Hosted Inference
Deployment optionOpen-weight deployment options for teams that need more direct control over privacy, latency, and cost.
Evaluation & Benchmarking
MethodsEvaluation methods for response quality, latency, cost, escalation, and observable business outcomes.
Reference workflows
Four reference workflows used to make scoping, review boundaries, and deployment requirements concrete.
A reviewed support pattern: retrieve approved context, draft a response, cite the source, and escalate edge cases.
An intake pattern that captures the right context, prepares a CRM handoff, and leaves final qualification to the operator.
A document-processing pattern that maps a source, validates fields, and routes uncertain records for review.
A research area for phone workflows where latency, disclosure, escalation, and conversational quality must be assessed together.
How We Build AI
Start with the problem, not the model
We evaluate whether AI is even the right tool before building anything. Sometimes a well-designed workflow beats a neural network.
Use the best model for the job
Provider and open-weight options should be evaluated against the task, source boundary, operating cost, and review requirements before a deployment choice is made.
Own your infrastructure
A scoped deployment can include self-hosted inference when privacy, hardware, operating cost, and ownership requirements make that the defensible option.
Measure everything
Each proposed system should define the evaluation checks, latency, cost, escalation, and business signals that can be observed before it is recommended for release.