Context Engineering Has a Missing Input: The Human on the Other Side

Teams building with LLMs have gotten sophisticated about retrieving documents, structuring tools, and managing token budgets. Almost none of that effort goes toward the one input that determines whether a response actually lands: who is asking.

Published 2026-07-21 · 6 min read

Context Engineering Has a Missing Input: The Human on the Other Side

The Discipline That Formed Around the Window

Prompt engineering was a phase. Context engineering is a discipline.

The shift happened because teams building serious LLM applications discovered that the model was rarely the bottleneck. The bottleneck was what went into the window. So an entire practice grew up around that problem: retrieval strategies, chunking schemes, reranking, tool result formatting, conversation compaction, memory summarization, token budget allocation. Engineers now reason carefully about what earns a place in the context window and what gets cut.

That practice has produced real gains. But look at what it optimizes. Nearly every technique in the modern context engineering toolkit is about the task: what information is relevant to the question, what tools might help, what happened earlier in this conversation.

Almost nothing in that toolkit is about the person.

Two Users, One Retrieval

Consider a support copilot for a fintech platform. Two users ask a functionally identical question: "Why was my transfer declined?"

A well-engineered context pipeline handles this cleanly. It retrieves the relevant policy documentation, pulls the user's recent transaction records via tool call, includes the last few turns of conversation, and assembles a tight, well-structured window. The model produces an accurate, well-sourced answer explaining the decline reason and the resolution path.

Both users receive essentially the same response.

But the first user is a small business operator who has used the platform for three years, transacts daily, has never contacted support before, and typed the question in nine seconds. The second user opened the app four times in the last hour, checked the balance screen before and after each attempt, abandoned a transfer at the confirmation step twice, and took ninety seconds to compose the same question.

These two people need different responses. Not different facts — the facts are the same — but different framing, different depth, different ordering, and different next-step guidance. The first wants the reason and the fix, in that order, in two sentences. The second needs reassurance that their money is safe before they can absorb any procedural explanation at all. Lead with the policy citation and they will escalate, because the answer did not address the thing actually driving the question.

The retrieval was perfect. The response still missed.

Why Conversation History Does Not Solve This

The standard objection is that conversation history already carries this information. If the user is anxious, surely that shows up in what they type.

Sometimes. But conversation history has three structural limits as a source of human context.

It is bounded to the session. The moment the conversation resets, everything the system learned about this person evaporates. A user who spent twenty turns last week establishing that they want terse, technical answers starts today from zero. Every session re-derives the same understanding, badly, from a shorter runway.

It only contains what the user chose to type. Users do not narrate their own state. They do not write "I am worried about this and need reassurance first." They write "why was my transfer declined?" The stress is entirely in the behavior surrounding the message — the retry pattern, the balance checks, the composition latency — and none of that is in the transcript.

It conflates the durable with the momentary. Even when history is long, it is a flat sequence. Nothing in it distinguishes a stable trait from a passing state. A user who was frustrated once in March and a user who is frustrated right now look similar to a model reading a transcript, and they require opposite handling.

Per-model memory features help at the margins, but they inherit the same shape: memory scoped to one assistant, populated by what the user said, not by how the user behaved.

Human Context Is a Separate Retrieval Problem

The productive reframing is to treat human context as its own retrieval target, parallel to document retrieval, with its own store and its own assembly step.

Document retrieval answers: what information is relevant to this question?

Human retrieval answers: who is asking, how do they process information, and what state are they in right now?

Both feed the same window. Both need to be compressed to fit a budget. Both should be assembled from a persistent store rather than reconstructed per session. The difference is the source. Document context comes from a corpus. Human context comes from behavior — the timing, navigation, hesitation, and interaction patterns a platform already emits and almost never interprets.

Structurally, human context has three layers with different update rhythms:

Traits are stable. Information-processing style, tolerance for detail, preference for direct versus exploratory explanation. These shift over months and are safe to cache aggressively.

Preferences are medium-term. Channel, format, timing, depth. These drift over weeks and want periodic refresh.

State is immediate. Stress, urgency, confusion, decision readiness. This changes within a single session and must be current or it is worse than useless — a stale state signal actively misleads.

Systems that collapse these into one blob lose the distinction that matters. Caching state like a trait means responding to who someone was an hour ago. Recomputing traits like state means burning compute to rediscover something that has not changed since February.

The Budget Objection

Every context engineer's first reaction is that the window is already full.

That is exactly why human context belongs in it. The reason windows fill up is that systems compensate for not knowing the user by including everything that might matter to anyone. Three explanation depths, multiple framings, extensive hedging, defensive caveats. Not knowing who is asking is expensive, and the expense shows up as tokens.

A compact behavioral block — a few hundred tokens describing processing style, current state, and interaction preferences — routinely pays for itself. It lets the assembler stop hedging across possible users and target the actual one. Retrieval can go shallower because relevance is sharper. Output can go shorter because it does not need to serve three audiences at once.

Compression is the whole point. The behavioral store may hold months of interaction history, but what enters the window is a small, model-ready summary. That is the same discipline context engineering already applies to documents, applied to people.

What Changes Downstream

When human context becomes a first-class input, several things stop being hard problems.

Response calibration stops being a prompt-tuning exercise. The system does not need instructions to "adapt tone appropriately" — a directive models follow inconsistently because they have nothing to adapt to. It receives the actual parameters.

Cold start shrinks. Behavioral signal accumulates from the first session, and early-session micro-signals carry real information about processing style well before a conversational profile could form.

Cross-surface consistency becomes achievable. A behavioral profile keyed to the person rather than to the assistant travels across the chat interface, the email sequence, the in-app prompt, and whatever model is serving each of them. Swap the underlying model and the understanding persists, because it was never stored in the model.

Agentic systems get a guardrail they currently lack. An agent deciding whether to act autonomously or check in benefits enormously from knowing whether this user wants delegation or oversight — a question about the human, not the task, and one no amount of document retrieval will answer.

Infrastructure, Not a Feature

This is not a prompt template. It requires ingesting behavioral events, maintaining per-user models across three time horizons, keeping state fresh, and serving compressed context fast enough for the inference path. That is infrastructure work, and it is orthogonal to whatever the application actually does.

Fluence provides it as a layer. \GET /context/{user_id}\ returns model-ready behavioral context — traits, preferences, and current state, compressed for direct insertion into a window. It reads the interaction stream a platform already produces, which is why integration typically runs under 10 hours rather than requiring new instrumentation. It analyzes behavioral patterns, never message content, which is what makes it LGPD and GDPR compliant by architecture rather than by consent flow.

In the Fortics deployment, 3.4 million profiles built this way produced a 40% churn reduction, 2.3x conversion lift, and 3.5x improvement in ML model accuracy. The models were not better. The context was.

Context engineering solved the question of what the model should know about the task. The remaining half is what it should know about the person.

👉 See what model-ready behavioral context looks like in a single API call →