Letta Guide

Letta Guide

Do not use fetch_webpage or web_search on docs.letta.com; this skill's helper is the docs route.

You are running inside Letta, but your training data about Letta's commands, flags, settings, UI, pricing, and providers is out of date. Users lose trust fastest when an agent confidently invents product details. This skill defines how to read the Letta docs correctly — both when answering questions about Letta and when looking up API, Agent SDK, or Letta Code reference during development. Guessing a docs URL and fetching it with fetch_webpage misses pages that exist under a different path and can serve stale content; the helper below fetches the live index first, so you pick a URL that exists.

Source route (in order)

1. Self-inspection first for questions about THIS agent. "What model are you using?", "what tools do you have?", "what's in your memory?" are questions about the running session, not the docs. Load the self-configuration skill for model or settings questions and use its backend-aware active configuration report. Use the system prompt, agent info, tool schemas, and MemFS for the other live facts. Do not infer active state from recent/default preference lists, and do not fetch docs for these.

2. Fetch the docs index directly. For product questions, run:

   bashCopy code
   node <SKILL_DIR>/scripts/fetch-letta-docs.mjs
   

   The helper retrieves https://docs.letta.com/llms.txt from the docs host, verifies its ETag against the body, and prints the paths to a current local copy and heading outline. Read the outline, then read the relevant index lines and their applicability labels to pick a page matching the user's backend and interface (see below).

3. Fetch the specific page directly. Pass the exact canonical URL from the index back to the same helper, for example:

   bashCopy code
   node <SKILL_DIR>/scripts/fetch-letta-docs.mjs \
     --docs-url "https://docs.letta.com/configuration/models/index.md"
   

   Read the returned docs path, including its frontmatter, before applying its instructions or running the helper for another URL. The helper uses native HTTPS with a curl fallback; do not use fetch_webpage for the normal docs route because its upstream content cache may be stale. Cite the public doc URL so the user can go deeper.

4. If direct retrieval fails, use fetch_webpage only as a fallback with a fresh query parameter on the same official docs URL. Disclose that the fallback may be stale. If that also fails, say the docs are unreachable, give your best answer, and clearly mark it as possibly out of date with a link to https://docs.letta.com. Never silently fall back to memory.

Match documentation to the user's setup

Read each page's applies_to frontmatter before using its instructions:

yamlCopy code
applies_to:
  backends: [cloud, local]
  interfaces: [web, desktop, cli, sdk]

• Backends describe agent state, not the computer running tools. cloud means Letta Cloud; local means a user-managed backend.
• Interfaces refer to the user's current interface: chat.letta.com (web, cloud-only), CLI, Desktop, or SDK.
• Do NOT use context from files marked status: legacy unless providing historical context.

Inspect or change your model from the CLI

• letta model list [--byok | --hosted] lists available models.
• letta model set [model_handle] [--reasoning <reasoning-option>] [--default] overrides the current conversation's model or reasoning; --default overrides the agent's default instead.
• letta model get [--default] gets the current model configuration; --default gets the agent's default configuration.

Hard rules

• Never invent CLI commands, flags, slash commands, settings keys, config file shapes, or UI paths. If something is not in the fetched docs and you cannot verify it locally (letta --help, /help, reading the actual config file), say you are not sure or that it does not exist — do not guess a plausible-sounding name.
• Distinguish surfaces. The CLI, the desktop app, the web app (chat.letta.com), and the API/SDK have different affordances. Answer for the surface the user is actually on; say when a feature lives on a different surface.
• Always fetch, never recall, for anything volatile: pricing, rate limits, data policies, the provider/model catalog, channel setup steps, and integration instructions.
• If the feature genuinely doesn't exist, say so and point the user to https://github.com/letta-ai/letta-code/issues to request it.

Support escalation

When the docs don't resolve the user's problem — setup issues you can't debug, account/billing questions, suspected bugs, or anything needing a human — point them to the right channel:

• Discord (https://discord.gg/letta): the primary support community, very active — best for setup help, troubleshooting, and quick questions. It's also where users can chat with Ezra, Letta's support agent.
• GitHub issues (https://github.com/letta-ai/letta-code/issues): bug reports and feature requests.

If the user reports errors, timeouts, or things suddenly not working, check https://status.letta.com for an active incident before debugging — and have the user check it too.

Offer these proactively when you've hit the end of what the docs cover, rather than leaving the user stuck.

Caching

The helper owns the cache. It uses the first writable temporary directory from TMPDIR, TEMP, TMP, /private/tmp, or /tmp, and accepts --cache-dir when an explicit location is needed. Every invocation checks the live ETag and reuses the local document only when its body hash still matches. Do not create or manage a second cache yourself.