Architecture & Technical Overview

The diagram below shows the components, the path a request takes, and the trust boundary between customer devices, the Kavanah platform, and the third-party services a customer chooses to connect. Each tier is described in the sections that follow.

Kavanah ships as three shells built from the same codebase, so behavior and security controls are consistent across every surface:

• Web app — the primary experience, served from the deployed Next.js application.
• Desktop app — a native macOS / Windows / Linux shell (Tauri) that loads the same web application.
• Mobile app — native iOS / Android shells (Tauri) that load the same web application, with native push notifications and biometric-capable device integration.

Because the shells load the deployed app rather than a bundled copy, security fixes and feature updates reach every platform the moment they ship — there is no stale client to patch.

Kavanah exposes a documented HTTP API described by an OpenAPI 3.1 specification. Every endpoint enforces the same authentication, workspace-scoping, and role checks as the UI — the UI is simply a client of the API. Requests are authenticated with session tokens and protected against cross-origin abuse with strict origin/CSRF checks.

All customer data is stored in a single logical Postgres database with strict row-level tenant scoping: every workspace-scoped table carries a workspace_id, and every query is required to filter on it. A build-time linter enforces this invariant so a tenant-isolation gap cannot ship unnoticed. See the Security Overview for detail.

Data residency

Production data is processed in the United States. See Sub-processors for the regions of each infrastructure provider. Enterprise customers with specific residency requirements can discuss options with our team.

Kavanah integrates with a broad set of third-party systems — Google Workspace, Microsoft 365, Notion, GitHub, ClickUp, ClearBooks, and more. Integrations connect through per-provider OAuth (or scoped API keys) that the customer authorizes. Access tokens are encrypted at rest with AES-256-GCM, scoped to the least privilege each feature needs, and revocable at any time from workspace settings. Data is exchanged only between the customer's workspace and the service they connected.

The built-in AI agent operates through a controlled tool-calling loop. It can only invoke the specific tools exposed to it, each of which enforces the same permission and workspace-scoping checks as the rest of the platform. Persona-level scopes further restrict which capability groups a given agent identity may use, and read-only tools are classified separately from tools that can make changes. The AI data-use posture is documented on the AI Transparency page.

The platform runs on auto-scaling serverless infrastructure with no single application host to fail. Background jobs are idempotent and monitored by a health registry that surfaces missed or failing runs. The database provides continuous backups with point-in-time recovery, and restore procedures are rehearsed on a recurring drill. Availability commitments are described in the SLA, and recovery objectives, backup design, and the continuity plan in the Disaster Recovery & Business Continuity Plan.