Prompt engineering is not obsolete; it is still responsible for making instructions clear. But an agent's success also depends on which tools, data, state, history, and memory it receives on every turn. Managing this complete set of visible information is the job of context engineering.
A prompt is an instruction; context is the world the model sees
In a 2025 engineering article, Anthropic described context engineering as the natural progression of prompt engineering. It involves curating not just prompts but also the system instructions, tools, MCP integrations, external data, and message history that enter the context window at inference time. See Anthropic: Effective context engineering for AI agents.
The distinction looks like this:
| Layer | Core question | Example |
|---|---|---|
| Prompt engineering | How should the model do the work? | “List the assumptions first, then provide SQL.” |
| Context engineering | What must the model see on this turn? | Schema, metric definitions, available tools, Plan state, recent queries |
A good prompt can still fail in the wrong context. An instruction may say “use the approved definition,” while the model never receives the approved Plan. Or a tool schema may still expose write operations even though the current state is read-only exploration. The problem is not the wording. The world visible to the model is inconsistent with the real working environment.
How much difference context makes to the same “analyze conversion” request
Prompt only
Analyze why conversion fell this month and provide conclusions and recommendations.
The model must guess the tables, funnel stages, denominator, time zone, and output format. Even if the answer is fluent, it may present a generic convention as the company's actual definition.
Structured context
State: PlanPlanning; formal execution is not allowed
Data: events(event_time, user_id, session_id, event_name)
Metric: checkout conversion = paid sessions / checkout_started sessions
Time: Asia/Taipei, complete days through 2026-06-30
Exclusions: employee, test, full_refund
Plan: one open annotation asks for confirmation of the cross-day payment window
Available tools: read schema, validate queries, revise Plan
The second context does not guarantee a correct conclusion, but it narrows the model's choices to a reviewable range. The model knows it cannot formally execute yet, which definition is active, and which human decision is still missing.
Six components of agent context
- Instructions: Role, quality standards, and prohibited actions.
- State: Whether the task is exploring, planning, executing, or delivering.
- Tools: What can be read or written on this turn and how results are returned.
- Data: Schemas, documents, query results, and error messages.
- History: Recent decisions, tool traces, and unresolved questions.
- Memory: Governed rules or business knowledge that remains valid across conversations.
The design question should not be “How much can we fit?” but “What is the smallest high-signal set of information sufficient to take the correct next step?” Anthropic treats context as a finite resource and recommends finding the minimum set of high-signal tokens that increases the likelihood of the desired behavior. This does not mean shorter context is always better. It means every token should contribute to the task.
Three common anti-patterns
Resending the entire workspace on every turn
The advantage is that the needed information may be somewhere inside. The costs are token consumption, contamination by stale content, and important facts getting buried. A better approach keeps a small Summary present and retrieves complete schemas or documents only when needed.
Expressing permissions only in the prompt
“Do not modify data” is not a sufficient boundary if it is only a textual reminder. The model or tool integration can still cross it when something goes wrong. Permissions should be enforced through tool allowlists, read-only query layers, and human authorization together. The prompt is one layer, not the only defense.
Treating every conversation as long-term memory
Conversations contain temporary assumptions, failed attempts, and sensitive information. Memory that persists across tasks needs a source, lifecycle, and approval flow. It should not permanently inject every utterance by default.
How Lantide Data configures analysis context
Lantide Data separates Summary from Detail. Each turn receives a concise summary of the workspace, project, active tab, and cache. Full schemas, Plans, Reports, or References are retrieved with tools when needed. The system prompt is assembled according to states such as NoProject, Planning, and Executing, and the available tool schemas are filtered by state as well. See Prompt and context engineering and Agent runtime architecture for the detailed design.
For analysis, this lets the same request see the Plan state, query environment, recent steps, and approved knowledge together. Queued Knowledge is not injected until the user applies it. Context therefore stays aligned with the actual IDE state instead of depending on an ever-growing chat transcript.
The boundary is equally important. Context engineering improves the conditions under which a model obtains and uses information; it cannot guarantee correct reasoning or replace data quality checks, Plan review, or Execute authorization. If the schema is wrong or metric definitions conflict, a person still needs to resolve the problem.
Conclusion
Prompt engineering has not disappeared; it has become one part of a larger context system. When building or evaluating an agent, inspect not only its prompt templates but also how state, tools, data, history, and Memory enter each turn. The real dividing line is whether the model sees the right world at the right time.