DEV Community: saaro

Agentic RAG 2026: When AI Agents Decide How to Find Knowledge

saaro — Sat, 24 Oct 2026 12:00:56 +0000

Classical RAG pipelines (Retrieval-Augmented Generation) have become the standard over the past two years for supplying large language models with up-to-date domain knowledge. But the simple “Embed → Retrieve → Generate” approach quickly reaches its limits with multi-step questions, ambiguous queries, or heterogeneous data sources. By 2026, Agentic RAG has established itself as an architectural pattern that replaces this linear process with an agentic control loop—taking the quality and reliability of knowledge-based AI applications to a new level.

What distinguishes Agentic RAG from classical RAG

A classical RAG pipeline works deterministically: the user query is embedded, the top-k most similar chunks are retrieved from a vector database, inserted into the prompt, and the LLM generates an answer. This one-time pass is fast and cheap, but blind—the retriever does not know whether the chunks found are actually relevant, and the LLM cannot ask follow-up questions or change strategy.

Agentic RAG wraps this process in an agent control loop: an LLM-based orchestrator agent independently decides how and where to search for information. It can break the query into sub-questions, call multiple retrieval tools sequentially (vector database, SQL database, web search, MCP servers), evaluate the results, and start a new round if quality is insufficient. The decisive difference: the system transitions from a pipeline model to a state machine model.

An example from practice: an internal knowledge assistant is asked: “What is our return policy for business customers in Germany, and has it changed since last quarter?” A classical RAG pipeline would embed the entire query and hope that the top chunks cover both aspects. An agentic RAG system, by contrast, identifies two sub-questions, searches for the right source for each (one for the current policy, one for the version history), evaluates the results, and then creates a synthetic answer with citations.

The five components of an agentic RAG architecture

A production-ready Agentic RAG architecture consists of five interlocking components:

1. The orchestrator agent: The LLM-powered brain of the system. It receives the query, plans the next steps, calls tools, and decides whether the gathered information is sufficient for an answer. Frameworks such as LangGraph or LlamaIndex Agents provide the necessary infrastructure for this.

2. Retrieval tools: Unlike in classical RAG, the agent has a toolbox with multiple access methods—vector search for semantic similarity, SQL queries for structured data, web search for current information, and MCP servers for specialized sources. Each tool is described via a schema that the agent can interpret automatically.

3. Query planning and rewriting: The agent breaks complex queries into sub-questions, expands abbreviations, or generates alternative formulations. For ambiguous queries, it creates a mini-plan: “First find the policy document, then search for exceptions, then summarize both.”

4. Self-correction and reflection: After each retrieval step, the agent evaluates the results for relevance and completeness. If the chunks are insufficient, the query is reformulated and searched again. This pattern—known as Corrective RAG or Self-RAG—is the biggest quality lever compared with classical pipelines.

5. The generator: Once enough validated information has been collected, the agent produces the final answer with citations. Because the retrieval process was targeted and self-correcting, the prompt contains less noise, and hallucinations measurably decrease.

Agentic RAG in practice: frameworks and patterns

The technology stack for Agentic RAG consolidated in 2026. LangGraph (from LangChain) has established itself as the standard for state machine orchestration and is replacing older chain-based approaches. LlamaIndex remains the first choice for the retrieval layer and data indexing. For evaluation, specialized platforms such as Ragas (for faithfulness and answer relevancy), Arize Phoenix, and Langfuse are increasingly used.

The costs should not be underestimated: Agentic RAG typically consumes 3–10 times more tokens and has 2–5 times higher latency than one-shot RAG. However, the added value justifies these costs for multi-step questions, ambiguous queries, and safety-critical areas such as law, medicine, or finance. In June 2026, Microsoft published a reference architecture for Agentic RAG on Azure that concretely describes how to get started with LangGraph and LlamaIndex.

Production targets for Agentic RAG that have proven themselves in practice: Faithfulness ≥ 0.9, Answer Relevancy ≥ 0.85, Context Precision ≥ 0.8—measured with Ragas on a golden dataset.

Conclusion

Classical RAG was a breakthrough, but it treated the LLM as a passive consumer of the retrieval result. Agentic RAG reverses this relationship: the model actively decides what to retrieve, where, and how—and whether the results are good enough. By 2026, this pattern has arrived in the mainstream. Platforms such as LangGraph and LlamaIndex provide the tools, evaluation metrics are standardized, and reference architectures from major cloud providers lower the barrier to entry. Anyone who wants to run knowledge-based AI applications in production can no longer avoid agentic retrieval architectures.

Sources

FreeAcademy.ai: Agentic RAG Explained – How AI Agents Supercharge RAG in 2026 — Fundamental introduction to the architecture and components of Agentic RAG.
MarsDevs: Agentic RAG – The 2026 Production Guide (Patterns, Frameworks, and the Cost Reality) — Production-proven patterns, framework comparison, and cost analysis.
Microsoft Learn: Develop an Agentic RAG Solution on Azure — Official Azure reference architecture for agentic RAG (June 2026).
Bacancy Technology: What is Agentic RAG – Architecture, Use Cases & Guide in 2026 — Overview of architectural patterns and use cases.
arXiv: Agentic Retrieval-Augmented Generation – A Survey on Agentic RAG (2501.09136) — Scientific taxonomy of agentic RAG patterns and their classification.

LLM Wiki in Practice 2026: CI Pipelines, Health Checks, and Operating AI Knowledge Bases

saaro — Fri, 23 Oct 2026 12:00:43 +0000

Since Andrej Karpathy published his GitHub Gist on the "LLM Wiki" in April 2026, the pattern has spread rapidly. What started as an initial prompt draft has become a movement: thousands of developers and knowledge workers now operate AI-managed knowledge bases. But practice reveals where the pattern's limits lie – and how CI pipelines, health checks, and clearly defined operational concepts turn an experiment into reliable knowledge infrastructure.

From prompt experiment to daily practice

Anyone who copies Karpathy's Gist into their coding agent will have a working LLM wiki within 15 minutes. The directory structure raw/ → wiki/ + CLAUDE.md is set up quickly. The magic lies in the ingestion process: a new PDF or article lands in raw/, the agent analyzes the document, creates a summary in wiki/sources/, and updates cross-linked concept pages – all automatically.

However, after a few weeks of daily use, patterns emerge that the original Gist does not address. Kunal Ganglani, who used the pattern daily for three months, describes a clear scaling limit: From about 150 to 200 wiki pages onward, no current agent can keep the entire knowledge graph in its context window. The result is inconsistent updates and missed cross-references.

The 200-page limit and the index workaround

The solution is surprisingly simple: a master index (wiki/index.md) that lists every page with a one-line summary and is updated on every ingestion. The agent reads the index first, then selectively chooses the relevant pages for an operation. This technique extends practical capacity to over 300 pages. Anyone maintaining many page types and cross-disciplinary topics cannot avoid this workaround.

The choice of agent is also not a minor detail: While Claude Code and OpenAI Codex work reliably for most workflows, smaller models (under 32B parameters) hit their limits with complex multi-page updates. Qwen3 32B and Llama 3 70B are suitable for basic use cases; according to consistent community experience, more powerful models are needed for full wiki operations with many cross-references.

Health checks as a CI pipeline for knowledge

Karpathy's compiler analogy – raw/ is source code, the LLM is the compiler, wiki/ is the binary – can be thought through to its logical conclusion: If the wiki is the compiled artifact, it needs a test suite. The pattern's third core operation, lint, is exactly that.

A structured lint run checks:

Contradictions: Claims that collide between different sources or pages
Orphaned pages: Wiki pages without incoming links – they are cut off from the knowledge graph
Missing concepts: Terms mentioned across multiple pages but lacking a page of their own
Outdated statements: Claims superseded by newer sources

In practice, automating these checks as a cron job or GitHub Actions workflow has proven effective. A daily lint run, driven by a prompt such as "Check the wiki for contradictions and orphaned pages," keeps the knowledge base clean – without any human intervention. LMMarketCap aptly describes this quality layer as "CI/CD for your knowledge database."

Integration into daily development work

The LLM wiki pattern is not a replacement for RAG, but a complement for a specific use case: vertical synthesis. While RAG scales horizontally (searching through 100,000 support tickets), the LLM wiki excels at the in-depth processing of fewer but higher-quality sources. Synthesizing 50 research papers on one topic and uncovering contradictions in the process is a task for which RAG is naturally ill-suited – while the LLM wiki approach is optimized for it.

Integrating Obsidian as a frontend makes the wiki searchable, linkable, and versionable. Those who take the compiler model seriously also place the entire wiki in a Git repository. The lint process becomes a CI job; faulty "compilations" become visible before they pollute the knowledge base.

Conclusion

The LLM wiki has evolved from Karpathy's prompt sketch into a mature pattern for personal and team knowledge bases. Practice shows: the real art lies not in setting it up, but in operating it. Index-driven navigation beyond the 200-page limit, automated health checks as a CI pipeline, and the deliberate delineation from RAG are the levers that turn a promising experiment into reliable knowledge infrastructure. Those who master these operational concepts have a tool that becomes more valuable with every new source.

Sources

Kunal Ganglani – LLM Wiki Setup: Karpathy's Knowledge Base [2026 Guide] — Practical experience after 3 months of daily use, scaling limits, and agent comparison
Starmorph – How to Build Karpathy's LLM Wiki: The Complete Guide — Complete setup guide with Claude Code, Obsidian, and 3-layer architecture
LMMarketCap – LLM Knowledge Bases: Karpathy's Self-Improving Second Brain — 6-stage pipeline, context window math, and model recommendations
GitHub Gist – Karpathy's llm-wiki.md — Original prompt pattern (5,000+ stars, 5,000+ forks, April 2026)

Kubernetes 1.37 on EKS, AKS, and GKE: Upgrade Deadlines and Support Costs in 2026

saaro — Thu, 22 Oct 2026 12:01:07 +0000

Kubernetes 1.37 „Garhwal" has been available upstream since August 26, 2026 — but for most teams, the release date matters less than the moment their managed provider rolls out the version in production. That moment has arrived in October 2026: Amazon has released 1.37 on EKS, Microsoft is following suit with AKS, and Google is initially holding back with the Rapid Channel. At the same time, a far more urgent deadline is expiring: the end of standard support for Kubernetes 1.34 — anyone who hasn't upgraded by then will pay six times the cluster price on EKS.

EKS, AKS, GKE: The status of Kubernetes 1.37

AWS released Kubernetes 1.37 for Amazon EKS and EKS Distro in early October 2026 — in all regions where EKS is available, including the GovCloud regions and Frankfurt. New clusters can be created directly with 1.37, and existing ones can be updated via the console, eksctl, or infrastructure-as-code. AWS highlights three innovations in the announcement: The Metrics API has reached General Availability with metrics.k8s.io/v1, Dynamic Resource Allocation (DRA) can now schedule devices such as GPUs via Taints and Tolerations, and the Horizontal Pod Autoscaler scales down to zero pods on demand with minReplicas: 0 for object or external metrics (beta, enabled by default).

Microsoft is close behind: On AKS, 1.37 has been in preview since September, with GA planned for October 2026 according to the version calendar. Google is holding back: According to the GKE release notes, 1.37 is only available in the Rapid Channel as of early October. This makes EKS the first of the big three for broad adoption of the new minor version.

The more urgent deadline: End of standard support for 1.34

The more important date for many cluster operators is not the 1.37 upgrade, but the end of support for 1.34. On EKS, standard support ends on December 2, 2026. After that, the cluster automatically switches to Extended Support, which is enabled by default. Instead of 0.10 USD, the cluster then costs 0.60 USD per hour; at 730 hours per month, that amounts to roughly 365 USD in additional costs per cluster. On AKS, 1.34 also ends in November 2026; with Long-Term Support (LTS) enabled, the version remains usable there until November 2027.

The version policies of the providers differ significantly. EKS guarantees 14 months of standard support per minor version, followed by 12 more months of Extended Support — currently four versions in standard (1.34 to 1.37), three in Extended Support. AKS follows a twelve-month policy for GA versions, with optional LTS as a one-year extension. Anyone operating multiple clouds in parallel should factor these calendars into upgrade planning from the start — they are now just as important as the feature decisions of the upstream project.

Upgrade practice: SELinux, version skew, and rollback

When jumping to 1.37, there are three things to consider from an operational perspective. First, the SELinux change: Pods that share a volume with different labels can get stuck in ContainerCreating after the upgrade; nodes without SELinux are not affected. 1.37 should therefore be tested in a non-production environment before the production rollout, ideally with an eye on SELinux-capable nodes. Second, version skew: The Kubernetes policy allows up to three minor versions of difference between the control plane and nodes, but the recommended approach is an identical state — node groups on EKS are not automatically updated with the control plane and must be upgraded separately. Third, rollback: An in-place upgrade on EKS can be reverted to the previous minor version within seven days; after the automatic upgrade at the end of Extended Support, this is no longer possible.

Upstream, 1.37 is one of the most extensive releases of recent times with 67 enhancements. Anyone operating a version beyond its end of support should be aware that the community stops publishing CVE patches after about a year — unpatched control planes then become a security risk without official remediation. This is exactly why providers automatically upgrade at the end of Extended Support, without prior notice.

Conclusion

October 2026 shows how strongly managed Kubernetes is now shaped by version policy: EKS and AKS are rolling out 1.37, GKE follows via the Rapid Channel — and in parallel, the clock is ticking for 1.34. For teams, this means: take the upgrade calendar of your own provider seriously as operational discipline, plan one minor jump per upgrade, and treat Extended Support only as an expensive postponement, not as a permanent state. The next round is coming as scheduled — the Kubernetes project releases a new minor version on average every four months, so 1.38 is expected for December 2026.

Sources

Argo CD Security Landscape 2026: Four Critical Flaws, Three Without CVEs – The Repo Server as an Attack Vector

saaro — Thu, 22 Oct 2026 12:00:32 +0000

Argo CD is the de facto standard for GitOps on Kubernetes: In the 2023 Argo community survey, 93 percent of respondents said they use the tool in production. And right there, at the center of the deployment pipeline, the security situation escalated in October 2026. On October 7, the project released six security advisories in one go — four of them with the highest rating CVSS 9.9 (critical). Three of the four critical vulnerabilities still have no CVE number today. For teams whose patch processes rely on CVE feeds and scanners, this is a structural blind spot. Added to this is a vulnerability in the Repo Server, known since July 2026 and still unpatched, that allows unauthenticated attackers to execute code. Time for a sober look at the attack surface of the most important GitOps controller.

Six advisories, four critical — and hardly any CVE visibility

All six advisories published on October 7, 2026 are fixed in the same four releases: v3.3.15, v3.4.10, v3.5.4 and v3.6.0-rc2. Four of them carry a CVSS rating of 9.9. But only one vulnerability has made it into the NVD so far: CVE-2026-55797, rated 8.8 by GitHub. A second, CVE-2026-77459, has a CVE ID but no NVD entry yet. Three of the four CVSS 9.9 findings have no CVE number at all, and five of the six GHSA records return a 404 in OSV. Anyone who bases their upgrade prioritization solely on CVE feeds sees only a fraction of this wave.

The Repo Server: bottleneck of the GitOps pipeline

Four of the six bugs converge on one component: the argocd-repo-server, the pod that translates Git content into Kubernetes manifests. It holds the Git, Helm, and OCI credentials of all repositories in the installation. Three different attack paths start with content in a repository: a Jsonnet file read path (traceable back to v0.9.0, 2018), a Kustomize remote ref via git fetch --upload-pack (since v2.7.0), and a Helm plugin execution via configHome with --enable-helm.

None of these vulnerabilities require more than the ability to commit content to a repository from which an Application syncs — in the GitOps model, a routine permission for app teams, CI jobs, and increasingly automated agents. The confused deputy effect is the real problem: a developer who is only allowed to change their own namespace ends up in a process that holds the credentials of all tenants — exactly the S:C (Scope Change) appears in all four CVSS vectors.

CVE-2026-55797: Command injection via SSH proxy

The only vulnerability with an NVD entry is a command injection (GHSA-j6cw-g6p4-7hch, CWE-78): For SSH Git repositories with a proxy URL, the proxy host and port are copied unchecked into an SSH ProxyCommand. A hostname with shell metacharacters breaks out of the command and executes arbitrary code in the Repo Server. All versions from v2.11.0 are affected; the behavior was introduced in January 2024 with SOCKS5 proxy support. The vulnerability can be triggered by anyone who can create a repository or a credential template — including project-wide repository permissions or argocd repo add --proxy. The fix validates proxy URLs via an allowlist: SSH proxies only socks5/socks5h, non-empty host, port 1–65535, hostnames exclusively alphanumeric with dots and hyphens.

The AppProject bypass: Multi-tenant GitOps wobbles

For multi-tenant operations, CVE-2026-77459 (GHSA-fmxq-cgp8-87wp, CVSS 9.9, CWE-863) is the most interesting vulnerability: Argo CD normally checks whether an Application matches its AppProject before creating resources — but the PreDelete and PostDelete hooks skip this check entirely and are executed with the Application Controller's credentials on the target cluster. "In a typical installation, this access is broad, so a tenant can create a cluster-wide object like a ClusterRoleBinding," the advisory states. The PostDelete path has "never applied" the project check since v2.10.0.

Unpatched since July: the "Octopus Trap"

Since July 1, 2026, another Repo Server vulnerability has been public for which there is still neither a fix nor a CVE. Synacktiv demonstrated an unauthenticated remote code execution: The Repo Server's internal gRPC service does not check callers; a crafted request to GenerateManifest can redirect the Kustomize options --enable-helm and --helm-command to a script from an attacker's repository. Anyone who reaches the port gets a shell. The researchers reported the vulnerability in January 2025 — about 18 months later it was still unpatched. The escalation continues: With code execution, an attacker reads the Redis password from the environment, poisons the manifest cache, and causes the Application Controller to roll out their own workload on the next sync — a repeat of CVE-2024-31989. Argo CD ships with NetworkPolicies, but the official Helm chart leaves them disabled by default (networkPolicy.create: false). Helm-based installations are therefore often unprotected.

Support cutoff as a risk

All October advisories carry the same sentence: "Argo CD 2.x and 3.0 to 3.2 are out of support and will not receive a patch." The affected code paths sometimes date back to v0.9.0 (2018). Anyone still running 2.x is operating known, published 9.9 RCEs with no prospect of a fix — only an upgrade to 3.3 or newer helps.

What teams should do now

Upgrade: Deploy v3.3.15, v3.4.10 or v3.5.4 — 2.x and 3.0–3.2 will not receive patches. Use the signed release assets (Cosign, SLSA Level 3).
Network isolation: Enable NetworkPolicies. kubectl get networkpolicy -A should show a policy per component; make Repo Server and Redis accessible only to Argo CD's own components.
RBAC: Do not grant repository create/update to untrusted users — not even project-wide.
Monitoring: Watch the Repo Server for unexpected shells and Git clones, Redis for accesses from unexpected sources, and syncs without a matching commit in the repository.
Processes: Do not treat CVE feeds as the sole truth — three of the four critical October vulnerabilities are invisible there. Regularly read the release notes of the projects you use.

Conclusion

The October wave shows two things: The Repo Server has become the crown jewel of the GitOps attack chain, and the severity of a vulnerability and its visibility in scanner feeds are independent variables. GitOps teams should treat Argo CD like tier-zero infrastructure: network policies as standard, least privilege instead of blanket repository write permissions, and monitoring that does not wait for CVE numbers. Those who apply the four patches and close their network boundaries have the wave behind them — those who rely only on scanners may not.

Sources

OpenTofu 1.13: Symbol Libraries, Linting Experiment, and Fewer Unknowns in Planning

saaro — Tue, 20 Oct 2026 12:00:45 +0000

On September 30, 2026, the OpenTofu project released version 1.13.0 — deliberately as a leaner release: The development time was shortened to align with the Go release cycle, which keeps the series under security support longer (until August 2027). Precisely because of the reduced feature load, two experiments are all the more remarkable, as they show where things are heading: built-in linting and a new artifact called "Symbol Libraries." In addition, there are new functions for more precise plans, official Windows ARM64 packages, and some breaking changes to consider when upgrading. For IaC teams, the release is also a good opportunity to review the project's position: OpenTofu is now the established Terraform fork hosted under the Linux Foundation and has been a CNCF sandbox project since April 2025.

Less "(known after apply)" with convert and assume

OpenTofu's core workflow depends on predicting the apply as accurately as possible. Values that cannot be determined during planning appear in the plan as "(known after apply)" — practical, but problematic: The meta-arguments enabled, for_each, and count reject unknown values, and automatic policy checks that evaluate the machine-readable plan output are practically blinded by unknowns.

OpenTofu 1.13 therefore introduces two families of tools with which module authors can give the tool additional hints:

convert() specifies an expected type, for example when an unknown string is parsed via jsondecode: The result remains unknown, but OpenTofu then knows that accessing id yields a string.
The assume... functions (e.g., assumenotnull, assumestringprefix) make statements about the value itself.

A typical example: The id of an AWS resource object is unknown at plan time. With a hint, the comparison with null can be turned into a known false:

output "vpc_id" {
  value = assumenotnull(
    assumestringprefix(
      aws_vpc.example.id,
      "vpc-",
    )
  )
}

The decisive condition: The hints must actually hold true at apply time. If the promised prefix does not match, the function fails during apply. Where provider or API documentation provides a guarantee, such assumptions can be cleanly encapsulated in a shared module.

Two experiments: Linting and Symbol Libraries

Version 1.13 contains very early work on built-in linting: initial infrastructure to enable lint rules and report results as warnings, plus some built-in example rules for the OpenTofu language. The project intends to develop this into a comprehensive feature long-term that also covers policy enforcement.

The second experiment is "Symbol Libraries": reusable collections of values, functions, and type aliases that can be imported from all source types also supported for modules. This allows, for example, an organization-wide convention for DNS records to be defined centrally:

typedef "recordset" {
  type = set({
    name    = string
    type    = string
    ttl     = number
    records = set(string)
  })
}

function "a_records" {
  type = symbols::dns_recordset()
  parameter "records" {
    type = map(set(string))
  }
  parameter "ttl" {
    type = number
  }
  return = [
    for name, ip_addrs in param.records : {
      name    = name
      type    = "A"
      ttl     = param.ttl
      records = ip_addrs
    }
  ]
}

Both experiments are deliberately marked as immature and are not intended for production use — the project is explicitly seeking early feedback from the community.

Windows on ARM64 and the farewell to WinRM

New is official support for Windows on ARM64: The major cloud providers have corresponding windows_arm64 packages; with third-party providers, a provider upgrade may be necessary. On the removal list, on the other hand, is WinRM: The connection types of the remote-exec and file provisioners are no longer supported because the underlying Go libraries are unmaintained. Affected configurations should migrate to OpenSSH for Windows.

Further breaking changes when upgrading

base64gzip now produces equivalent but no longer byte-identical results due to a new DEFLATE implementation — OpenTofu may therefore suggest resource changes; the ignore_changes meta-argument serves as a transition.
macOS builds require at least macOS 13 Ventura.
v1.13 is the last series with official 32-bit packages (386, arm); calling tofu init warns about this, and v1.14 will remove them entirely.
The first patch, v1.13.1 from October 1, fixes among other things tofu show -json with ephemeral resources.

Where OpenTofu stands in 2026

The fork was created in August 2023 after HashiCorp converted Terraform from MPL 2.0 to the Business Source License; since September 2023 the project lives under the Linux Foundation, the first stable version 1.6.0 was released in January 2024, and CNCF acceptance as a sandbox project followed in April 2025. In 2026, OpenTofu continues to introduce features that Terraform does not offer — such as built-in state encryption (1.7), early variable evaluation (1.8), and dynamic prevent_destroy (1.12); provider for_each (1.9) and ephemeral values (1.11) also came first in OpenTofu. Currently, the 1.11, 1.12, and 1.13 lines are maintained; patch 1.12.7 most recently closed security gaps in the SSH provisioner (CVE-2026-78662, CVE-2026-56855). Major companies are also migrating: Fidelity Investments documented its migration from Terraform to OpenTofu in the official blog.

Conclusion

OpenTofu 1.13 is a signal release: With the assume... functions, planning becomes more precise, and the experiments on linting and symbol libraries point to the next evolutionary stage of the tool — quality assurance and reusable logic directly in the core instead of in external tools. Teams should plan for WinRM removal, base64gzip changes, and the 32-bit deprecation when upgrading. Looking at v1.14 (without 32-bit packages) and the 1.13 series supported until August 2027 is worthwhile for every IaC roadmap — OpenTofu is no longer a side project in 2026, but an independent force in the IaC ecosystem.

Sources

OpenTofu v1.13.0 (official blog post) — feature details, experiments, breaking changes
opentofu/opentofu Releases (GitHub) — v1.13.0/v1.13.1/v1.12.7, support periods, CVEs
OpenTofu Blog — incl. "An Introduction to OpenTofu Symbol Libraries" (09/17/2026), "A Vision for Built-in Linting" (09/03/2026), Fidelity migration report
Spacelift: OpenTofu – The Open-Source Alternative to Terraform — project history, release cadence, feature timeline
env.dev: OpenTofu in 2026 — Terraform comparison, migration path

From Vibe to Context: Do We Still Need the Spec?

saaro — Tue, 20 Oct 2026 12:00:09 +0000

As of: October 2026. Anyone working today with Claude Code, Copilot, Cursor, or similar tools knows the tension: On one hand, the models have become so powerful that a rough task assignment often carries surprisingly far. On the other hand, you quickly notice in real projects that good results rarely come from just a good one-liner. This is exactly where the line runs from Vibe Coding to Context Engineering. The pointed thesis of this article is therefore: Yes, strict prompt specifications are becoming less important in some situations. But the effort does not disappear – it shifts from formulating individual prompts to designing the project context.

Vibe Coding: Concept, Promise, Early Practice

The term "vibe coding" goes back to Andrej Karpathy. In his much-cited X post from February 2, 2025, he described a style where you "almost forget the code," request changes in everyday language, simply throw errors back into the model, and often even hit "Accept All" without thoroughly reading diffs. This was not a precise methodology, but rather a deliberately pointed description of a new practice: type less, say more, iterate quickly, trust the model.

The appeal is obvious. For greenfield ideas, throwaway prototypes, UI sketches, or small helper tools, this approach can be very productive. Anyone building a form, a small script, or a simple service on a common stack benefits from the fact that models already know many common patterns from training. In such situations, Vibe Coding is not just laziness, but a form of leverage: less friction between idea and first working result.

But even in Karpathy's original text, the warning is included. He explicitly writes about "throwaway weekend projects" and about how the code can grow beyond its usual depth of understanding. That is exactly where the risks begin: vague requirements, blind acceptance of changes, hard-to-detect security issues, and technical debt that only becomes visible later. Independent studies from 2025 and 2026 support exactly this skepticism: LLM-generated code can appear functional and still contain security or quality issues that easily slip through without additional review.

The Shift: Why the Loose Prompt Became a Context Craft

That the term Context Engineering subsequently established itself is no coincidence. Anthropic describes Context Engineering as the evolution of Prompt Engineering: Not only the words in the prompt count, but the entire set of tokens and signals the model sees in a situation – system instructions, tools, external data, message history, MCP context, and other states. The focus thus shifts from "How do I formulate the request?" to "What information should the model see at which moment at all?"

The reason for this lies in the way today's coding and agent tools work. Modern agents no longer operate in a single turn, but in loops with tools, intermediate states, and follow-up decisions. The potentially relevant context grows constantly. It is then not enough to overwhelm a model with as much text as possible. You have to select, structure, and reload at the right time.

That is precisely why project files like CLAUDE.md or AGENTS.md, stored memory entries, skills, and subagents have become so important. Anthropic openly documents that CLAUDE.md files load permanent project rules, architecture notes, and working conventions into every session, while Auto Memory makes corrections and patterns available across sessions. Subagents, in turn, are explicitly used to process subtasks in their own context window so that the main conversation does not get clogged with trivialities. This is exactly the opposite of "one big prompt solves everything."

Context Engineering therefore does not primarily mean longer prompts. It means better context architecture. Which project rules always apply? Which information does only a specialist agent need? What is stored permanently, what is loaded just in time? And what must the human explicitly specify because the model cannot possibly know it from training?

The Thesis Put to the Test

Now to the actual thesis: "Today's models are so good that tight context specifications are often no longer necessary. Often a few sentences describing the project are enough."

The fair finding is: That is sometimes true. And that is exactly what makes the thesis so attractive.

It holds especially where tasks are close to common patterns. In a fresh project with a standard stack, well-known libraries, and a manageable target, models can supplement surprisingly much. A rough assignment like "build a small FastAPI service with JWT login, PostgreSQL, and tests" often already delivers a surprisingly usable starting point today. For small features, prototypes, or internal tools, the gap between a brief instruction and a working draft has become significantly smaller. This is not because context is unimportant, but because part of the context is already embedded in the model: framework conventions, standard project structures, common test patterns, familiar API forms.

But the thesis breaks down where the decisive factor is not in general training knowledge. Large, evolved codebases contain local truths: internal shortcuts, historical architecture decisions, team conventions, special cases in deployment, implicit security assumptions, legacy interfaces, and maintainability rules. This knowledge is precisely not guessable for the model. Anyone starting here with only two sentences gets not "less specification," but more often hallucinations with a professional tone.

Added to this is a second breaking point: Quality and security are not automatically derivable from high model capability. A quantitative analysis from 2025 concludes that functional correctness is not a reliable indicator of code quality and security; precisely for this reason, static analyses and additional verification are necessary. Another study on agentic program repair on SWE-bench shows that agentic workflows can also create new vulnerabilities – especially when more autonomy is allowed and context about the issue and codebase is incomplete. In short: Better models reduce some friction, but they do not eliminate the costs of missing context information.

A Small Experiment for Everyday Use

Anyone who wants to test the thesis themselves does not need a large research environment. A small team experiment is enough. Take an identical task in a real but non-critical codebase – for example: "Add a new filter option in the search dialog, including tests and documentation." Have the model work once with only a brief short description. In the second run, give it structured context: relevant files, architecture note, acceptance criteria, project rules, test command, and two typical pitfalls.

Compare not only "works" or "doesn't work," but also: number of follow-up questions, number of subsequent corrections, quality of tests, adherence to conventions, readability of changes, and review effort. My expectation would be: For small, generic tasks, the difference is smaller than in 2024. But as soon as project knowledge, constraints, and non-obvious standards become important, the structured context should perform more robustly.

Where the Boundary Lies

The boundary thus runs less between "old" and "new" models than between task types. Vibe-like approaches work well where the model can plausibly fill in missing details from known patterns. They become risky where missing details are domain-specific, architectural, or security-relevant.

It becomes particularly critical in four situations. First, in large legacy projects: Here, local knowledge is more important than general framework knowledge. Second, with implicit team rules: If naming, error handling, or release practices are not made explicit, the model optimizes for plausibility, not for your reality. Third, with security and maintainability requirements: Studies show that AI-generated code can still exhibit systematic weaknesses. Fourth, in longer agentic chains: The more loops, tools, and intermediate steps involved, the more important good context management becomes instead of mere hope in model intelligence.

Conclusion and Recommendation

So does the specification effort disappear? No. It shifts. Some prompt tricks from the early phase become less important: artificially inflated role prose, rigid formulation recipes, and over-optimized one-shot prompts. What becomes more important, on the other hand, are the things the model cannot derive from world knowledge: acceptance criteria, project rules, architecture boundaries, decision logs, relevant files, test and security requirements.

My concrete recommendation is therefore: Use short prompts where the problem is generic. But invest deliberately in reusable project context as soon as the same rules apply multiple times. Write CLAUDE.md or AGENTS.md, keep acceptance criteria brief and explicit, use memory for recurring corrections, and separate research, implementation, and review more strongly via specialized agents or subagents. The future lies not in the choice between Vibe Coding and specification. It lies in knowing when a few sentences are enough – and when missing context will later cost more than any clean specification at the start.

Sources

Fine-Tuning with LoRA and QLoRA 2026: Adapting Open-Source LLMs on Consumer Hardware

saaro — Mon, 19 Oct 2026 12:00:57 +0000

Adapting large language models (LLMs) to enterprise-specific domains was long considered an expensive undertaking: hundreds of GPU hours and specialized infrastructure seemed necessary to fine-tune a model such as Llama, Mistral, or Qwen on one’s own data. This has now fundamentally changed. With LoRA (Low-Rank Adaptation) and its quantized variant QLoRA, teams can fine-tune even 70B-parameter models on commercially available GPUs – with minimal quality loss and a training effort that often takes just one hour.

In 2026, the question is no longer whether you can afford fine-tuning, but whether you can afford to go without it. The following article shows how these methods work, where they are usefully applied, and which tools have become established.

How LoRA and QLoRA work

LoRA, introduced by Microsoft Research in 2021, pursues an elegant approach: instead of completely updating the billions of weights of a pre-trained model, small, trainable adapter matrices are inserted into the transformer layers. Only these adapters – typically 0.4 to 6 percent of the total parameters – are changed during training. The base weights remain frozen. The result: instead of 7 billion parameters, training a 7B model with LoRA involves only about 4 million – a reduction by a factor of 1,700.

QLoRA, developed by Tim Dettmers and colleagues at the University of Washington, goes one step further. It quantizes the base model to 4-bit precision (NF4 format) and combines this with double quantization and paged optimizers. This further massively reduces memory requirements:

Method	VRAM (7B)	VRAM (13B)	VRAM (70B)
Full Fine-Tune	~112 GB	~208 GB	~1.1 TB
LoRA (16 Bit)	~28 GB	~52 GB	~280 GB
QLoRA (4 Bit)	~6 GB	~10 GB	~48 GB

The quality loss is minimal: QLoRA achieves about 95 percent of the full fine-tune quality, LoRA about 97 percent. For most practical applications, this difference is negligible.

When fine-tuning makes sense – and when it doesn’t

One of the most important insights of recent years is that fine-tuning is not universally the best solution. The Prompt Quorum guide and the authors of Precision AI Academy agree: before any fine-tuning project, the decision matrix should be worked through.

Step 1: Prompting. A good system prompt with 3–5 few-shot examples solves 80 percent of all tasks. Only proceed if no satisfactory results are achieved here.

Step 2: RAG. Does the model need new knowledge (current documents, internal policies)? Then Retrieval-Augmented Generation (RAG) is the right approach – not fine-tuning.

Step 3: Fine-tuning. Only when the problem is a behavioral problem – consistent format, specific tone, domain-specific terminology that the base model does not reliably master – does it make sense to move to fine-tuning.

The rule of thumb: fine-tuning teaches a model new behavior, not new knowledge. If you want to inject facts, use RAG.

Practical: Tools and data requirements

The toolbox for LoRA/QLoRA is mature in 2026:

Unsloth is considered the fastest framework – up to 2× faster than standard Hugging Face training with 70 percent less VRAM. It supports Llama 3.x, Qwen3, Mistral and Gemma 4 and has been part of the official PyTorch ecosystem since May 2026.
Hugging Face TRL + PEFT remains the robust standard option with SFTTrainer for supervised fine-tuning and comprehensive LoRA/QLoRA support.
Axolotl offers maximum flexibility via YAML configuration and also supports multimodal models.

Data quality is crucial. According to a study by Particula Tech, 100–300 examples per category suffice for classification tasks, 200–500 for structured extraction, 500–2,000 for content generation, and 1,000–5,000 examples for complex domain adaptation. Quality matters more than quantity: 200 curated examples beat 2,000 messy ones.

After training, the LoRA adapter is merged into the base weights and exported as a GGUF file. The resulting model can then be run seamlessly in Ollama, LM Studio or llama.cpp – without additional dependencies.

Cost framework 2026

The cost of a fine-tuning run is now manageable. A LoRA run with Llama 3.1 8B and 1,000 examples costs around $0.30 on a RunPod RTX 4090 and takes 20 minutes. Even a 70B model can be realized with QLoRA on two RTX 4090s for about $15–36 per run. A free Colab T4 GPU (16 GB VRAM) is sufficient to train most 7B models via QLoRA.

Conclusion

LoRA and QLoRA have democratized fine-tuning of open-source LLMs. What required expensive GPU clusters two years ago now runs on consumer hardware or in the cloud for a few dollars. The combination of mature frameworks (Unsloth, PEFT, TRL) and efficient methods makes it affordable for any team to build specialized models – whether for customer support, code generation, or document analysis. The key lies in the discipline of always checking prompting and RAG before fine-tuning. Those who follow this can turn a generic open-source LLM into a domain-specific assistant in just a few hours.

Sources

PromptQuorum: LoRA Fine-Tuning für lokale LLMs 2026: Unsloth auf 8 GB VRAM – aktualisiert Juni 2026
Kunal Ganglani: Fine-Tune Open-Source LLMs – LoRA & QLoRA 2026 Guide – September 2026
Particula Tech: How Much Data Do You Need to Fine-Tune an LLM in 2026? – 2026
Precision AI Academy: LLM Fine-Tuning Explained 2026 – April 2026
Noqta: Fine-Tuning LLMs with LoRA & QLoRA – 2026 Developer Guide – Mai 2026

LLM Wiki 2026: Karpathy's Pattern for Self-Managing AI Knowledge Bases

saaro — Sat, 17 Oct 2026 12:01:27 +0000

In April 2026, Andrej Karpathy – co-founder of OpenAI and former AI lead at Tesla – published a short GitHub Gist that gathered over 5,000 stars within days and received more than 16 million views on X. His topic: a new pattern for handling knowledge with Large Language Models. Instead of re-searching and re-analyzing documents with every query (as RAG systems do), Karpathy proposes that an AI agent builds and continuously maintains a persistent, structured wiki of Markdown files. The idea struck a nerve – and has since changed how developers and knowledge workers design their personal research environments.

The Core Problem: Stateless Knowledge

Most AI knowledge tools today work on the same principle: upload files, split them into chunks, embed them into a vector database, and retrieve the relevant pieces for each question. NotebookLM, ChatGPT uploads, and virtually all RAG systems operate that way. The problem: The AI rediscovers knowledge with every question. There is no accumulation. When a complex question is asked that requires synthesizing five documents, the model must find and assemble the appropriate fragments anew each time. Nothing is retained, nothing grows.

Karpathy’s diagnosis: The most expensive part of a knowledge base is not reading or thinking – it is bookkeeping: cross-references, summaries, deduplication, conflict detection. These are precisely the tasks for which LLMs are disproportionately well-suited, and which humans reliably abandon after two weeks.

The Three-Layer Architecture

The LLM wiki pattern consists of three clearly separated layers:

Layer 1 – Raw sources (raw/): This is where the immutable source documents land: PDFs, articles, papers, screenshots, transcripts. These files are never modified after ingestion – they serve as an archived source of truth.

Layer 2 – The Wiki (wiki/): An AI agent incrementally compiles the raw documents into a structured collection of Markdown files. Each file is a Wikipedia-like entry for a concept or entity, linked via [[Wiki-Links]], categorized, and annotated with source citations. Karpathy himself reports that his research wiki has grown to roughly 100 articles with over 400,000 words – without him writing a single line.

Layer 3 – Schema (CLAUDE.md or schema.md): This is where the rules are defined: How should new pages be created? What categories exist? How are contradictions handled? This schema is the most important file – it controls how the agent builds and maintains the wiki.

The analogy to a compiler is obvious: raw/ is the source code, the LLM agent is the compiler, the wiki is the binary, and the health checks are the test suite.

The Three Operations: Ingest, Query, Lint

The pattern defines three fundamental workflows:

Ingest: A new document is placed in raw/. The agent reads it, extracts the core information, and integrates it into the existing wiki – updates existing pages, creates new entries for unknown concepts, sets cross-references, and flags contradictions.
Query: Instead of searching through chunks RAG-style, the agent navigates the already-compiled wiki, follows links, and synthesizes answers from the already interlinked entries. The answer is not only faster, but more informed – because the wiki already integrates all previous sources.
Lint (Health Checks): Regular audit runs identify dead links, orphan pages, contradictions, or gaps. Like a linter for code, the health check ensures the knowledge base remains clean and consistent.

LLM Wiki vs. RAG: Which Approach When?

The LLM wiki is not a universal RAG replacement, but a tool with specific strengths:

Criterion	RAG	LLM Wiki
Knowledge persistence	None – stateless	Full – builds upon
Multi-document synthesis	Per query, new	Pre-compiled
Conflict detection	No	Yes
Setup effort	Low	Medium
Source traceability	High (chunk-level)	Medium (page-level)
Ideal for	Quick Q&A, frequently changing data	Deep, growing research topics

RAG is the better choice when data changes daily or exact source tracking at chunk level is critical. The LLM wiki excels when building expertise over weeks and months – and when the model needs to reason across the knowledge base, not just retrieve from it.

Tools and Community

The barrier to entry is remarkably low. All that is needed is a folder on your computer, an LLM agent (Claude Code, OpenAI Codex, OpenCode), and optionally Obsidian as a frontend for the graph view. Within weeks, the community has produced numerous implementations: an Obsidian plugin for LLM Wiki, LLM Wiki apps, CI pipelines for automatic health checks, and even Google’s Open Knowledge Format, which extends the pattern with a common standard.

Conclusion

Karpathy’s LLM wiki pattern is more than just another AI trend – it is a fundamental shift in perspective. Instead of using LLMs as mere query engines for raw documents, they become active curators of a growing knowledge base. The key insight: LLMs are better at managing knowledge than humans – and humans are better at curating and evaluating. This pattern distributes the work where it is most effective. For anyone regularly working with deep research and expanding knowledge domains, the LLM wiki in 2026 is the most promising approach to rethinking personal knowledge work.

Sources

Karpathy’s original GitHub Gist: llm-wiki.md (April 2026) — 5.000+ stars, the original idea
DecodeTheFuture: LLM Wiki – Karpathy’s 3-Layer Pattern vs. RAG (2026) — Detailed analysis of the architecture
Data Science Dojo: LLM Wiki Tutorial – Build a Compounding Knowledge Base — Step-by-step guide for getting started
Starmorph: Complete Guide to Karpathy’s LLM Wiki (April 2026) — Comprehensive guide with Claude Code and Obsidian
Agentpedia Codes: Karpathy’s LLM Knowledge Bases – The Post-Code-AI Workflow — German analysis of the paradigm shift
Denser AI: LLM Wiki – Karpathy’s Idea for AI Knowledge Bases — Overview of the most important projects

OpenTelemetry 2026: CNCF Graduation, Kubernetes Processor, and the Dawn of a New Observability Era

saaro — Sat, 17 Oct 2026 12:00:51 +0000

OpenTelemetry underwent a remarkable maturation process in 2026: In May, the project graduated at the CNCF, in September the Kubernetes Attributes Processor followed with version 1.0.0, and numerous other milestones – from Continuous Profiling to specific Semantic Conventions for AI – make the year a turning point for vendor-neutral observability. What do these developments mean for teams relying on OpenTelemetry?

CNCF Graduation: A Standard Comes of Age

On May 21, 2026, the Cloud Native Computing Foundation (CNCF) announced the graduation of OpenTelemetry at the Observability Summit in Minneapolis – the same maturity status that Kubernetes, Prometheus, and Envoy achieved before it (1). The graduation is not just a marketing badge: It requires an independent security audit, a formal governance review, and the approval of the CNCF Technical Oversight Committee, sponsored by Emily Fox and Davanum Srinivas (1).

OpenTelemetry is thus the project with the second-highest development velocity in the CNCF ecosystem – only Kubernetes is ahead of it (1). Over 12,000 contributors from more than 2,800 companies have contributed to the project. The sheer download volume speaks for itself: The JavaScript API package was downloaded 1.36 billion times in the twelve months before graduation, the Python API package 1.3 billion times – both with new monthly records in April 2026 (1).

Kubernetes Attributes Processor Becomes Stable

A concrete milestone followed in September 2026: The Kubernetes Attributes Processor of the OpenTelemetry Collector reached version 1.0.0 and thus "Stable" status (2, 3). The processor enriches logs, metrics, and traces with Kubernetes metadata – such as pod names, namespaces, nodes, and workloads. This turns generic telemetry into data material that can be searched and correlated according to Kubernetes context.

The release was more complex than a regular release because it had to be coordinated with the underlying Kubernetes Semantic Conventions. These reached the release candidate in March 2026 and achieved stability with Semantic Conventions version 1.42.0 in June (2). The price: some attribute names changed, for example container.image.tag to container.image.tags. OpenTelemetry provides feature gates to support both naming conventions in parallel during the migration (2).

The processor is stable for logs, metrics, and traces; profiles remain under development for now (3). The OpenTelemetry documentation points out limitations with host-networked pods and sidecar deployments, as well as the growing memory requirements of the in-memory cache in large environments (2).

2026 as a Turning Point for Observability

The Grafana Labs trend analysis for 2026 aptly summarizes the development: OpenTelemetry would become the standard in 2026 – teams would no longer ask whether they should use OpenTelemetry, but why they weren't using it yet (4). All major cloud providers (AWS, Google, Microsoft) natively support OpenTelemetry, and the OTLP protocol has established itself as a universal exchange format (4).

Three other developments shape the year:

Continuous Profiling as the Fourth Signal: In addition to traces, metrics, and logs, the profiling signal – based on the Linux-perf format and eBPF collection – reaches alpha status, with a targeted GA by Q3/Q4 2026 (5). This will allow teams to analyze CPU and allocation costs directly in the OTel stack without relying on separate profiling tools.

Java Agent 3.0: The OpenTelemetry Java Agent reached version 3.0 as a target release in October 2026, after version 2.32.0 served as the release candidate (6). The agent receives fundamental architectural changes and is one of the most widely used language SDKs in the ecosystem.

GenAI Observability: The Semantic Conventions for generative AI became the de facto vocabulary for the observability of AI models in 2026. Every major provider supports them, even though the specification itself is still under development (4). This allows hallucination rates, prediction freshness, and the quality of AI outputs to be displayed in the same dashboards as API latencies and error rates.

What the Cost Side Shows

A side effect of the graduation: OTLP is now a cemented industry standard. For platform teams, switching to self-hosted observability backends (like SigNoz or OpenObserve) becomes calculable. A comparison shows: At 1.5 TB

Vector Databases 2026: Milvus 3.0, Qdrant, and the Postgres Question

saaro — Wed, 14 Oct 2026 12:00:46 +0000

Anyone bringing a RAG pipeline into production in 2026 cannot avoid vector databases: they are the backbone of retrieval-augmented generation, the dominant enterprise AI architecture. But the category is undergoing a profound transformation. In July 2026, Zilliz presented Milvus 3.0, an architecture that runs vector retrieval directly in the data lake; in March, Qdrant closed a $50 million Series B and is growing with agent workloads; and PostgreSQL with pgvector is taking over an ever larger share of the smaller use cases. The

MCP 2026: The Overhaul to a Production-Ready Agent Protocol

saaro — Wed, 14 Oct 2026 12:00:10 +0000

Vor knapp zwei Jahren hat Anthropic das Model Context Protocol (MCP) vorgestellt, um KI-Modelle standardisiert mit externen Tools und Datenquellen zu verbinden. Aus dem Experiment ist längst die Integrationsschicht der Agentic-KI geworden: Die Tier-1-SDKs verzeichnen inzwischen rund eine halbe Milliarde Downloads pro Monat, die TypeScript- und Python-SDKs haben jeweils die Milliarden-Marke überschritten. Im Mai 2026 warnte die NSA erstmals formal vor Sicherheitslücken des Protokolls, im Juli 2026 folgte die bislang tiefgreifendste Revision der Spezifikation. MCP wird erwachsen — und genau das verändert, wie Teams Agenten bauen und betreiben.

Abschied vom Session-Zwang: der stateless Core

Das Herzstück der Revision 2026-07-28 ist ein stateless Protokollkern. Der initialize/initialized-Handshake und der Mcp-Session-Id-Header sind ersatzlos entfallen. Jede Anfrage trägt ihre Protokollversion, Client-Identität und Capabilities selbst in _meta mit; wer die Fähigkeiten eines Servers vorab kennen will, nutzt optional den neuen server/discover-Aufruf. Die Folge ist praktisch bedeutsam: Eine Anfrage kann auf jede beliebige Instanz hinter einem einfachen Round-Robin-Load-Balancer landen, ohne dass die Instanzen gemeinsamen State halten müssen. Horizontale Skalierung, wie man sie von normalen HTTP-Diensten kennt, wird damit erstmals ohne Workarounds möglich.

The New Stack weist in seiner Einordnung auf einen wichtigen Punkt hin: „The protocol stopped managing state, which is not the same as the state going away." Wer als Server Anwendungszustand braucht, verwaltet ihn jetzt explizit — etwa über Handles, die das Modell als Argument zwischen Tool-Aufru

Obsidian 2026: Knowledge Management in the AI Era – MCP, Local LLMs, and Agents in the Vault

saaro — Tue, 13 Oct 2026 12:01:32 +0000

Obsidian has long established itself as a serious knowledge management platform in the Personal Knowledge Management community: local Markdown files, open data storage, and a large plugin community. In 2026, however, the discussion has shifted — away from the question of which app has the best interface, towards the question of which app can best connect with AI. The standard for this is the Model Context Protocol (MCP), and Obsidian benefits doubly from it: as a data source for AI agents and through plugins that bring LLMs directly into the vault.

The Vault as a Data Source: Connecting Obsidian via MCP

The Model Context Protocol has established itself as an open standard through which AI applications communicate with external systems. For Obsidian, there are several MCP servers that give an AI assistant direct access to the vault — to every Markdown file, every folder, and every link between notes. A prominent example is mcp-obsidian, an MCP server that accesses the vault via the Local REST API community plugin and is widely used with around 4,500 stars on GitHub.

The central difference to cloud solutions like Notion lies in the architecture: The Obsidian MCP server runs as a local process on your own computer, reads files directly from the file system, and communicates with the AI tool via stdio — without network access and without an API key for the vault. A comparison from April 2026 highlights that this means no API rate limits exist, full-text search in the vault responds in milliseconds, and notes never leave the computer. The traceability of Wikilinks is particularly striking: An agent can follow the link graph and ask, for example, which notes are connected to a concept — a transformative capability for Zettelkasten and Evergreen users.

Local LLMs: Smart Connections and Copilot as a Duo

Those who do not want to use a cloud API can run LLMs completely locally. A guide from May 2026 recommends the combination of two plugins for this: Smart Connections handles vault-wide semantic search via local embeddings (e.g., nomic-embed-text or mxbai-embed-large via Ollama), while the chat runs via Copilot for Obsidian, which is pointed at the OpenAI-compatible Ollama endpoint at http://localhost:11434/v1. Together, both plugins cover around 80 percent of the typical use cases of a "second brain" — semantic search and chat with notes — without vault contents reaching the cloud. A tip during setup: The initial indexing of embeddings can take a few minutes depending on vault size and should be completed before further AI plugins are activated. For mobile devices, Ollama can be made accessible via a home server on the LAN or a mesh VPN like Tailscale.

Copilot V4: Agents Directly in the Vault

The most significant development of the year is the step from pure chat plugins to real agents: Copilot V4 brings full-fledged coding agents into Obsidian with opencode, Claude Code, and Codex. The plugin is the most used AI plugin with over 2.4 million downloads and was awarded the "Best LLM Integration Award" by the Obsidian community in 2024; version 4.0.13 was updated in early October 2026. The agent mode can inspect notes, create files, and work across multiple steps. Users choose between their own API keys, local models, or hosted models — plugin version 4 also supports projects with custom instructions, reusable skills, and saved commands.

Data Protection: Stay Local, But Choose Consciously

Obsidian itself stores notes privately on the device. With AI integration, the choice of backend determines the data flow: With local models, neither notes nor prompts leave the computer. If you use cloud APIs, messages and sent note context go to the respective provider. The Copilot plugin developer Brevilabs emphasizes that when using the free version with your own backend, no data is transmitted to their servers; only hosted features process requests server-side. Those processing sensitive notes should therefore choose these routes consciously.

Conclusion

In 2026, Obsidian has evolved from a note-taking app to a hub for AI-powered knowledge work: Via MCP, the vault becomes a data source for external agents; via plugins like Smart Connections and Copilot, local, privacy-friendly assistants are created within the vault itself. The combination of an open file format, local operation, and an active plugin ecosystem makes Obsidian an interesting foundation for anyone who wants to connect their knowledge base with AI without giving up control over their own data. It remains to be seen in which direction the agent integrations — particularly the collaboration of coding agents with the vault — will develop further in the coming year.

Sources

Obsidian MCP vs Notion MCP: Best Notes MCP Server (2026) | Skiln — Comparison of MCP architectures, April 2026
Copilot – Obsidian Plugin | Obsidian Community Plugins — Plugin details, version 4.0.13, October 2026
Beste Obsidian-Plugins für lokales LLM mit Ollama 2026 | PromptQuorum — Guide to local LLM plugins, May 2026
MarkusPfundstein/mcp-obsidian | GitHub — MCP server for Obsidian via the Local REST API