Kendr is built around a real runtime, not a loose chain of prompts. Requests move through discovery, planning, execution control, and saved state.
Every request moves through the same structured control plane before it becomes an answer, artifact, or governed action.
Input arrives through CLI, gateway, or Web UI carrying context like working directory, project root, channel/session metadata, and optional workflow hints.
The runtime builds a unified registry of available capabilities, then applies a setup snapshot so only eligible actions remain available.
Built-in
20+
task agents
Plugins
∞
via ./plugins
MCP
∞
synthetic agents
Models
Multi
execution lanes
Once the eligible surface is known, Kendr classifies the request and chooses the right lane: direct tools, explicit workflows, or planner-driven execution. This is where the runtime stops being generic chat.
A typed RuntimeState is constructed. The runtime decides whether this is deep research, local-drive, superRAG, project workbench, OS command, long-document, or general planning work.
Planner-backed runs are safety-classified. Conservative read-only plans can auto-approve, while risky or mutating work pauses for human review before any consequential action is taken.
Approval Required
The orchestrator has planned a 4-step workflow that includes file writes and 3 external API calls. Review and approve to continue.
Kendr executes safe read-only batches in parallel where possible and keeps risky or write-heavy work serialized. Each step records messages, artifacts, work notes, session state, and orchestration events into SQLite.
Messages
All agent outputs stored
Artifacts
Files and data outputs
Execution trace
Full step-by-step log
Checkpoints
Resumable state snapshots
Session state
Context continuity
Run manifest
Complete run summary
On completion, the runtime writes final outputs, session summaries, and manifests. On failure, a recovery checkpoint allows safe resume from the last stable state. Nothing is lost.
Under the hood, Kendr is split into six layers that keep research, execution, and memory working together.
CLI, Gateway HTTP surface, Web UI, and Project Workbench UI — all backed by the same runtime engine.
State initialization, workflow typing, planning, approvals, execution control, recovery.
Built-in agents, plugin agents, and tool capabilities unified in one registry.
Local-drive ingestion, OCR, vector search, superRAG sessions, source-aware synthesis.
SQLite-backed runs, tasks, artifacts, sessions, checkpoints. File-based agent memory that's human-readable.
Setup-aware controls, scoped security, checkpoints, kill-switch support.