Technical Guide: Automating Documentation with Kaya Suites

Practical Summary and Core Functionality

Kaya Suites is an AI-native knowledge base designed to function as a living source of truth by actively maintaining documentation through an automated agent pipeline. The system is built as a single Apache 2.0 distribution, utilizing a Rust backend based on Axum and a Cargo workspace, paired with a Next.js 16 frontend. The core innovation lies in its three-agent architecture: an orchestrator that classifies chat turns, a read-only researcher that gathers evidence, and a write-only editor that proposes modifications. This structure ensures that no agent can directly mutate storage, enforcing a strict separation of concerns that is validated at compile time using trybuild tests.

Prerequisites and System Requirements

To successfully deploy and operate Kaya Suites, users must ensure their environment meets specific technical requirements. The system requires Rust (stable, edition 2024) for the backend and Node.js version 20 or higher, along with pnpm version 9 or higher for the frontend. Additionally, a SQLite system library is required as the default storage backend. The repository structure is specific: the Rust workspace root is located at apps/backend/Cargo.toml, and it is important to note that there is no Cargo.toml at the repository root, nor is the apps/web/ directory part of the Cargo workspace.

Backend and Frontend Setup

Setting up the development environment involves initializing both the backend and frontend components. For the backend, navigate to apps/backend and execute cargo build --workspace followed by cargo run --bin kaya-oss. The OSS binary will serve the HTTP API on http://localhost:3001 by default. For the frontend, run pnpm install from the repository root, followed by pnpm dev to launch the workspace development scripts. The web application is accessed on http://localhost:3000 and is configured to proxy API calls to the backend via the NEXT_PUBLIC_API_URL environment variable, which defaults to http://localhost:3001.

The Propose-then-Approve Workflow

Kaya Suites implements a secure workflow for document updates to maintain data integrity. Agents do not have direct write access to the storage layer. Instead, all proposed edits are generated as ProposedEdit events and streamed over Server-Sent Events (SSE). A change only becomes permanent when a user provides explicit approval, which generates an ApprovalToken. This token is required by the commit_edit function to finalize the update. This mechanism ensures that the knowledge base remains a verified source of truth, as every modification is subject to human oversight before being committed to the underlying storage.

Regenerating the API Client

The project uses a generated TypeScript OpenAPI client to bridge the Rust backend and the Next.js frontend. If you modify a backend route or the data schema, you must regenerate the client to keep the frontend in sync. The documented process for this is as follows:

cd apps/backend
cargo run --bin kaya-oss -- --schema > ../../packages/api-client/openapi.json
cd ../../
pnpm generate

It is essential that both the updated openapi.json file and the generated files within packages/api-client/src/ are committed to version control together to ensure consistency across the codebase.

Configuration and LLM Integration

Kaya Suites supports pluggable LLM providers, including OpenAI, Anthropic, Gemini, and a MockProvider for testing purposes. Routing is managed through a configuration-driven approach using apps/backend/kaya.yaml. Users must provide the necessary API keys via environment variables, such as OPENAI_API_KEY, ANTHROPIC_API_KEY, or GEMINI_API_KEY, depending on the selected provider. Detailed information regarding the LlmProvider, ModelRouter, and specific routing configurations can be found in the project documentation at https://github.com/Kaya-suites/Kaya-Suites#readme.

Storage and Authentication Adapters

The system is designed for flexibility through the use of adapters. The StorageAdapter trait allows the system to interface with multiple backends, including SQLite (the default), Postgres, and MySQL. Similarly, the AuthAdapter trait provides a framework for authentication, with current scaffolds supporting magic link and password-based login. On the first boot, the backend automatically seeds a superadmin account with the credentials admin@kaya.local (email), KayaSuperAdmin (username), and KayaPassword. Users are strongly advised to change these credentials immediately via the account settings page, as they are intended solely for local development.

Choosing When to Use Kaya Suites

Kaya Suites is best suited for teams that require an AI-assisted documentation management system where accuracy and verification are paramount. Because the system enforces a strict propose-then-approve workflow, it is ideal for environments where documentation must be treated as a living, audited source of truth rather than a static repository. The pluggable nature of its storage and LLM providers makes it adaptable to various infrastructure requirements, provided the team is comfortable working within a Rust-based backend and a Next.js frontend ecosystem. For further architectural details, refer to the official documentation provided at https://github.com/Kaya-suites/Kaya-Suites#readme.