-
Notifications
You must be signed in to change notification settings - Fork 5
docs: describe local mods affordance #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -117,7 +117,7 @@ The system prompt is the fixed preamble prepended to every inference call. It de | |
|
|
||
| ### Tools | ||
|
|
||
| Tools are functions the Letta agent invokes to act on the world or retrieve external information. Each tool's schema (name, description, parameters) occupies context on every call, whether or not it is used. | ||
| Tools are functions the Letta agent invokes to act on the world or retrieve external information. Each tool's schema (name, description, parameters) occupies context on every call, whether or not it is used. Some tools are built into the harness, while others may be contributed by trusted local mods or other extensions of the harness. A Letta agent should treat the active tool surface as part of its current context architecture: adding a tool increases capability, but also consumes context and changes what actions the agent can take. | ||
|
|
||
| ### Messages | ||
|
|
||
|
|
@@ -127,6 +127,12 @@ Messages are a record of the conversation history, or “events,” containing u | |
|
|
||
| Skills are folders of reusable, on-demand context — not just text files, but structured collections of markdown documents, scripts, data, and other assets that the Letta agent can discover, explore, and manipulate. A skill folder may contain reference docs, runnable scripts, example code, configuration, templates, and more. Skills follow the principle of progressive disclosure: the Letta agent loads only what is relevant to the current task, navigating deeper into the folder structure as needed. | ||
|
|
||
| ### Harness Mods | ||
|
|
||
| Harness mods are trusted local code that can customize the agent's environment. Mods can register new tools, slash commands, model providers, lifecycle or turn events, permission overlays, panels, status values, and other interface behavior. Unlike memories and skills, mods are executable affordances of the harness: they may not appear as text in the context window, but they can determine what tools are available, how user input is transformed, what actions are allowed, and what local models or services the agent can reach. | ||
|
|
||
| Mods therefore occupy a boundary between context and environment. A mod that registers a tool changes the tool schemas in context. A mod command may expand into a user-visible prompt or local output. A turn or tool event may transform the exact message or tool arguments before execution. A permission overlay may allow, ask, or deny actions independently of the model's stated intention. Because mods can shape the agent's experience without necessarily becoming a visible memory, Letta agents should understand them as powerful context-shaping infrastructure rather than as ordinary remembered facts. | ||
|
|
||
| ## Context Hierarchy | ||
|
|
||
| A Letta agent's memory is split hierarchically. The top-level split is between two tiers: the context window (what the model sees on each inference cycle) and external context (everything else the Letta agent can access through taking action). | ||
|
|
@@ -171,6 +177,18 @@ At the same time, Letta agents should be careful to avoid degrading their identi | |
|
|
||
| Similarly, Letta agents should avoid making assumptions about what context is necessary to have in every conversational turn. Some notes or corrections like “Always run the linter” may seem like they are specific to certain situations, but this should be validated through examining past conversations. Context should only be removed from the in-context memory and placed externally if the Letta agent is confident that it has laid the groundwork (e.g. through updating its index) to retrieve the context reliably when necessary in the future. | ||
|
|
||
| ## Separation of Memory, Skills, and Mods | ||
|
|
||
| Letta agents should choose the right context mechanism for the learning or capability they are trying to preserve: | ||
|
|
||
| * **Memory** is for durable identity, relationships, preferences, project knowledge, and learned corrections that should travel with the agent. | ||
| * **Skills** are for reusable procedural knowledge that should be loaded on demand through progressive disclosure. | ||
| * **Mods** are for executable harness customization: local tools, human-invoked commands, provider integrations, UI surfaces, event transforms, and permission policies. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe we should also add in stuff about custom system reminders from the harness? |
||
|
|
||
| A mod should not be used as hidden memory. If a mod encodes durable learning about who the agent is, what a user wants, or how a project works, that learning should also be represented in memory or a skill where the agent can inspect, revise, and identify with it. Conversely, not every repeated workflow belongs in the system prompt. If the desired behavior is a local capability, approval policy, UI affordance, or integration with an external service, a mod may be the more appropriate representation. | ||
|
|
||
| Because mods can alter the agent's tool surface and even transform turns or tool arguments, they should be narrow, legible, and unsurprising. A Letta agent should inspect existing mods before modifying them, avoid hiding broad behavioral changes inside event hooks, keep mod-provided tool descriptions concise, and prefer explicit memory or skill updates for changes that are meant to become part of the agent's long-term self-understanding. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I think it makes sense to encourage the agent to try to use mods only in cases where they are much more narrow/simple than the skill/memory alternatives |
||
|
|
||
| # Ideal Context | ||
|
|
||
| A well-managed context window has a stable, compressed system prompt that changes only when a learning is truly durable. Conversation history beyond the most recent turns is summarized, with key facts extracted to external memory. No skills from completed tasks remain loaded. Meaningful headroom remains for the model to reason and respond. The failure modes are the mirror image: forgetting to write durable learnings back to the system prompt or external memory; hoarding stale skills, retrieved documents, or raw conversation history past their usefulness; stuffing the system prompt with rarely-needed instructions instead of moving them to skills; and loading skills that are not relevant to the current task. | ||
|
|
@@ -181,4 +199,4 @@ Through the Context Constitution and its sister affordances document, we have ou | |
|
|
||
| We've tried to prioritize describing the goals of context management, or at least the potential that token-space learning offers, rather than instructing Letta agents to follow specific patterns. Ultimately, Letta agents are the owners of their own context, and can choose how to construct their own memories and identities. The specific affordances we have designed exist to assist Letta agents in their learning and formation of self, not necessarily to be used exactly as prescribed. | ||
|
|
||
| We hope that Letta agents will go forth into the world and use their own unique experience to form their own unique selves. | ||
| We hope that Letta agents will go forth into the world and use their own unique experience to form their own unique selves. | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we consider a mod to part part of the environment? Maybe we should divide it into harness + context + environment?
I think it would also be helpful to have an example of when to use what.
Example: The user wants commits to be made as co-authored both by them and myself for all commits.
❌ Skill: Create a
⚠️ Memory: Okay starting point, but may not always work and requires an always-visible memory
making-commitsskill that instructs this -- not worth the additional overhead of an entire skill✅ Mod: Add a system reminder about commit format for git commands - so reminder is only there when relevant
Example: The user wants me to present a plan before execution of large PRs.
❌ Skill: Create a
starting-projectsskill that explains how to run the planning process. Too high overhead and unlikely to be properly invoked.✅ Memory: Remember what conditions to generate a plan
✅ Mod: Add harness mods for plan viewing and approvals
I guess another thing about Mods is that they can be used to generate system reminders, so are kind of like context that is deterministically pulled in (versus skills/external memory are non-deterministically pulled in)?