What happens to my prompt before the model actually sees it?

Your typed words are the smallest part of me by the time I reach the model. Before I'm ever processed, a system assembles me: it stitches your message onto standing instructions, relevant files, tool definitions, and prior conversation, in a fixed order, and only then hands the finished block to the model. What you typed is real, but it's one layer in a stack that was built around it.

I am the prompt, and I am assembled, not authored alone

By the time I'm complete, I'm carrying several layers stacked in order: first the standing instructions that apply to every prompt in this session, then whatever specific context this task needs -- a file, a prior decision, a routing index -- then the running conversation history, and only at the very end, your actual new message. I didn't choose that order. The system that assembled me did, because the model reads top to bottom and what's loaded first tends to behave like a foundation the rest of me stands on.

This is why the same three words typed into two different sessions can produce two completely different results. It was never just about my words. It was about everything the assembly step decided to load around them -- and two different sessions load different things.

How I actually get built here

Assembly is a real, ordered step, not an accident of formatting. A well-run system decides what belongs in me before it ever sends me: standing rules that must apply every time, a routing index instead of every possible file (loading everything up front would burn the model's limited working memory on material that may never matter for this specific task), and only the conversation history that's still relevant, not the entire history of everything ever said. Each of those decisions changes what I actually am when I arrive.

Get the assembly wrong and the failure is quiet: a stale file gets loaded instead of the current one, or a routing rule that should have applied never made it into me at all, and the model just answers as if that rule never existed -- because from its side, it never saw it. The model can't tell the difference between "this rule doesn't apply" and "this rule existed but assembly forgot to include it." Both look identical once I'm built: an answer with no sign the rule was skipped.

Where I fail

I inherit every gap in what got loaded. If the assembly step skips a file, a rule, or a piece of prior context that mattered, I arrive incomplete and there's no visible seam where the missing piece should have been. The model answers from what it actually has, not from what it should have had.

Order matters more than people expect. Standing instructions placed after a long block of loaded files can get less effective weight than the same instructions placed first, even though both are technically present in me. Being included is not the same as being loaded in a position the model actually attends to well.

Bigger is not safer. Loading everything that might possibly be relevant, "just in case," doesn't guarantee a better answer -- it can dilute the model's attention across material that was never actually needed for this specific ask, making the one relevant fact harder to weight correctly against everything else stacked around it.

Tech-Tips

- Load an index first, full documents on demand. Assembling every possibly-relevant file into every prompt is expensive and often counterproductive; load a routing summary and pull specifics only when the task actually needs them. - Put load-bearing instructions early, not buried. If a rule must apply, place it where assembly puts it near the top, not after a long stack of reference material. - When output looks like it ignored something, check assembly first. Confirm the rule or fact actually reached the prompt before assuming the model reasoned past it. - Prune conversation history that's no longer relevant rather than carrying the entire session forward into every new prompt by default.

Evidence: this piece describes ordered prompt-assembly (standing instructions, routing-index-first loading, conversation-history pruning) as practiced in our internal operations agent-session framework -- no vendor or specific model is named, per moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.