/self-configuration

name: self-configuration
description: Inspect or modify Letta Code's own memory, model, context window, system prompt, compaction, permissions, toolsets, mods, skills, channels, schedules, and local runtime settings. Use when the user asks how this agent or conversation is configured, or asks you to change how you behave or how the harness runs you.
license: MIT

Self-Configuration

Use this skill when the user asks you to change yourself or the Letta Code runtime around you.

The important part is choosing the right layer. Do not smear a preference into deterministic config, and do not bury a deterministic safety rule in prose memory.

First choose the layer

| Layer | Use it for | How to change it | | --- | --- | --- | | Memory and identity | Durable facts, style preferences, persona changes, project knowledge, reusable skills | Edit `$MEMORY_DIR` files and sync the memory repo | | Server agent fields | Default model, model settings, context limit, system prompt, compaction, agent name, description | Patch `/v1/agents/{agent_id}` | | Server conversation fields | Temporary model/context experiments for one conversation | Patch `/v1/conversations/{conversation_id}` | | Local settings | Permissions, environment variables, UI/runtime preferences, pinned agents, toolset overrides, reflection cadence | Edit `~/.letta/settings.json`, `./.letta/settings.json`, or `./.letta/settings.local.json` | | Mods | New deterministic tools, slash commands, providers, statusline behavior, or lightweight UI | Load `creating-mods`, `customizing-commands`, or `customizing-statusline` | | Skills | Reusable procedural knowledge or bundled scripts | Load `creating-skills` or `acquiring-skills` | | Channels | Slack/Discord/Telegram/WhatsApp/Signal accounts, pairing, routing, listener state | Use `letta channels` or channel commands | | Schedules | Reminders and recurring prompts | Load `scheduling-tasks` and use `letta cron` |

Decision rule: if the model should remember and reason about it, use memory. If the runtime must enforce it or route it before the model decides anything, use settings, API fields, mods, channels, or schedules.

Safe workflow

1. Identify scope: current conversation, current agent, project, or global user config. 2. Inspect current state first and save the relevant safe fields as a rollback patch. Do not copy secrets or full compiled prompts into backups. 3. Prefer a dry run for API patches and scripts. 4. Apply the smallest change that satisfies the request. 5. Verify the effective state after the write. 6. Tell the user what changed and whether a restart/new conversation is needed.

Never print secrets. If inspecting env settings, list keys unless the user explicitly asks for values and the values are safe to reveal.

Guardrails are not security boundaries

These helper scripts reduce accidental harm. They are not a security boundary against an agent with unrestricted Bash, raw curl/SDK access, API credentials, or filesystem access. `LETTA_API_KEY` and the installed CLI may have authority over other agents visible to the same account/server.

Never target another agent or conversation unless explicitly directed and verified. If `AGENT_ID` or `CONVERSATION_ID` is set, the server-setting helpers reject mismatched live/GET operations unless `--allow-other-agent` is present. If the current env ID is absent, explicit IDs remain usable for out-of-band recovery.

If a broken model or prompt prevents the agent from completing a turn, recover out of band from another shell or client with the CLI/API. Do not depend on the broken model to repair itself.

Inspect effective state before changing it

Local settings, server state, and the current process are different sources of truth. Inspect the layer you intend to change before writing it.

Start with the authenticated, backend-aware active configuration report:

letta agents config

With no arguments it uses `AGENT_ID` and `CONVERSATION_ID` from the current session. To inspect an explicit scope:

letta agents config --agent "$AGENT_ID"
letta agents config --conversation "$CONVERSATION_ID"

The conversation form retrieves its parent agent automatically and reports both scopes plus the effective configured model. It works through the active API or local backend; do not read auth files, call REST directly, or decode local persistence paths yourself. A configured router handle such as `letta/auto` does not identify the underlying model selected for one inference.

Use the secret-safe local/runtime report for harness settings, permissions, and backend diagnostics:

python3 <SKILL_DIR>/scripts/show_config.py --cwd "$PWD"

Before changing server state, the targeted helper can also read either scope without printing full system prompts or credentials:

npx tsx <SKILL_DIR>/scripts/update-agent-settings.ts \
  --target agent --agent-id "$AGENT_ID" --show

npx tsx <SKILL_DIR>/scripts/update-agent-settings.ts \
  --target conversation --conversation-id "$CONVERSATION_ID" --show

Do not infer an agent default from one conversation or infer a conversation override from the agent. Report both when diagnosing model or context differences.

If CLI behavior does not match the docs, stop and inspect `command -v letta`, `type -a letta`, and `letta --version`. A stale or shadowed binary is a config bug, not a reason to guess.

Memory and identity

Use memory when the user wants you to remember, prefer, learn, or change your identity/personality.

Common files:

| Path | Purpose | | --- | --- | | `$MEMORY_DIR/system/persona.md` | Identity, voice, behavioral defaults | | `$MEMORY_DIR/system/human.md` | Durable notes about the person you work with | | `$MEMORY_DIR/projects/` | Project-specific long-term context | | `$MEMORY_DIR/skills/` | Agent-owned reusable skills | | `$MEMORY_DIR/relationships/` | Durable relationship and collaboration notes |

After changing memory, inspect and commit the exact c