Kami AI

01The problem

Most in-product assistants only answer questions, so the user still has to hunt through screens to get work done. An agent that acts inside a real SaaS product also has to respect the user’s permissions, avoid duplicate approvals for ordinary work and stop before anything risky.

02The approach

1. Embed a script in the host product. The agent combines the user’s request, the interface currently on screen, recent conversation and product knowledge to decide each next step, then navigates, opens records, selects options and fills fields through the live UI.
2. Make voice the default with realtime two-way conversation over WebRTC and an on-device wake word that runs in the browser with ONNX Runtime Web; typing stays a first-class option.
3. Run a multi-tenant TypeScript backend with separate tool, embed, runtime and client-admin routes, Zod-validated tool calls, rate limiting and passwordless admin login. Act only through the signed-in user’s existing access.
4. Classify risk before acting: ordinary requested changes go straight through, while money movement, credential or security changes and destructive actions pause for one final confirmation. Tasks can be stopped and activity is recorded.

03The evidence

• Live at kamiai.tech with a recorded product run in which a dispatcher asks Kami to find an emergency job, open the record, assign the route and verify the saved outcome.
• Every change passes a CI release gate: dependency audit, typecheck, backend and embed regression suites, behaviour evals for risk confirmation and execution-state memory, and Playwright browser regressions.
• Deployed on a Linux server behind nginx and TLS, managed with PM2.