View/Context Engineering Overview

• View/Context Engineering is the systematic process for constructing and managing the informational projection used by AI systems during decision-making.
• It integrates historical multi-view and CSCW traditions with modern prompt engineering, memory hierarchy, and context compression techniques.
• Key design principles include progressive disclosure, task-specific customization, and fidelity management to mitigate context pollution and starvation.

View/Context Engineering denotes the disciplined construction of the informational projection that a system, agent, or model sees at decision time. In earlier engineering and CSCW traditions, a “view” was a partial representation of a shared cooperation context, tied to a specific point of view and synchronized with other views through model transformations (0711.2811). In current LLM research, context engineering is the systematic practice of assembling, processing, and managing the informational payload fed to a model during inference, while recent multi-agent work defines View/Context Engineering more specifically as the layer that manages the “active RAM” of each reasoning step by maintaining task-relevant Views and controlling Context Entropy (Mei et al., 17 Jul 2025, Zhang et al., 16 Mar 2026).

1. Definition and conceptual scope

A general formalization treats context as the union of features describing the relevant entities in an interaction. If $\mathcal{E}$ is the universe of entities, $\mathcal{F}$ the space of possible feature descriptions, and $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$ the situational characterization function, then for relevant entities $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$ the context is

$$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$

Context Engineering is then defined as the systematic mapping

$\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$

where $T$ is a target task or application domain and $f_{\mathrm{context}}$ transforms raw context into optimized representations through operations such as collection, filtering, aggregation, abstraction, storage, retrieval, and prompt injection (Hua et al., 30 Oct 2025).

In the LLM setting, this broad definition subsumes prompt engineering. One formulation decomposes the context presented to an autoregressive model into structured components $c_i$ and an assembly function $\mathcal{A}$, so that $\mathcal{F}$0 under a context-length constraint (Mei et al., 17 Jul 2025). A corporate multi-agent formulation expresses the same idea operationally as a function $\mathcal{F}$1 that selects, transforms, and schedules fragments of the total knowledge sources for decision step $\mathcal{F}$2 (Vishnyakova, 10 Mar 2026).

The term “view” introduces an additional projection semantics. In Loosely-Structured Software (LSS), at each discrete step $\mathcal{F}$3 there are persistent artifacts $\mathcal{F}$4, an intent $\mathcal{F}$5, a step-specific projection $\mathcal{F}$6, and an output $\mathcal{F}$7, with

$\mathcal{F}$8

$\mathcal{F}$9

Within this vocabulary, the View is the exact slice of global state that becomes operative for a step, while the Context is the current View plus the fragment of prior trajectory that is carried forward (Zhang et al., 16 Mar 2026). This distinction is useful because it separates the global information reservoir from the local projection actually exposed to the model.

2. Historical lineage: viewpoints, multi-view systems, and agentic context

The intellectual lineage of View/Context Engineering predates contemporary LLM systems. In industrial Concurrent Engineering, empirical studies of evaluation meetings examined how specialists express and defend viewpoints in argumentation. These studies found that arguments defending a viewpoint or proposal are often characterized by the use of constraints; that apparently identical constraints may carry different meanings and weightings for different specialists; that constraints can be implicit or explicit depending on interlocutive factors; and that arguments often mobilize not a single constraint but a network of constraints, leading to a first model of the dynamics of viewpoints confrontation and integration [0612020]. In this usage, a viewpoint is not merely a visual perspective but a constraint-weighted interpretive position within cooperative design.

A model-driven continuation of this line appears in Bat’iViews, a multi-view interface for construction-site management. Bat’iViews starts from the observation that a construction project is unique but that actors manipulate multiple views that partially represent the cooperation context through specific points of view. The system distinguishes between context modelling and the modelling of concepts represented in each business view, and uses an integrative model infrastructure with model transformations to manage navigation and interaction across views (0711.2811). Here, view engineering is explicitly tied to synchronization, partiality, and role-specific access to shared project state.

Recent work on context engineering places these earlier ideas into a longer historical arc. One account identifies four eras: Era 1.0, “Primitive Computation (1990s–2020)”; Era 2.0, “Agent-Centric Intelligence (2020–Present)”; Era 3.0, “Human-Level Intelligence (Future)”; and Era 4.0, “Superhuman Intelligence (Speculative)” (Hua et al., 30 Oct 2025). The same paper argues that context engineering is often treated as a recent innovation of the agent era, while related practices can be traced back more than twenty years. This suggests continuity between context-aware HCI, model-driven multi-view systems, and current agentic LLM infrastructures.

3. Formal objectives, constraints, and failure modes

A strong formalization of context engineering is given by the Root Theorem of Context Engineering. It begins with two axioms: every deployed LLM has a hard context-window bound $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$0, and response fidelity falls as cumulative context tokens $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$1 grow. With degradation rate $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$2, the paper models first-order fidelity as

$$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$3

with empirical $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$4 per $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$5 tokens. If $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$6 denotes signal and $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$7 token count, the signal-to-token ratio is $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$8, and the governing design principle is to maximize $$\mathrm{Char}:\mathcal{E}\to\mathcal{P}(\mathcal{F})$$9 under bounded, lossy channels subject to $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$0 and an operational fidelity threshold (Schick, 29 Mar 2026).

From this formulation follow several consequences that are central to View/Context Engineering. First, degradation is monotonic in injected volume. Second, signal and token count must be treated as independent optimization variables. Third, gate mechanisms must be triggered by fidelity thresholds rather than nominal capacity limits; the threshold point is

$\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$1

Fourth, long-lived systems require a homeostatic cycle of “accumulate → compress → rewrite → shed.” Fifth, because compression is performed inside the same lossy channel it compresses, external verification is required (Schick, 29 Mar 2026).

The LSS framework recasts these ideas at the runtime step level through the concept of Context Entropy. Context Entropy is the instability introduced by the gap between the actual $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$2 presented and the ideal minimal $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$3 needed to solve $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$4. Its two-sided failure modes are Context Pollution, where $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$5 contains irrelevant or contradictory material, and Context Starvation, where $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$6 omits critical constraints or state (Zhang et al., 16 Mar 2026). This language is particularly useful for multi-agent systems because it converts context errors into a tractable engineering vocabulary.

A complementary operational formulation is provided by five production-grade context quality criteria: relevance, sufficiency, isolation, economy, and provenance. Relevance requires that only information necessary for the current decision be included; sufficiency requires that all needed information be present; isolation requires slice separation across sub-agents; economy minimizes context size while preserving quality; and provenance tags each element with source identifier and timestamp for audit (Vishnyakova, 10 Mar 2026). Taken together, these criteria define what a well-engineered view must preserve even when aggressive selection or compression is applied.

4. Design principles and assembly methods

At the runtime layer, View/Context Engineering is organized around progressive disclosure and step-level customization. Progressive disclosure includes “Minimal-Sufficient,” “Adaptive Context Expansion,” and “Context Backpressure.” The first principle includes only the smallest slice of artifacts and history that plausibly supports the current intent; the second adds semantically adjacent evidence when the model signals low confidence or begins to loop; the third monitors token usage and ambiguity and triggers summarization or compression when pressure is high (Zhang et al., 16 Mar 2026). Step-level customization adds “Context Branching & Stitching,” in which isolated sub-contexts are forked and only the distilled winning path is returned, and “Context Isolation,” in which each new intent receives a fresh subset of prior trajectory rather than the entire raw history (Zhang et al., 16 Mar 2026).

These principles are implemented through recurring semantic control patterns. A Semantic Lens realizes $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$7 by retrieving and assembling a compact, dynamically expanding View. A Context Curator periodically distills carried context into a shorter summary and can spin up curated sub-contexts of bounded size. A Mediator creates clean agent-to-agent contracts and forks child agents with minimal inherited Views. End Criteria define the predicates under which ephemeral branches terminate and are optionally summarized back into persistent memory (Zhang et al., 16 Mar 2026). In the LSS case studies, this logic is not merely descriptive: on RepoBench-R, a worker-only setting produced Hit@5 = 0.70, “Lens+Worker” produced Hit@5 = 0.78, and “Lens+Index+Worker” produced Hit@5 = 0.84 (Zhang et al., 16 Mar 2026).

Human-guided assembly methodologies encode similar ideas with explicit artifact roles. One practitioner framework defines a five-role context package—Authority, Exemplar, Constraint, Rubric, and Metadata—with an explicit priority ranking for conflict resolution, and executes context preparation through four stages: Reviewer, Design, Builder, and Auditor (Calboreanu, 5 Apr 2026). In its observational study of 200 documented interactions, incomplete context was associated with 72 percent of iteration cycles; structured context assembly was associated with a reduction from 3.8 to 2.0 average iteration cycles per task and an improvement in first-pass acceptance from 32 percent to 55 percent; when iteration was permitted, the final success rate reached 91.5 percent (Calboreanu, 5 Apr 2026). These results are explicitly presented as observational and based on a single-operator dataset, but they reinforce the engineering claim that context completeness is often more consequential than instruction phrasing alone.

5. Architectures and system realizations

Recent systems instantiate View/Context Engineering through distinct representational choices: request-scoped hybrid views, step-indexed plan/code histories, mounted file-system namespaces, flexible file-and-code artifacts, instance-wise context routing, and statistically calibrated retrieval filters (Tan et al., 7 Apr 2026, Roy et al., 10 Jan 2026, Xu et al., 5 Dec 2025, Ye et al., 29 Jan 2026, Zhu et al., 15 May 2026, Chakraborty et al., 22 Nov 2025).

System	View/context representation	Main mechanism
HYVE	Hybrid columnar and row-oriented views over a request-scoped datastore	Preprocessing, selective exposure, SQL-backed postprocessing
CEDAR	Structured project summary and numbered Text #i / Code #i history	Three-agent orchestration, function calls, smart history rendering
AIGNE file-system abstraction	Mounted namespace of context artifacts with metadata and ACLs	Context Constructor, Loader, Evaluator
MCE / NCCE	Files-and-code artifacts or a catalog of context strategies	Skill evolution or instance-wise routing
Conformal RAG	Filtered snippet subset $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$8	Coverage-controlled pre-generation filtering

HYVE is the clearest example of “view” as an explicit representation transform over large machine-data payloads. It parses a raw input string $\mathcal{E}_{\mathrm{rel}}\subseteq\mathcal{E}$9 into alternating text and JSON/AST objects, loads the full-fidelity data into an in-memory datastore $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$0, constructs column-oriented and row-oriented hybrid views, and exposes only the most relevant representation to the LLM. Formally, $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$1, while the visible prompt is a function of rendered column and row views. Across real-world workloads, HYVE reduces token usage by 50–90% while maintaining or improving output quality; on structured generation tasks it improves chart-generation accuracy by up to 132% and reduces latency by up to 83%; on TOON-QA it raises exact match from 0.47 to 0.93 while reducing tokens from 1.3 M to 0.15 M (Tan et al., 7 Apr 2026).

CEDAR applies context engineering to agentic data science. It begins with a structured prompt containing DS-specific input fields, materializes the workflow as an enumerated sequence of interleaved plan and code blocks, keeps raw data local by using function calls that inject only aggregate statistics and instructions into prompts, and manages failures through iterative code generation and smart history rendering. Its explicit token-budget condition is

$$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$2

In a typical Kaggle run, the system executes 10–20 numbered steps with end-to-end runtime $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$3 minutes under “Autorun” mode, and the cited baseline logistic regression reached $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$4 accuracy (Roy et al., 10 Jan 2026).

The file-system abstraction proposed in AIGNE generalizes context to a mounted namespace $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$5 over files, directories, tools, and external endpoints, governed by primitive operations such as mount, read, write, and unmount and bounded by a session token budget $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$6. Its pipeline separates Context Constructor, Loader, and Evaluator, and all artifacts carry provenance metadata and access-control policy (Xu et al., 5 Dec 2025). Automated context optimization systems push further: MCE models a context artifact as a directory of markdown files and executable code and reports 5.6–53.8% relative improvement over state-of-the-art agentic CE methods, while NCCE reframes context engineering as recommendation and routes each instance to a learned best context strategy, achieving average test accuracy 74.8 across HoVer, SCONE, and HotpotQA against 71.5 for POLCA (Ye et al., 29 Jan 2026, Zhu et al., 15 May 2026).

A statistically grounded variant appears in conformal RAG. Given snippets $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$7, relevance labels $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$8, and a nonconformity score $$C=\bigcup_{e\in\mathcal{E}_{\mathrm{rel}}}\mathrm{Char}(e).$$9, split conformal filtering constructs a threshold $\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$0 on positive calibration examples and retains

$\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$1

with the finite-sample guarantee

$\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$2

under exchangeability. The method reduces retained context by 2–3x relative to unfiltered retrieval while meeting target coverage (Chakraborty et al., 22 Nov 2025). Outside purely textual agents, the same view logic appears in multi-view engineering drawing interpretation, where Stage 1 isolates views, Stage 2 detects rotated annotations within each view, and Stage 3 parses them with specialized VLMs into unified JSON; the reported overall F1 scores are 0.672 for the Alphabetical VLM and 0.963 for the Numerical VLM (Khan et al., 23 Oct 2025).

6. Evaluation, limitations, and research directions

Empirical work consistently shows that context design is task- and domain-dependent rather than universally uniform. The CL4SE benchmark defines four software-engineering context types—interpretable examples, project-specific context, procedural decision-making context, and positive & negative context—and reports an average performance improvement of 24.7% across tasks, with procedural context boosting code review by up to 33%, mixed positive-negative context improving patch assessment by 30%, project-specific context increasing code summarization BLEU by 14.78%, and interpretable examples enhancing code generation PASS@1 by 5.72% (Hu et al., 26 Feb 2026). These results support the stronger claim that “context type” itself is a design variable.

Evaluation research also shows that realistic contexts are harder than synthetic long-context tests. HaystackCraft constructs noisy long contexts using heterogeneous retrievers and dynamic agentic workflows. Its results show that stronger dense retrievers can introduce more challenging distractors, that graph-based reranking improves retrieval effectiveness and mitigates more harmful distractors, and that in static NIAH settings graph-based reranking yields up to +44% relative F1 on 128 K contexts. In dynamic tests, even advanced models such as Gemini 2.5 Pro and GPT-5 suffer cascading failures from self-generated distractors or struggle to perform early stops; for GPT-5, enforced multi-round performance drops from 77% to 72% to 70% (Li et al., 8 Oct 2025). This is directly relevant to View/Context Engineering because it shows that the difficulty lies not only in fitting more tokens but in governing what kinds of evidence accumulate and in what order.

Long-horizon persistence remains a central technical problem. The Root Theorem paper argues that append-only systems necessarily exceed their effective window in finite time, and its 60+-session case study reports that after 62 sessions an append-only projection reaches $\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$3 tokens while a homeostatic architecture remains at $\mathrm{CE}:(C,T)\mapsto f_{\mathrm{context}},$4, with divergence emerging by Session 10–12 (Schick, 29 Mar 2026). The survey literature generalizes this into a broader research gap: after analyzing over 1300 papers, one survey identifies a “fundamental asymmetry” in which current models, even with advanced context engineering, are better at understanding complex contexts than at generating equally sophisticated, long-form outputs (Mei et al., 17 Jul 2025).

Open problems are correspondingly broad. “Context Engineering 2.0” lists storage bottlenecks, quadratic attention and attention dilution, retrieval noise, error propagation across lifelong memory chains, lack of isolation and validation for critical tasks, and the absence of standard benchmarks for lifelong reasoning or evolving context (Hua et al., 30 Oct 2025). A plausible implication is that View/Context Engineering is converging toward a full systems discipline: it now encompasses projection design, compression, memory hierarchy, retrieval control, inter-agent isolation, provenance, verification, and evaluation under drift. In that sense, the “view” is no longer a passive slice of data but a governed operational surface on which task performance, failure modes, and long-term system behavior depend.