A minimal, typed async agent runtime for OpenAI-compatible LLMs, plus a kent CLI for using it interactively from the terminal — in the spirit of opencode and hermes-agent, but small enough to read in one sitting.

The Python package is imported as agent; the installed CLI binary is kent.

• What this is
• Repo layout
• Install
• Quick start (dev)
• Getting started
  • 1. Set your API key
  • 2. Launch the REPL
  • 3. One-shot mode
  • 4. Open the live 3D palace viewer + chat
  • 5. Talk to kent on Discord
  • 6. Heartbeat: scheduled agent check-ins
• CLI reference
  • kent
  • kent run
  • kent viz
  • kent gateway
  • kent auth
  • kent models
  • kent doctor
  • Slash commands (in-REPL)
• Built-in tools
• Supported services
• Configuration
• Library use
  • Minimal example
  • Tool authoring
  • Subagent example
  • Event reference
  • Cancellation
• Testing
• Training & evaluation
  • Commands
  • Test layout
  • What's been verified live
  • Suggested next tests
• Persistent memory
  • Wings & diary
• Known limitations

Two layers in one repo:

1. A library (agent) — a ~400-line agent loop that streams events, starts safe tool calls while the model is still streaming, partitions concurrent vs. serial tools, and recovers from context-window overflow by compacting and retrying. Works against anything OpenAI-shaped: OpenAI, Atlas Cloud, Together, Groq, OpenRouter, vLLM, Ollama, llama.cpp.
2. A CLI (kent) — a small terminal front-end that auto-detects your shell, prompts for a service / model / key on first run, persists the choice, and drops you into a REPL with web-search, web-fetch, shell, and subagent tools wired up. Ships subcommands (run, auth, models, doctor) so it's scriptable too.

Web search uses DuckDuckGo HTML scraping — no third-party search API key required.

agent/
├── __init__.py        # public exports
├── cli.py             # `kent` CLI: subcommands, REPL, slash commands, persistence
├── loop.py            # the agent loop (streams events, drives tools, handles overflow)
├── llm.py             # LLM protocol + OpenAICompatibleLLM (driven by openai SDK)
├── tools.py           # Tool protocol, ToolRegistry, StreamingExecutor (concurrent/serial batching)
├── state.py           # immutable LoopState, terminal/transition reasons
├── events.py          # all event dataclasses (TextDelta, ToolCallComplete, Terminal, …)
├── compact.py         # context-window compaction + recovery
├── builtin/
│   ├── shell.py       # cross-platform shell tool (bash / wsl / powershell)
│   ├── spawn.py       # spawn_subagent: delegate a subtask with its own context window
│   ├── web_search.py  # DuckDuckGo HTML scraping (no API key)
│   ├── web_fetch.py   # URL → markdown via httpx + markdownify
│   ├── memory_recall.py / memory_recall_here.py / diary_write.py / set_wing.py
│   └── task_boundary.py  # task_start, task_end (rollout boundaries for training)
└── training/          # APO training subsystem (Microsoft Agent Lightning + MemPalace)
    ├── rollout.py            # @agl.rollout-decorated kent_task_rollout + recall_game_rollout
    ├── apo_runner.py         # train_resource() — wraps agl.Trainer.fit() with APO
    ├── palace_isolation.py   # snapshot/cleanup helpers (hardlink + SQLite/diary copy)
    ├── critic_scorer.py      # critic LLM call + JSON parse + scalar reward
    ├── swap_pair.py          # actor×critic family-collision guard
    ├── recall_games.py       # Game A: query → Layer3.search → recall@k
    ├── scope_eval.py         # Game B: counterfactual scope selection
    ├── closet_fidelity.py    # Game C: can actor answer from closet alone?
    ├── tunnel_utility.py     # Game D logger
    ├── eval_harness.py       # collusion probes + cross-critic consensus
    └── datasets.py           # TrainingExample loaders

tests/                 # pytest suite (offline + opt-in integration tests)
└── training/          # 31 tests for the training subsystem (see Training & evaluation §)

From PyPI (when published):

uv add agent

From a clone:

git clone <repo-url> kent
cd kent
uv sync

This installs the kent binary into the project venv. Either run it via uv run kent … or activate the venv (source .venv/bin/activate) and use kent directly.

The repo ships a one-shot bootstrap script that installs dependencies, validates your API keys, and drops you into a chat session:

./dev-startup.sh

What it does:

1. Runs uv sync to install all project + dev dependencies into .venv.
2. Reads credentials.json at the repo root and filters out placeholder values (anything containing <, e.g. apikey-<your-atlascloud-key-here>).
3. Merges valid keys into ~/.kent/credentials.json (chmod 0600) — the location kent resolves keys from.
4. Launches kent run "user just finished installation of kent repo" so the LLM greets you with post-install context.

Setup before running:

cp credentials.json.example credentials.json
# edit credentials.json and replace the placeholder with your real key
./dev-startup.sh

If credentials.json is missing or only contains placeholder values, the script stops cleanly after uv sync and prints kent auth instructions instead of launching chat. credentials.json is gitignored.

For Atlas Cloud (the only service wired up out of the box):

export ATLASCLOUD_API_KEY=apikey-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

…or save it persistently with chmod-600 storage:

kent auth
# prompts for the key, writes to ~/.kent/credentials.json

Resolution order: env var → saved credential → interactive prompt.

kent

You'll see:

============================================================
 kent — interactive terminal AI agent
============================================================

[environment]
  OS         : Darwin 24.3.0
  Python     : 3.13.0
  Shell tool : bash (macOS)  (/bin/bash)

[web search]
  Provider   : DuckDuckGo HTML  (https://html.duckduckgo.com/html/)
  API key    : none required
  Notes      : DDG may rate-limit; this is best-effort scraping.
               No queries are sent to any third-party search API.

[llm setup]
Service (atlascloud) [atlascloud]:
Model (qwen/qwen3.6-35b-a3b) [qwen/qwen3.6-35b-a3b]:

[ready]
  Service: Atlas Cloud  (https://api.atlascloud.ai/v1)
  Model  : qwen/qwen3.6-35b-a3b
  Tools  : web_search, web_fetch, shell, spawn_subagent
  Type your message. /help for slash commands. /exit to quit.
------------------------------------------------------------

you>

After the first run, ~/.kent/config.json remembers your service and model — subsequent launches just press-Enter through the prompts.

Skip the REPL when you only want a single answer:

kent run "What's in my current directory?"
kent run "Find the latest Python release version" --quiet     # suppress tool-call chatter
kent run "Summarize https://peps.python.org/pep-0008/"

Exits 0 on success, 1 on model_error / context_overflow / tool_loop, 2 on missing config.

kent viz starts a tiny localhost web server that renders your MemPalace as an animated 3D force-directed graph and gives you a chat panel so you can talk to kent in the same window. As the agent's tool calls (diary_write, set_wing, memory_recall, …) hit disk, you watch new drawers bloom into the graph in real time.

kent viz                       # start on the default port (8765)
kent viz --port 9000           # pick a different port
kent viz --read-only           # graph only, no chat panel (no API key needed)

You'll see:

kent viz [chat+graph] → http://127.0.0.1:8765

Open that URL in any modern browser. Ctrl-C in the terminal to stop the server.

The page is one static HTML file with two SSE streams under the hood: /events pushes a fresh palace snapshot whenever the on-disk mtime ticks (~1 s), and POST /chat streams agent events back into the right-hand chat column. No build step, no npm — 3d-force-graph and three.js load from cdn.jsdelivr.net on first paint.

Requirements: mempalace must be installed (it is, by default — uv sync pulls it in). For the chat panel, kent auth (or ATLASCLOUD_API_KEY) must be set; pass --read-only to skip the LLM/auth setup. The server binds 127.0.0.1 only — there is no auth, by design.

kent can also live on Discord as a bot — read messages, reply, react, manage threads, set presence — with each channel/DM mapped to its own memory wing. The gateway is a managed background service; once a token is saved, dev-startup.sh auto-starts it alongside kent viz.

kent gateway config             # paste your bot token (see docs/gateway.md for app setup)
kent gateway test --send        # smoke test: connect, verify channel, post one marker
kent gateway start              # detach the daemon
kent gateway status             # is it running? where's the log?

See docs/gateway.md for the full Discord application walkthrough (creating the app, enabling intents, generating an invite URL).

The gateway can fire a periodic, agent-driven "heartbeat" turn on a configurable cadence — kent stays alive between user mentions instead of sitting idle. Each tick reads ~/.kent/HEARTBEAT.md (free-form Markdown you control), runs one full agent turn with that file as the prompt, and lets the agent decide whether to post via discord_send, write a diary entry, run a search, etc.

# Configure interval + channel (or let dev-startup.sh prompt you on first run)
kent gateway config --heartbeat-interval 30m --heartbeat-channel-id 1234567890

# Edit what kent does each tick
$EDITOR ~/.kent/HEARTBEAT.md

# Confirm it ran
kent gateway status            # shows last_heartbeat_at / last_heartbeat_status

Accepted intervals: 30s, 5m, 30m, 1h, etc. Set to off (or leave unset) to disable. The file is re-read every tick, so you can edit HEARTBEAT.md live and the next tick picks up the new instructions without a restart.

dev-startup.sh will:

1. Prompt for an interval (default 30m) and a Discord channel id on first run, persisting both to ~/.kent/config.json.
2. Seed ~/.kent/HEARTBEAT.md with a starter template if the file is missing.
3. Run kent gateway test --send as a connectivity smoke test — token, intents, channel access, and send permission — before spawning the long-lived gateway.
4. Spawn the gateway and poll gateway.status.json until on_ready fires (up to 20s) so token errors surface immediately instead of hiding in gateway.log.

Skip the prompt with KENT_NO_HEARTBEAT=1; skip the smoke test with KENT_NO_GATEWAY_TEST=1; skip the gateway entirely with KENT_NO_GATEWAY=1.

Launch the interactive REPL. No arguments. Prints the banner, environment, and web-search notice; prompts for service / model / key (using saved values as defaults); enters a streaming REPL loop.

kent run <prompt> [--service ID] [--model ID] [--quiet]

kent viz [--port N] [--read-only]

Launches the live 3D palace viewer + chat panel on http://127.0.0.1:<port>. The graph auto-updates from the on-disk palace via mtime polling; the chat panel runs the same agent stack as kent / kent run and writes back into the same palace.

Exits 0 on Ctrl-C, 1 if mempalace isn't importable, 2 if chat is enabled but no API key is configured (run kent auth or pass --read-only).

kent gateway [run|start|stop|restart|status|config|test] [flags]

Runs kent as a Discord bot. Each channel/DM maps to its own memory wing (discord_<guild_id>_<channel_id> or discord_dm_<user_id>). Discord tools (discord_send, discord_react, discord_thread_create, discord_set_status, discord_read_history) are registered into the bot's tool registry — they are not available in the local REPL or kent run.

Flags for run / start / restart:

Flags for test:

Status side-files: ~/.kent/gateway.pid is written at start; ~/.kent/gateway.status.json is updated on connect and per new channel session — both are removed on kent gateway stop.

Requires discord.py (installed via uv sync once pyproject.toml is updated). See docs/gateway.md for the Discord application walkthrough.

kent auth [--service ID] [--clear]

Save (or clear) an API key for a service. Stored at ~/.kent/credentials.json with chmod 0600 attempted.

kent models [--service ID]

Lists the models available for a service. Marks the default with (default) and the currently-active saved choice with *.

kent doctor

Health check. Prints OS / shell backend, web-search provider, config-file paths, per-service credential status (env var present? saved credential present?), and a dependency-import check. Useful first thing to run if anything misbehaves.

† Discord tools are only registered inside kent gateway run; they require a live Discord WebSocket and won't appear in kent REPL or kent run.

Concurrency-safe tools batch and run in parallel via StreamingExecutor; unsafe tools (like shell) serialize so they can't race state mutations.

Adding a new service: edit SUPPORTED_SERVICES in agent/cli.py — it's a dict literal. For library use, just instantiate OpenAICompatibleLLM(base_url=..., api_key=..., model=..., context_window=...) directly.

Files live under ~/.kent/ (override with KENT_HOME=/some/path):

Override with environment:

import asyncio
from pydantic import BaseModel
from agent import run, ToolRegistry, ToolResult, OpenAICompatibleLLM, TextDelta, Terminal

class EchoTool:
    name = "echo"
    description = "Echo back the input text"
    class Args(BaseModel):
        text: str
    input_model = Args
    def is_concurrency_safe(self, args): return True
    async def call(self, args, ctx):
        return ToolResult(call_id="", output=args.text)

async def main():
    llm = OpenAICompatibleLLM("http://localhost:11434/v1", "ollama", "llama3.2", context_window=8192)
    registry = ToolRegistry()
    registry.register(EchoTool())
    async for ev in run(messages=[{"role": "user", "content": "say hello"}], tools=registry, llm=llm):
        if isinstance(ev, TextDelta):
            print(ev.text, end="", flush=True)
        if isinstance(ev, Terminal):
            print(f"\n[{ev.reason}]")

asyncio.run(main())

from pydantic import BaseModel
from agent import ToolResult, ToolContext

class MyTool:
    name = "my_tool"               # unique tool name
    description = "What it does"   # shown to the model
    class Args(BaseModel):
        path: str                  # Pydantic model for arguments
    input_model = Args
    def is_concurrency_safe(self, args) -> bool:
        return True   # True = may run in parallel with other safe tools
    async def call(self, args: Args, ctx: ToolContext) -> ToolResult:
        return ToolResult(call_id="", output=f"result for {args.path}")

from agent import ToolRegistry, OpenAICompatibleLLM
from agent.builtin.spawn import Spawn

registry = ToolRegistry()
llm = OpenAICompatibleLLM(...)
registry.register(Spawn(parent_registry=registry, llm=llm))
# model can now call spawn_subagent to delegate subtasks

Pass signal: asyncio.Event to run(). Set it from another task to abort:

signal = asyncio.Event()
asyncio.create_task(cancel_after_timeout(signal))
async for ev in run(..., signal=signal):
    ...

uv run pytest -m "not integration and not memory and not slow"   # offline suite (default)
uv run pytest tests/training/                                    # training subsystem only
uv run pytest -m live_apo -v -s                                  # live LLM + APO tests (Atlas Cloud key required)
uv run pytest -m live_discord -v -s                              # live Discord gateway (requires KENT_DISCORD_BOT_TOKEN + KENT_DISCORD_TEST_CHANNEL_ID)
uv run pytest tests/integration/                                 # live mempalace / ollama

The offline suite covers the agent loop, streaming executor, compaction, the Spawn subagent, every built-in tool, and the full training subsystem (palace isolation, critic scoring, swap-pair guard, recall games, rollout pipeline). 196 tests, all green in ~2.3s.

The training subsystem optimizes kent's prompt resources via Microsoft Agent Lightning's APO (Automatic Prompt Optimization) — see the plan. Two CLI entry points and a tiered test ladder validate it.

kent train --resource query_rewrite_policy \
    --pair qwen/qwen3.6-35b-a3b+qwen/qwen3.6-35b-a3b \
    --apo-base-url https://api.atlascloud.ai/v1 \
    --gradient-model qwen/qwen3.6-35b-a3b \
    --apply-edit-model qwen/qwen3.6-35b-a3b \
    --rounds 1 --runners 1 --train-size 3 \
    --skip-collusion-check          # only when actor and critic share a family

kent wake-up --duration 5m          # run recall self-improvement games against the live palace

--examples-dir DIR loads real training examples (one JSONL per file, line shape {task_id, prompt, ...}). Without it, synthetic prompts are used (smoke-test only).

The current ladder validates pipeline plumbing and the training signal (better queries → better embedding scores). What's not yet proven: that APO discovers better prompts, and that the other plan resources (scope_policy, closet_summary_policy, actor_system_prompt) train cleanly. Order by value/effort:

1. Sequential resource freezing test (unit, fast). Save a fake optimized actor_system_prompt.txt to lightning_store/resources/, run a rollout for retrieval_policy, assert the frozen actor prompt is concatenated into the system prompt. Exercises plan line 47 directly.
2. Collusion probe trip-wire (unit, fast). Mock a critic that scores 5/5 on bad outputs; assert cmd_train aborts with the right exit code. Plan line 138 calls it "mandatory" — currently only validated by the eval_harness unit test, not the cmd_train wiring.
3. Game B scope_eval live test (live_apo, ~3 min). Replay queries at three scopes, assert the critic-picked scope matches the seeded wing. Plan line 26.
4. Game C closet_fidelity live test (live_apo, ~3 min). Sample a closet, generate question, assert actor can answer from closet alone. Plan line 27. Stratify by drawer source (transcript vs diary).
5. Multi-round APO improvement test (live_apo, slow). Run APO with n_rounds=3 on query_rewrite_policy and assert val_reward at round 3 ≥ val_reward at round 1. The first concrete claim that APO actually improves the prompt — currently only ran round 01.
6. Trained-vs-baseline efficacy (live_apo, slow). Run rollouts with the saved optimized prompt vs the seed, count drawer-content hits in the actor's response. Plan verification step 4.
7. APO shutdown-hang fix or workaround. Either a documented os._exit(0) after assertions in slow tests, or upstream issue against agentlightning/agentops. Currently blocks CI on test_apo_train_query_rewrite_policy_atlas.
8. Concurrent-rollout stress test (slow). 10 parallel kent_task_rollout calls against the same palace; assert no SQLite or diary corruption. Plan critical risk #4 says n_runners=4 multiplies race risk; we have one tiny test for two parallel rollouts but nothing at scale.
9. Wing-scoped recall A/B. Same shape as test_retrieval_policy_ab_against_atlas but using memory_recall_here to test that wing routing actually narrows results.

Kent has long-term, cross-session memory on by default. It's powered by MemPalace, a local-first, ChromaDB-backed store that requires no API key and runs entirely on your machine.

There is nothing to enable. The first time you launch kent, kent run, or call agent.run(...) from your own code, a palace is created at ~/.kent/palace and every conversation turn from that point on is persisted. The next session — same machine, hours or weeks later — recalls relevant context automatically.

Kent owns its own ChromaDB palace at ~/.kent/palace (configurable via $KENT_HOME). It does not share the default mempalace location at ~/.mempalace/palace, so kent's verbatim conversations stay isolated from other mempalace consumers (mempalace mine, the MCP server, etc.) on the same machine.

To opt out as a library consumer, pass any object implementing the 3-method MemoryStore protocol — for example, a no-op stub:

class NullStore:
    @property
    def session_id(self): return "no-memory"
    def record_turn(self, messages, *, session_id): pass
    def wake_up(self): return ""
    def recall(self, query, k=5): return ""

async for ev in run(messages=[...], tools=registry, llm=llm, memory_store=NullStore()):
    ...

Kent uses a deliberately small surface of mempalace's API. The full library ships 29 MCP tools, a CLI, and four memory layers; we reach into three submodules and ignore the rest.

Sweeper-ingested turns carry no wing metadata. Mempalace's sweeper.sweep() does not write a wing field to drawer metadata — only diary_ingest and a few other paths set wings. Kent achieves palace isolation by owning a separate ChromaDB at ~/.kent/palace instead of sharing ~/.mempalace/palace with other tools. Wings are used exclusively for the diary path (see Wings & diary).

What we don't use from MemPalace on the sweeper path:

• mempalace.convo_miner.mine_convos — batch-import for an existing corpus. Kent streams live via sweep per turn.
• The 29 MCP tools — kent isn't an MCP host; mempalace is used as a Python library.
• Direct ChromaDB writes — sweep handles dedup. We never reach into the chromadb collection ourselves.

   user types "remember my favorite color is octarine"
              │
              ▼
   ┌───────────────────────────────────────┐
   │ agent.run(...) → loop.py turn         │
   │   model streams; tools run; assistant │
   │   message + tool results form a turn  │
   └───────────────────────────────────────┘
              │  end-of-turn (any terminal: completed, max_turns,
              │   tool_loop, model_error, context_overflow, aborted)
              ▼
   MemPalaceStore.record_turn(messages, session_id=…)
              │
              ▼
   ┌─────────────────────────────────────────────────────┐
   │ 1. append_messages → JSONL line per message in      │
   │    Claude-Code format at                            │
   │    ~/.cache/kent/transcripts/<session_id>.jsonl     │
   │    • role: user / assistant / tool_use / tool_result│
   │    • sessionId, uuid, timestamp, content            │
   └─────────────────────────────────────────────────────┘
              │
              ▼
   ┌─────────────────────────────────────────────────────┐
   │ 2. mempalace.sweeper.sweep(...)                     │
   │    • parses JSONL                                   │
   │    • generates deterministic drawer IDs             │
   │      `sweep_<session_id>_<message_uuid>`            │
   │    • upserts into ChromaDB at ~/.kent/palace        │
   │    • idempotent: re-sweep is a no-op                │
   └─────────────────────────────────────────────────────┘

On the read side, two paths surface stored memory back to the model:

1. Wake-up injection (proactive). At session start the REPL/CLI calls MemoryStack.wake_up(), wraps the result in <recalled-memory>…</recalled-memory>, and prepends it as a system message. When maybe_compact fires mid-session, the same wake-up text is embedded inline in the new summary message — so the priming refreshes after every compaction instead of being lost when the head is summarized away.

2. memory_recall tool (on-demand). The model can call memory_recall(query, k=5) whenever a question references prior context. This routes to Layer3.search, which does semantic vector search over all drawers and returns formatted text the model can quote back.

The two paths are complementary: wake-up gives the model passive priming with the most "essential" L1 moments; memory_recall gives it active retrieval for specific queries that wake-up didn't surface.

Kent supports wings — named project/intent contexts — and a per-wing agent diary that captures the model's observations, findings, decisions, and recurring patterns across sessions.

All wing state lives under ${KENT_HOME} (default ~/.kent/):

~/.kent/
├── palace/                     # ChromaDB — conversation turns (sweeper path)
├── active_wing.txt             # one line: current wing name
└── diaries/
    ├── kent_default/
    │   ├── .intent.txt         # one-line wing description
    │   ├── 2026-04-27.md       # today's diary entries
    │   └── 2026-04-28.md
    └── prod-deploys/
        ├── .intent.txt
        └── 2026-04-27.md

The directory layout is the wing registry. list_wings() = ls ~/.kent/diaries/. No separate registry file.

Wings are created on demand. When the model encounters a new project intent:

1. Model calls set_wing(name="prod-deploys") — no wing exists yet → returns an error telling the model to ask the user for a one-line description and re-call.
2. User confirms; model calls set_wing(name="prod-deploys", intent="monitor terraform deploy pipeline").
3. Wing directory and .intent.txt are written; store switches to that wing.

You can also switch wings directly from the REPL:

/wing prod-deploys        # switch (must exist)
/wings                    # list all wings with intents
/wing                     # show current active wing
kent --wing prod-deploys  # set wing for the whole session

/diary the build slowed 30% after midnight

…or the model calls diary_write(kind="OBSERVATION", text="...", topic="builds").

Valid kinds: OBSERVATION, FINDING, DECISION, PATTERN.

Entries are appended to ~/.kent/diaries/<wing>/YYYY-MM-DD.md under fcntl.flock and immediately ingested into ChromaDB via mempalace.diary_ingest.ingest_diaries. The format matches the diary spec from mempalace:

# 2026-04-27

## 14:32:01 [agent=kent] [OBSERVATION] builds
The build pipeline got 30% slower after midnight.

## 15:08:44 [agent=kent] [DECISION] feature-flags
Decided to gate the new ranker behind FF_RANKER_V2.

Two surfaces:

Wing-scoped recall is diary-only. Turn transcripts ingested by sweeper.sweep() carry no wing metadata, so memory_recall_here only surfaces diary entries (written via diary_write). Use memory_recall for cross-session turn retrieval.

• Diary is append-only. Editing requires manually modifying the .md file and re-running ingest with force=True. /forget only removes the current session's turn transcript — diary entries persist.
• Wing rename/delete not supported in v1. Renaming orphans drawers (different (wing, date) hash in ChromaDB). Work around with rm -rf ~/.kent/diaries/<old> + manual ChromaDB cleanup.
• Secrets caveat applies to diaries too. Anything written to a diary entry is stored verbatim in ChromaDB. Use mempalace tools or rm -rf ~/.kent/palace to wipe.
• ~/.mempalace/state/ side effect. ingest_diaries writes a small state file under ~/.mempalace/state/ (hard-coded inside mempalace). The file is SHA-keyed by (palace_path, diary_dir) so no collision is possible with other mempalace tools. You can delete it freely.
• Subagents inherit the active wing. When spawn_subagent is called, the subagent shares the parent's MemPalaceStore and therefore the same active_wing. Wing mutations by a subagent via set_wing affect the parent's state on the next turn.

• Recording fires on every terminal reason. The loop calls record_turn on completed, next_turn, model_error, max_turns, tool_loop, aborted, and context_overflow. A crashed turn is captured up to the last completed message, not lost.
• Backend errors never break a conversation. All three MemPalaceStore methods (record_turn, wake_up, recall) are wrapped in try/except with logging.warning. A broken palace, a chromadb upgrade glitch, or a corrupt drawer surfaces as a warning in the log; the loop carries on.
• JSONL is a write buffer, not the source of truth. Per-session JSONL files at ~/.cache/kent/transcripts/ are append-only and accumulate. The durable store is the ChromaDB palace. You can wipe the transcript dir at any time without losing memory.

kent doctor includes a [memory] block:

[memory]
  palace     : /Users/you/.kent/palace  (exists: True)
  transcripts: /Users/you/.cache/kent/transcripts  (exists: True)
  drawers    : 1247
  last-write : 2026-04-27T09:04:22

drawers comes from MemoryStack.status(); last-write is the most recent mtime among palace files. Both are 0 / <never> until the first turn is recorded.

• Secrets are stored verbatim. Anything echoed in a conversation — API keys leaked through shell output, .env contents read by a tool, password fragments — ends up in the palace as searchable text. /forget removes the current session's JSONL buffer, but already-swept drawers persist; use mempalace's own tools to clear them, or rm -rf ~/.kent/palace to wipe everything.
• First import is heavy. MemPalace pulls in chromadb (~300 MB) and downloads a ~80 MB ONNX model on first use for embeddings. Kent lazy-imports mempalace inside MemPalaceStore.__init__, so import agent itself stays light — the cost is paid on first record_turn / wake_up call.
• Subagents share the parent's store. When kent spawns a subagent via spawn_subagent, it threads the same MemPalaceStore through. Concurrent sibling-spawn writes are unverified — see Known limitations.
• No per-project scoping. Kent uses one palace at ~/.kent/palace for everything. If you want per-project isolation today, set $KENT_HOME to a project-specific directory before launching.

• No built-in retries or rate limiting — wrap run() yourself if needed.
• No timeouts on tool calls — use signal for cancellation (the shell tool has its own per-command timeout).
• No Anthropic-native API — use a litellm proxy or OpenAICompatibleLLM with an OpenAI-format endpoint.
• No live integration tests in CI — run tests/integration/ manually with OLLAMA_HOST set.
• DuckDuckGo HTML can rate-limit aggressive use; web_search is best-effort scraping, not a contracted API.
• Concurrent subagent memory writes are unverified. When a Spawn-ed subagent shares the parent's MemPalaceStore, sibling subagents writing to the same JSONL transcript and ChromaDB upsert path concurrently may race. Safe today because subagents typically serialize their own LLM calls; revisit if you parallelize many spawns.
• Transcript buffer grows unbounded. Per-session JSONL files under ~/.cache/kent/transcripts/ are never pruned. They are a write buffer; the durable store is ChromaDB. Sweep / delete the directory yourself if it grows large.