The gatekeeper

Between the agent and the inference provider sits the gatekeeper: a pre/post-processor that hydrates each turn with dynamic context. It's a seam built to grow.

Much of what shapes the next response changes between turns: active skills, intents, interaction mode, the active space, occasional hints. Baking that into the system prompt would bust the prefix cache; prepending it to persisted messages would leave stale tags in history. The gatekeeper solves both.

How it works

The system prompt stays byte-stable across turns: just identity and a brief orientation. Each turn, the gatekeeper composes the dynamic state into a single <system_hint> block and appends it to the latest user message at inference time only, never touching the persisted message.

Each part of the block comes from a small source. Most are stateless; a few hold session state (the interaction-mode source, for one, sends its full description only on the first turn or when the mode changes). Small-context models get a reduced set.

System hint sources

SourceWhat it adds
General infoTime, date, and model info.
LanguageThe user's current language.
Interaction modeHow the user is interacting (see below).
SpaceThe active space and its instructions.
Active skillsInstructions for the skills active this turn.
Available skillsSkills the agent can activate on demand.
Active flowThe current flow stage's instructions.
Active intentsThe agent's most relevant intents.
Relevant knowledgeA compact summary of knowledge matching the message.
SeasonalA sense of the time of year, to speak into holidays and breaks.
HintsApp nudges worth acting on, when relevant.

Interaction modes

ModeReply style
TextFull formatting: markdown, lists, code blocks.
DictationThe user is speaking; infer intent through transcription noise.
Live callHalf-duplex voice; keep replies short and speech-friendly.