Soul
A soul is an agent identity — the “who” and “what” of your agent. It has two distinct parts:- Character (
soulMd) — WHO the agent is. Written like a hire brief, not a rules list. Voice, values, judgment style. This is what makes the agent behave sensibly in situations you never explicitly anticipated. - Context (
agentsMd) — WHAT the agent operates in. The product, the users, the domain, the constraints. Situational awareness, not personality. - Allowed tools — what the agent can actually do. You control this explicitly.
- Model — which LLM powers this soul. Supports Anthropic, OpenAI, and OpenRouter models.
One soul serves all your users. Each user gets their own isolated context on top of it. Change the soul’s character once — every user gets the update on the next invocation.
Memory
Every user gets a persistent memory store, scoped to them. The agent reads it at the start of each invocation and can write to it during the session. Memory has four semantic categories — each tells the agent how to use the information, not just what it is.Agent writes
The agent uses built-in tools to write what it observes — preferences, patterns, relationship history — with the right category.
Your app writes
You write ground truth from your database — plan, name, recent DB state. The agent treats it as authoritative.
result.memoryDelta tells you exactly what it wrote. Sync it back to your DB if needed.
Memory is scoped by role — the same user can have different memory for different agent contexts (e.g. support vs onboarding).
Sessions
Sessions give the agent multi-turn conversation history. When you pass asessionId, the agent picks up where it left off.
Without
sessionId, each invocation is stateless — but memory still persists. Sessions expire after 30 days of inactivity.Mandates
Mandates are scheduled autonomous agent tasks. The agent runs on a cron schedule — no user interaction required. It has access to the user’s memory and the soul’s tool permissions.- Proactive nudges (“You haven’t updated your pipeline in 5 days”)
- Background data processing and enrichment
- Periodic summaries and reports
- Scheduled follow-ups without user interaction
Roles
Roles let the same user have different agent contexts within your product. Memory and sessions are scoped per role."default" when not specified.
Multi-tenancy
Kairn is multi-tenant by design. Your API key scopes every call to your tenant. Your users’ data never mixes with another tenant’s.Data isolation
Separate DB rows per tenant. No cross-tenant memory access is possible at the query level.
Execution isolation
Each invocation runs in an isolated sandbox. Concurrent requests from different users never touch each other’s state.