Context Engineering: Give the Model Less, but Better

“Put everything in the prompt” is the agent equivalent of “SELECT *”. It works until scale, privacy, relevance, and cost arrive. Context engineering is the discipline of deciding what information the model should see right now, what should stay in deterministic systems, and what should be retrieved only when needed.

A useful architecture separates four categories: trusted runtime context, model context, authoritative business state, and memory. Mixing them creates subtle bugs.

1. Trusted runtime context

This is identity, tenant, permissions, credentials, API clients, and security metadata. It belongs in the application. The model may need the effects of this context, but it usually does not need raw credentials or the ability to rewrite its own identity.

2. Model context

This is what the model actually reasons over: instructions, the current user request, selected conversation history, relevant tool results, and retrieved knowledge. Every token should earn its place.

3. Authoritative business state

Order state, payment state, CRM stage, ticket ownership, workflow status, and permissions should live in systems of record. Conversation history can tell you what was discussed; it cannot prove what actually happened.

4. Memory

Memory itself is several things: short-lived working context, conversation history, durable user preferences, and application state. Only the first three are really “agent memory.” Workflow state should stay structured and authoritative.

1trusted runtime context  → identity / tenant / permissions2model context            → instructions / messages / selected evidence3authoritative state      → CRM / order DB / workflow / ledger4memory                   → conversation + durable preferences

Least context as an engineering principle

If a tool can return the three fields needed for the next decision, do not return the entire record. If the model needs one policy paragraph, do not inject the entire handbook. If a user asks about today’s opportunity status, query the source of truth rather than past conversation memory.

PFPLabs takeaways

• Keep identity and credentials app-side. The model should not be able to redefine its own security context.
• Treat business state as authoritative outside the conversation.
• Retrieve on demand. Do not turn the context window into a data warehouse.
• Design compact tool outputs. Context quality beats context volume.