The tracker
Everything that happens (messages, replies, tool calls, results, and every change to what the agent knows) is written to an append-only log called the tracker. This is the source of truth. It survives across turns and sessions; if the same user returns, the history is still there. The tracker is complete but large, which is exactly why it is not what the LLM sees each turn.Scoped context
Maestro does not dump the full log into the LLM. Each turn, at step 2 of the runtime loop, it builds a focused view: the active skill’s instructions, only the tools that are relevant right now, and the memory values that actually matter. Keeping the context tight is what keeps the agent fast and on-topic, and it’s how guardrails likeif:
markers work: a stripped branch simply isn’t in the prompt.
Memory is scoped per skill. A skill can mark values as public, and that is
how skills share results: a later skill never re-asks for something an earlier
one already collected. See Memory for the schema and
visibility rules.
Memory outlives the task
A value set during a skill stays set when that skill ends, and remains readable for the rest of the conversation. This is what stops a later skill re-asking for something the customer already said. The exception is the bundled default skills, such as the greeting and wrap-up. Those reset their own declared entries on activation so each run starts clean. Skills you write keep their values.Answering from references
When a user asks something no skill covers, Maestro searches your references and answers from what it found. If the knowledge base has no answer, the model declines through the built-incannot_help tool rather than guessing, and the bundled decline skill delivers
the message. Redeclare its responses in your own responses.yml to change the
wording.
Reference
Memory types, visibility, and access control are documented in thememory.yml reference.