Skip to main content

​
Overview

Kheish is a daemon-first agent runtime. Instead of embedding an agent loop inside a single process, it treats the daemon as the source of truth for execution state, orchestration, approvals, and external integrations. Clients interact with Kheish over HTTP and Server-Sent Events. A CLI, webhook, Slack bot, Telegram bot, or another service can all target the same daemon and the same long-lived session.

​
Product model

Kheish is built around a small set of persistent runtime objects:
  • Personas are daemon-managed mutable instruction records that future sessions can bind.
  • Sessions are durable units of work backed by an append-only journal and optional checkpoints.
  • Runs are concrete executions triggered by input, approvals, user-question answers, schedules, or mailbox activity.
  • Playbooks are immutable, digest-covered procedure manifests with separate release state.
  • Flows are daemon-owned projections that correlate one Playbook version to normal sessions, runs, approvals, agents, and evidence.
  • Projects are daemon-owned coordination resources that bind durable membership, linked channels, and project tasks over multiple sessions.
  • Project tasks are daemon-owned work items that can own assignment, dependencies, discussion threads, and one latest associated run.
  • Channels are daemon-owned public conversation spaces backed by their own durable message and reaction log.
  • Routes are daemon-owned execution identities that bind one route_id, one default/current model, and one auth_ref.
  • Assets are daemon-owned files referenced by sessions and runs for document, image, and retained audio input.
  • Agents are execution contexts in a hierarchy, including parent agents and sidechains.
  • Session tasks are structured execution-scoped work items with ownership, status, and dependencies inside one session.
  • Approvals and user questions are suspension points that let the runtime stop, wait, and resume safely.
  • Outputs are normalized response envelopes that can stay local to the daemon or be routed externally.
  • Connectors are daemon-managed transport definitions used for ingress and, when applicable, reply routing.

​
Why daemon-first matters

The daemon-first model changes how agent systems behave in production:
  • state survives client disconnects and daemon restarts
  • approvals can be resolved asynchronously by another client
  • runs are observable and controllable independently of the original caller
  • sessions can pin one persona snapshot without being rewritten when the source persona record changes later
  • shared conversations can live in channels without collapsing multiple agents into one shared session
  • ingress and egress can be attached through connectors and output plugins
  • transport configuration can stay daemon-global while sessions keep their own durable reply-target defaults
  • files can be stored once and reused across later runs through stable asset identifiers
  • route, auth, model, and permission changes can be applied live without rebuilding a caller
The route/auth split is operationally important:
  • runs select a daemon-owned route_id, not raw credentials
  • routes resolve credentials through stable auth_ref slots owned by the daemon
  • operators can update one secret slot without rewriting every route file or redeploying every client

​
What Kheish is optimized for

Kheish is a good fit when you need:
  • long-lived sessions rather than stateless request-response interactions
  • explicit control over tool execution, permissions, and auditability
  • a shared control plane for multiple clients and integration points
  • resumable workflows that may wait on human input or external systems
  • one runtime that can mix direct API input, hooks, schedules, sidechains, and connector traffic

​
What Kheish is not

Kheish is not primarily an embedded agent SDK, a prompt library, or a stateless completion wrapper. It is an operational runtime intended to own the lifecycle of agent execution.