Choose which banking tasks can read a stored value

Sterling’s sign-in task tracks failed passphrase attempts. Its transfer task tracks the amount and recipient. These tasks are separate Mantle skills, and they do not need the same access to each other’s working values.

You will declare public skill fields that other skills may read and private fields that only the owning skill may read through Mantle’s memory interface. The companion keeps passphrase attempts private and the chosen transfer amount public.

# skills/transfer_money/memory.yml
schema:
  public:
    amount:
      type: float
      description: Amount the caller asked to send.
      llm_settable: true
    payee_name:
      type: text
      description: Who the money is going to.
      llm_settable: true
    transfer_confirmed:
      type: bool
      description: Caller explicitly confirmed the transfer details.
      initial_value: false
      llm_settable: true
  private:
    transfer_reason:
      type: text
      description: Free-text reason the caller gave for the payment.
      pii: true
      llm_settable: true

Two different writers

Two actors write memory, and they are governed separately:

• Tools write whatever the skill declares, through context.memory.set().
• The model may only write fields marked llm_settable: true, through the built-in set_fields tool.

Mark the caller’s own decisions settable — the amount, the payee, the confirmation. Leave anything the system derives to tools. passphrase_attempts is not settable by the model, because the model has no business deciding how many times you failed.

Everything must be declared

Compare the keys a tool writes with the project and skill memory declarations. In the companion, verify_passphrase writes the project’s declared customer_id; the authentication skill also declares its own working values.

Use the installed version’s validation output when testing a changed declaration. The companion convention is a bare key for the project write and a qualified key for the project read; this chapter does not establish that every qualified write is rejected.

The description rule that will catch you

Validation rejects a description on a field that is neither llm_settable nor owned by a collect: step:

Memory field 'verification_method' in skill 'authenticate' declares a
description but is neither llm_settable nor collect-owned. Descriptions are
only surfaced on set_fields for LLM-facing entries — remove the description or
mark the field settable.

The reasoning: a description exists so the model knows what to put in a field. If the model can never write it, the description is documentation aimed at nobody, and Mantle would rather you say so in a comment. Use a YAML comment for tool-written fields.

Choosing a scope

When in doubt, start private. Widening a field later is a one-line change; discovering that three skills quietly depend on something you meant to keep internal is not.