Beyond RAG: the rise of Context Architecture

Engineering the context layer for autonomous agents.

LinkTec Labs · Research Note N°01 · Applied AI & Data · Edition 2026

Abstract

Retrieval-Augmented Generation made large language models useful on private knowledge. But the single-shot pipeline (embed, search, stuff, generate) was designed for one human question, not for autonomous agents that issue thousands of calls and accumulate state across long-running sessions. As agents reach production, the binding constraint is no longer the model or the vector index; it is the context layer: what reaches the model, when, in what form, at what cost, and under whose authority. This note reframes RAG as one component of a broader discipline, context architecture, and surveys the techniques that now define the state of the art: hybrid and contextual retrieval, late-interaction models, agentic (self-correcting) retrieval loops, graph-structured reasoning, context-budget management, persistent agent memory, and the evaluation methods that keep all of it honest. It also addresses two topics most treatments still omit: the economics of the context layer, and its security. A retrieval corpus is an attack surface, and an unguarded context window is an open door. We close with the reference architecture LinkTec Labs deploys for organisations moving from proof-of-concept to production, and with five working hypotheses that define our research agenda for the year ahead.

01 · The shift: from clever prompts to engineered context

Retrieval-Augmented Generation [1] was the idea that unlocked enterprise adoption of language models. Instead of fine-tuning a model on private data, you retrieve the relevant passages at query time and let the model read them. It worked. It also quietly set a ceiling. The canonical pipeline (chunk the corpus, embed it, run a nearest-neighbour search on the user's question, concatenate the top results, generate) assumes a single, well-formed human query and a single pass. That assumption breaks the moment the caller is an agent.

Autonomous agents do not ask one question. They plan, call tools, read results, revise, and call again, emitting orders of magnitude more retrievals than a person and carrying an ever-growing working state between steps. The scarce resource shifts from model quality to context quality: the limited window must be filled, at every step, with exactly the information and tools the next decision requires, and nothing else. Andrej Karpathy framed it memorably: the LLM is a new kind of operating system, and the context window is its RAM [2]. The job of the engineer is memory management.

This is why the field has moved, in the space of two years, from prompt engineering to what is now widely called context engineering and, at production scale, to context architecture: the systematic design of the pipelines, indices, controllers, budgets and boundaries that decide what the model sees. Anthropic has published explicit guidance on the practice [3]; analysts now describe it as the discipline that supersedes prompt engineering. The thesis of this note is simple and, we believe, consequential:

The bottleneck in applied AI is no longer the model. It is the architecture of the context that surrounds it.

For a model vendor, that is a footnote. For an organisation trying to put agents into production on its own messy data, it is the whole game. It is buildable, measurable, and ownable. The remainder of this note lays out the terrain.

02 · The long-context illusion: why "just paste everything" fails

The first reflex when context matters is to make the window bigger. Frontier models now advertise windows of hundreds of thousands, even millions, of tokens, and a tempting conclusion follows: if everything fits, retrieval is obsolete. The evidence says otherwise. Long windows are necessary but not sufficient, because models do not use long contexts uniformly.

Three failure modes are now well documented. The first is positional. Liu et al. showed that performance on multi-document tasks follows a U-shaped curve: on a twenty-document question-answering benchmark, accuracy sat near 75% when the answer appeared at the start of the input and fell to roughly 55% when the same evidence was buried in the middle, a swing of some twenty points from position alone [4]. The phenomenon, "lost in the middle", replicates across model families.

The second is cumulative. Chroma's context-rot study, spanning eighteen frontier models, demonstrates that as raw input grows, performance degrades non-uniformly and often well before the advertised limit, as attention dilutes across more tokens and the model is more easily lured by coherent-but-irrelevant distractors [5].

The third, and the most damning for the "paste everything" reflex, is semantic. The popular needle-in-a-haystack test rewards literal string matching and therefore flatters every model that takes it. NoLiMa, a benchmark built so that the question and the evidence share almost no vocabulary, forces the model to reason rather than pattern-match across the window. Under that condition, ten of twelve models claiming 128k-token support fell below half of their own short-context accuracy by 32k tokens [17]. The advertised window and the usable window are not the same thing.

The operational consequence is decisive. A bigger window does not remove the need to choose what goes into it; it raises the stakes of choosing badly. Retrieval is not a workaround for small windows. It is the mechanism by which we keep the signal-to-token ratio high regardless of window size. Context architecture begins here.

03 · The retrieval substrate, done right: hybrid, contextual, reranked, late-interaction

If retrieval is permanent, it must be excellent. The naive baseline (dense vectors over fixed-size chunks) leaves a great deal of accuracy on the table. Four upgrades now constitute the production standard.

Hybrid retrieval and rank fusion

Dense embeddings capture semantic similarity but miss exact terms: identifiers, error codes, names, rare tokens that sparse lexical methods such as BM25 catch reliably. The robust default is to run both and merge their results with Reciprocal Rank Fusion, then deduplicate. Hybrid retrieval is now the recommended starting point for essentially all production systems [6]. Learned sparse models such as SPLADE, which keep the exact-match behaviour of an inverted index while learning neural term expansions, offer a further refinement of the sparse leg where the corpus rewards it [18].

Contextual retrieval

Chunking destroys context: a paragraph that says "the margin fell to 3.2%" loses the entity and the period it refers to. Anthropic's contextual retrieval prepends a short, model-generated description situating each chunk in its document before indexing, applied to both the embedding and the BM25 index. The measured effect is large: contextual embeddings cut top-20 retrieval failures by 35% (from 5.7% to 3.7%); adding contextual BM25 reaches 49%; adding a reranker on top reaches 67% [6].

Reranking

First-stage retrieval optimises for recall; it returns many plausible candidates. A cross-encoder reranker, which reads query and passage jointly rather than comparing pre-computed vectors, then reorders them for precision. The pattern is to over-retrieve (50-100 candidates) and rerank down to the handful that actually enter the prompt, trading a small latency cost for a substantial precision gain. How many candidates to rerank against how much added latency is the central tuning knob [6].

Late interaction

Between single-vector dense retrieval and full cross-encoding sits late interaction. ColBERT represents query and document as sets of token-level vectors and scores them with a fine-grained MaxSim operator, capturing nuance a single pooled vector loses [7]. Once academic, late-interaction models are now firmly in production, with mature tooling and millions of monthly downloads. ColPali extends the idea to documents-as-images, retrieving over rendered pages, tables, figures and layout without a brittle OCR pipeline [8]. For visually complex corpora this is a step change.

04 · From pipelines to agentic retrieval: retrieval as a control loop

Even an excellent funnel runs once. The deeper shift is to let the agent control retrieval: decide whether to retrieve at all, judge whether what came back is sufficient, and act to fix it if not. Four named patterns from the literature now compose most production systems.

• Self-RAG trains the model to emit reflection tokens, deciding on demand when to retrieve and critiquing whether its own draft is supported by the evidence [9].
• Corrective RAG (CRAG) adds a lightweight retrieval evaluator that grades the relevance of retrieved documents and, on a low score, triggers a corrective action (query rewriting or a web fallback) rather than answering from poor context [10].
• FLARE retrieves actively: it generates forward and pauses to fetch evidence whenever its next-token confidence drops, so retrieval is driven by the model's own uncertainty [11].
• Adaptive-RAG routes by query difficulty. A small classifier sends easy questions straight to generation and reserves the expensive multi-step loop for the hard ones, controlling cost as well as accuracy [12].

The unifying picture is a loop (route → retrieve → grade → act → generate → reflect) in which retrieval is a tool the agent invokes under a policy, not a fixed prelude. The accuracy gains on the queries that matter most (multi-hop, compositional, ambiguous) are large relative to single-shot RAG, precisely because the agent can recover from a bad first retrieval instead of confidently answering from it [9][10][12].

Graph-structured retrieval for multi-hop reasoning

Some questions are not about finding a passage but about traversing relationships: "what did our top three competitors do last quarter that affected our European customers." Flat chunk retrieval cannot compose that answer. GraphRAG builds a knowledge graph of entities and relations during ingestion and retrieves structured subgraphs, enabling multi-hop reasoning and corpus-level summarisation. In Microsoft Research's evaluation on sense-making tasks, LLM judges preferred GraphRAG's answers over vector RAG's for comprehensiveness in 72-83% of head-to-head comparisons, with similar margins for diversity [13]. Two caveats belong next to that number: the evaluation relies on LLM-as-judge, a method with known biases (see section 08), and graph construction carries a real ingestion cost. The mature pattern is therefore not graph instead of vectors but graph alongside them: hybrid retrieval as the default, with selective graph enrichment for known multi-hop query classes.

05 · The context budget: managing the window as a memory hierarchy

Retrieval decides what could enter the window. The context budget decides what actually does, turn after turn, as an agent runs for tens or hundreds of steps. This is where most production agents quietly fail: not on a single answer, but on the fortieth, when the window has filled with tool transcripts and the model loses the thread. Treating the window as a managed memory hierarchy, not a bucket, is the difference.

Three techniques carry most of the load. Context editing prunes low-signal content (stale tool output, superseded drafts) by rule before it accumulates; in Anthropic's hundred-turn evaluation, context editing cut token consumption by 84% and allowed workflows to complete that would otherwise have exhausted the window [3][19]. Compaction periodically summarises history into a compact state object, preserving decisions and discarding transcript. Sub-agent isolation gives each sub-task its own clean window and returns only a condensed summary, typically one to two thousand tokens, to the orchestrator, so the lead agent's context never absorbs the full working state of its delegates [3]. Combined with a persistent memory store, these mechanisms compound: in the same evaluation series, memory plus context editing improved agentic search performance by 39% over the baseline [19].

Design principle. The token budget is managed before content enters the window, not after. Every token spent on low-signal material is paid twice: once in cost, and again in the accuracy lost to context rot.

The economics nobody budgets for

Two line items dominate the cost side of the context ledger, and both are design choices rather than facts of nature.

The first is tool definitions. Agents connected to many tools through protocols such as MCP pay for every schema on every call: a single large tool server can consume tens of thousands of tokens before the user has typed a character, and production teams have reported tool definitions alone occupying most of a 200k window. The remedy is progressive disclosure: load tool schemas on demand, or expose tools through a code-execution layer so the model reads a filesystem of definitions instead of holding them all in context. Anthropic reports a worked example in which this pattern reduced a 150,000-token tool overhead to roughly 2,000 tokens [20].

The second is cache economics. Providers now price cached input tokens at roughly a tenth of fresh ones, which turns prompt structure into a financial instrument. An agent whose context is append-only (stable system prompt and tool schemas first, volatile material last) reuses its key-value cache across turns; one that rewrites early context invalidates the cache on every call and pays full price for the same tokens hundreds of times. Cache-aware context assembly routinely cuts agent serving costs by half or more and improves latency in the same stroke [21]. The context budgeter, in other words, has two objective functions: accuracy per token, and cost per correct answer.

RAG, CAG, or long context? A decision, not a religion

Not every problem needs retrieval. When a knowledge base is small, stable, and fits the window, cache-augmented generation (CAG) preloads the whole corpus and precomputes its key-value cache once, eliminating per-query retrieval latency and retrieval errors entirely [14]. The engineering judgement is to match mechanism to corpus:

06 · Memory: state that outlives the session

Everything above manages a single session. Production agents also need the opposite: state that survives when the window does not. An agent that re-learns a user's preferences, an account's history, or its own past mistakes on every session is wasteful at best and erratic at worst.

The field has converged on a layered answer. MemGPT first framed the problem in operating-system terms: a small core memory held in-window, with archival storage paged in and out under the model's own control [16]. Production systems since have refined the write path, which is where the difficulty actually lives. Mem0 extracts salient facts from each exchange and then applies explicit ADD, UPDATE, DELETE or no-op decisions against the store, so that memory converges instead of accumulating contradictions [22]. Temporal knowledge-graph designs go further, timestamping assertions so the agent can distinguish what was true from what is true. Benchmarks such as LongMemEval now measure exactly these abilities (temporal reasoning, knowledge updates, cross-session synthesis) and show that naive "stuff the history into the window" baselines degrade sharply as interaction history grows [23].

Two engineering rules follow. First, memory is a write-policy problem before it is a retrieval problem: an unmanaged store fills with stale and contradictory entries whose retrieval later poisons good context. Second, memory competes for the same budget as everything else; what gets promoted into the window each turn must be governed by the budgeter, not appended by reflex. Memory is not a bolt-on feature. It is the fourth tier of the hierarchy in Fig. 4, and it deserves the same architectural care as the index.

07 · The poisoned context: security is an architecture property

Context architecture has a property that model selection does not: it defines the system's attack surface. Every channel that feeds the window (retrieved chunks, tool results, web pages, uploaded documents, memory entries) is a channel an adversary can write to. The model cannot reliably distinguish instructions from data within its input; that weakness is structural, and it makes indirect prompt injection the defining vulnerability of LLM-integrated systems [24].

The retrieval corpus itself is the most consequential vector. PoisonedRAG demonstrated that injecting five crafted documents into a corpus of millions is sufficient to make the system return an attacker-chosen answer for a targeted query around 90% of the time [25]; follow-up work has pushed comparable attacks down to a single document. Persistent memory raises the stakes further: a poisoned memory entry does not corrupt one answer, it redirects the agent's behaviour across every future session that retrieves it. The same loops that make agentic retrieval powerful (grade, correct, re-query) also give injected instructions more opportunities to execute.

Defence, accordingly, is architectural rather than model-level, and it maps onto layers this note has already described:

• Provenance and trust tiers at ingestion. Every span in the window carries a source and a trust level; unvetted external content never enters the same tier as curated internal documents. Corpus governance (who can write to the index, and how writes are reviewed) is part of the retrieval system, not an afterthought.
• Separation of instruction and data in assembly. Retrieved text is delimited, marked as untrusted, and never allowed to redefine the agent's objectives; the context assembler enforces this the way an operating system separates code from data.
• Least-privilege tools and egress control. An injected instruction is only as dangerous as the actions available to it. Scoping tool permissions per task, and auditing outputs that leave the system, bounds the blast radius.
• Injection resistance as a tracked metric. Red-team suites for injection belong in the evaluation harness beside faithfulness, run on every change to prompts, tools or corpus.

Design principle. The context window is a security boundary. Anything that can write into it can, in the limit, act through the agent. Architect the write paths with the same rigour as the read paths.

08 · Measuring what matters: evaluation as the control system

None of the above is safe to deploy on intuition. Context architecture is an empirical discipline, and its instrument is evaluation. The community has converged on a small, decomposable metric set, operationalised by RAGAS and its successors, that separates retrieval quality from generation quality [15]:

• Context precision and recall. Are the retrieved chunks relevant, and do they actually contain the answer? These isolate the retriever from the generator.
• Faithfulness, decomposed as the share of the answer's atomic claims that are directly supported by the retrieved context. The front-line metric against hallucination [15].
• Answer relevance. Does the response actually address the question asked?

Alongside these, classic ranking metrics (Precision@k, Recall@k) track the funnel directly; reasonable starting targets for narrow-domain systems are Precision@5 ≥ 0.7 and Recall@20 ≥ 0.8.

Two hard-won lessons temper the tooling. First, most of these metrics are computed by an LLM judging another LLM, and judges carry biases: they favour longer answers, favour their own model family, and drift as judge models are updated. The production pattern is two-layered: automated metrics on every change, plus human evaluation on a stratified sample (and on all of the highest-stakes traffic), with the human labels fed back to calibrate the judge. Second, offline scores are necessary but not sufficient; the same metrics must run as observability on live traffic, attached to traces that span routing, retrieval, tool use and generation, because context bugs surface in production distributions long before they appear in a curated test set.

The point is not the specific numbers but the loop: instrument retrieval and generation separately, set targets, and let measured faithfulness and context precision, not intuition, drive every change to chunking, indexing, reranking and prompting. A system you cannot measure, you cannot improve. A system you can measure separates a retrieval bug from a generation bug in minutes instead of weeks.

Why this matters for trust. Faithfulness scoring gives a defensible, auditable answer to the question every regulated buyer asks: "how do you know the model isn't making this up?" The answer is a number, tracked over time, not a promise.

09 · A reference architecture: the context layer, as LinkTec Labs builds it

The techniques above are not a menu to pick from at random; they compose into a layer. The architecture below is the one we deploy for organisations moving from proof-of-concept to production, deliberately sized for real, mixed, mid-scale corpora rather than for leaderboard conditions.

Five principles govern it. Retrieval quality is the product: contextual indexing and reranking are not optional polish but the accuracy floor. The controller is explicit: retrieval is a governed tool with routing and grading, never a blind prelude. The budget is engineered: the window is allocated, edited and compacted under a policy that optimises both accuracy per token and cost per correct answer, and memory writes are governed with the same discipline. The boundary is defended: every write path into the window carries provenance, and injection resistance is tested like any other regression. And everything is measured: every change is justified by a movement in faithfulness or context precision, with a full, exportable audit trace from query to answer.

That last pair of properties, the defended boundary and the audit trace, is what makes the architecture deployable in regulated, sovereignty-sensitive environments, the subject of a forthcoming note in this series.

10 · Open problems: five working hypotheses

Context architecture is young, and the honest position is that several of its hardest problems remain open. These five hypotheses define LinkTec Labs' research agenda; each is falsifiable, and we intend to publish results either way.

H1. Budget allocation can be learned. Today's context budgets are hand-tuned rules (prune after n turns, compact at x% fill). We hypothesise that allocation policies learned from evaluation signals (which spans, kept or dropped, moved faithfulness on which task classes) will outperform static rules, in effect an admission controller for the window trained on the system's own telemetry.

H2. Provenance can be load-bearing. Trust labels attached at ingestion are currently advisory. We hypothesise they can be made mechanical: propagated span-by-span through assembly into the answer, so that every claim in an output is attributable to a source and trust tier without re-running the system. This would convert audit from reconstruction into lookup, which is what regulated deployment actually requires.

H3. Retrieval should be cache-shaped. Retrieval and caching are optimised by different teams and fight each other: each injected chunk that displaces stable prefix tokens silently multiplies serving cost. We hypothesise that a retrieval scheduler with the KV-cache in its objective (choosing where and when to inject, not only what) can cut cost per correct answer substantially at flat accuracy.

H4. The index should learn from use. ACE-style results show agents improving by curating their own playbooks from execution feedback rather than by fine-tuning [26]. We hypothesise the same write-back loop applies to the retrieval layer: distilling resolved episodes into the corpus so retrieval quality compounds with usage. The guardrail is section 07: a self-writing index is a self-poisoning risk, so write-back must pass the same provenance gate as any external source.

H5. Ingestion should be tuned by outcomes. Chunk sizes and contextualisation prompts are set once, by heuristic, and rarely revisited. We hypothesise that closing the loop from measured faithfulness and context precision back into chunking and contextualisation choices, per corpus, yields gains comparable to a reranker upgrade at a fraction of the serving cost.

11 · Practitioner's playbook: what to do on Monday

• Stop pasting; start curating. A larger window is not a retrieval strategy. Keep the signal-to-token ratio high at every step [4][5][17].
• Make hybrid the default. Dense + BM25 + RRF before anything exotic; it is the highest-return first move [6].
• Contextualise chunks before indexing. A one-line situating description per chunk is among the cheapest large accuracy gains available [6].
• Over-retrieve, then rerank. 50-100 candidates into a cross-encoder, down to a precise top-k [6].
• Give the agent a retrieval policy. Route by difficulty, grade sufficiency, correct on failure; never answer from bad context [9][10][12].
• Budget the window like memory. Edit, compact, and isolate sub-agents; treat tokens as a managed resource [3][19].
• Design for the cache. Keep context append-only where possible: stable prefixes first, volatile material last. Load tool definitions on demand instead of all at once [20][21].
• Give memory a write policy. Extract, update and expire; an append-only memory store is a liability, not an asset [22][23].
• Treat every retrieved span as untrusted input. Provenance at ingestion, delimitation at assembly, least-privilege tools, and injection tests in the regression suite [24][25].
• Match mechanism to corpus. RAG, CAG, long-context and graph are tools, not allegiances [13][14].
• Instrument before you optimise. Faithfulness and context precision/recall, tracked over time, on test sets and on live traffic, or you are guessing [15].

The model is a commodity. The context around it is the architecture, and the architecture is where the advantage lives.

LinkTec Labs designs, builds and measures context architectures for organisations moving from proof-of-concept to production: sovereign-deployable, audit-ready, and sized for real data. This is the first in our 2026 research series. linktec.fr / labs

References

1. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401. https://arxiv.org/abs/2005.11401
2. LangChain. Context Engineering for Agents (incl. A. Karpathy's "LLM as OS / context as RAM" framing). 2025. https://www.langchain.com/blog/context-engineering-for-agents
3. Anthropic. Effective Context Engineering for AI Agents. Anthropic Engineering, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
4. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. arXiv:2307.03172. https://arxiv.org/abs/2307.03172
5. Chroma Research. Context Rot: How Increasing Input Tokens Impacts LLM Performance. 2025. https://research.trychroma.com/context-rot
6. Anthropic. Introducing Contextual Retrieval. 2024. https://www.anthropic.com/news/contextual-retrieval
7. Khattab & Zaharia. ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT. SIGIR 2020. arXiv:2004.12832. https://arxiv.org/abs/2004.12832
8. Faysse et al. ColPali: Efficient Document Retrieval with Vision Language Models. ICLR 2025. arXiv:2407.01449. https://arxiv.org/abs/2407.01449
9. Asai et al. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. arXiv:2310.11511. https://arxiv.org/abs/2310.11511
10. Yan et al. Corrective Retrieval-Augmented Generation (CRAG). 2024. arXiv:2401.15884. https://arxiv.org/abs/2401.15884
11. Jiang et al. Active Retrieval-Augmented Generation (FLARE). EMNLP 2023. arXiv:2305.06983. https://arxiv.org/abs/2305.06983
12. Jeong et al. Adaptive-RAG: Learning to Adapt Retrieval-Augmented LLMs through Question Complexity. NAACL 2024. arXiv:2403.14403. https://arxiv.org/abs/2403.14403
13. Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research, 2024. arXiv:2404.16130. https://arxiv.org/abs/2404.16130
14. Chan et al. Don't Do RAG: When Cache-Augmented Generation is All You Need. 2024. arXiv:2412.15605. https://arxiv.org/abs/2412.15605
15. Es et al. RAGAS: Automated Evaluation of Retrieval-Augmented Generation. 2023. arXiv:2309.15217. https://arxiv.org/abs/2309.15217
16. Packer et al. MemGPT: Towards LLMs as Operating Systems. 2023. arXiv:2310.08560. https://arxiv.org/abs/2310.08560
17. Modarressi et al. NoLiMa: Long-Context Evaluation Beyond Literal Matching. ICML 2025. arXiv:2502.05167. https://arxiv.org/abs/2502.05167
18. Formal et al. SPLADE: Sparse Lexical and Expansion Model for First Stage Ranking. SIGIR 2021. arXiv:2107.05720. https://arxiv.org/abs/2107.05720
19. Anthropic. Managing Context on the Claude Developer Platform. 2025. https://www.anthropic.com/news/context-management
20. Anthropic. Code Execution with MCP: Building More Efficient AI Agents. Anthropic Engineering, 2025. https://www.anthropic.com/engineering/code-execution-with-mcp
21. Anthropic. Prompt Caching. Claude Developer Platform documentation, 2024-2025. https://docs.claude.com/en/docs/build-with-claude/prompt-caching
22. Chhikara et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. 2025. arXiv:2504.19413. https://arxiv.org/abs/2504.19413
23. Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. ICLR 2025. arXiv:2410.10813. https://arxiv.org/abs/2410.10813
24. Greshake et al. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. AISec 2023. arXiv:2302.12173. https://arxiv.org/abs/2302.12173
25. Zou et al. PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models. USENIX Security 2025. arXiv:2402.07867. https://arxiv.org/abs/2402.07867
26. Zhang et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. 2025. arXiv:2510.04618. https://arxiv.org/abs/2510.04618

© 2026 LinkTec, LinkTec Labs. Research Note N°01. Figures are original schematics by LinkTec Labs, after the cited studies. Reported quantitative results are attributed to their primary sources; secondary syntheses are indicated as such in-text. This note is informational and does not constitute a benchmark claim by LinkTec.