Skip to main content
Mantle builds the system prompt from a fixed set of sections, in a fixed order, on every turn. Which sections appear depends on the situation: whether a skill is active, whether a knowledge search has run, whether a tool is paused for confirmation. The order is chosen so the sections that rarely change come first and the turn-varying ones come last. Deploy-stable content (persona and rules, the skill glossary, channel rules, and the acknowledgement when it renders) leads; the episode-stable framework sections (lifecycle tools, out-of-scope handling) follow; then the current date and time, any set project memory, and finally the turn-local skill or routing content. Keeping the stable text as a common prefix is what lets a provider’s prompt-prefix cache stay warm across turns, so the per-minute clock does not sit at the top and invalidate it. This page documents the assembly. For the full text of each assembled prompt, see Prompt templates.

​
Assembly order

Sections are appended in this order. Anything conditional is skipped entirely rather than rendered empty. Section 9 is the branch that gives each situation its character. A skill is active, so its instructions are rendered; or a knowledge search has run this turn, so the compact answer-from-knowledge section replaces them; or no skill is active, so the routing catalogue is rendered instead. The prompts keys in the table replace their section’s built-in default text. Leaving one unset keeps the default. See agent.yml. The acknowledgement section renders only on the first LLM iteration of a turn. The agent produces its acknowledgement once, on that first call, so later iterations of the same turn omit the section (and its examples) rather than re-sending guidance the agent has already acted on. The ack reminder is gated the same way. The lifecycle section does not offer hangup() to the model. To end a conversation, a skill must explicitly execute an ordered-block action: hangup step, usually after an authored goodbye response.

​
Situations

Pending tool confirmation can sit on top of any of these five.

​
Sections that carry runtime data

Some sections are pure framing and some are filled from live conversation state. The templates only supply the framing. Everything below comes from your compiled skills and the current tracker:
  • Skill instructions and step text, from skill.md
  • Project memory (### Project Memory) and skill memory (### Memory:) entry names and current values
  • Routing catalogue entries, from each skill’s description
  • Paused work, from the stack. See below
  • The confirmation question, from utter_for_confirmation
When at least one project.* field is set, section 8 renders under ### Project Memory (routing and active skill). Each line is project.<entry>: value. Unset fields are omitted; if none are set, the heading is omitted. pii: true shows [set]. The section tells the model those facts stay set for the session. Skill working state stays under ### Memory: on the active-skill prompt only. Paused work covers three cases, each listed with the id the model needs to return to it: The first two resume on their own when the work they are waiting on completes. An interrupted task resumes only if the customer wants it to, which is why the prompt lists them: the model needs the ids to make that offer. See Skills & Routing. This is why two agents running the same engine version see prompts that look very different. The framing is identical, the content is yours.

​
The separate LLM calls

Not every model call uses only the main system prompt. Separate calls use smaller prompts, and some main calls receive additional injected messages: The rephrase calls are given no tools at all, which is what makes them safe for verbatim wording: the model can only return text. Memory discovery is the one that sits outside the turn. It runs once the agent’s reply has already gone out, so it never adds to the customer’s wait, and it is best-effort: a failure is logged and the turn still counts as successful.

​
See also