DEV Community: Rashid

AI Agent Memory Explained: How Coding Agents Remember (and Why They Forget)

Rashid — Wed, 21 Oct 2026 16:38:49 +0000

Close a long coding session, open a new one tomorrow, and your AI agent greets your codebase like a stranger. The architecture decision you explained twice, the test command that only works with a certain flag, the library you told it never to touch: gone. That isn't a bug in one product. By default, a language model starts every session with a blank slate, and everything it "knows" about your project has to be put back in front of it each time.

AI agent memory is the set of techniques that fixes this. It decides what an agent writes down, where it stores it, and what it pulls back into view later. It sounds simple, but it is increasingly where the gap between a useful coding agent and a frustrating one comes from.

Quick answer: AI agent memory is any mechanism that lets an agent keep and reuse information beyond a single context window, from a plain markdown file like AGENTS.md to a dedicated memory layer built on vector search or knowledge graphs. Researchers usually split it into working memory (what is in the context window right now) and three long-term types: episodic (past experiences), semantic (facts), and procedural (how to do things). Which approach works best is still one of the most debated questions in agent design, and many of the benchmark numbers you will see published are by the vendors selling the tools.

Why AI Agents Forget Between Sessions

A model only "sees" what is inside its context window for the current session. When the session ends, so does that view. Nothing about your project carries over unless something puts it back.

The obvious fix is to paste more into the window, but that runs into a problem Chroma documented in its 2025 "context rot" research. The team tested 18 leading models and held task difficulty constant while only increasing input length. Performance became less reliable as inputs grew, even on simple tasks, and in uneven, hard-to-predict ways. In other words, a bigger pile of remembered text is not automatically a better memory.

That is the same underlying problem behind context engineering: the skill is deciding what deserves to be in the window at all. Memory is the storage side of that decision. It also complements repository intelligence, which helps an agent understand the code itself, while memory holds what the agent learned while working on it.

The Four Types of AI Agent Memory

The most common reference point is CoALA (Cognitive Architectures for Language Agents), a 2023 framework from Princeton researchers. It describes short-term working memory plus three long-term memories, borrowed loosely from cognitive science.

Memory type	What it holds	Coding-agent example
Working	Whatever is active in the current context window	The files and errors in front of the agent right now
Episodic	Experiences from earlier runs	"Last time this migration failed because of a missing environment variable"
Semantic	Facts about the world and the project	"The API is versioned under /v2 and uses PostgreSQL"
Procedural	How to do things	Build and test commands, coding conventions, reusable skills

The framework makes one point worth remembering. Letting an agent write new knowledge into episodic or semantic memory is relatively low-risk, but letting it rewrite its own procedural memory is significantly riskier, because that can introduce bugs or let the agent drift from what its designers intended. For coding agents, the practical version is simple: be careful about letting an agent edit its own instructions without review.

How Coding Agents Remember in Practice

Most of today's real-world agent memory is far less exotic than the research papers suggest.

Instruction files. The simplest memory is a markdown file the agent reads at the start of every session. AGENTS.md is the open version of this idea. When OpenAI contributed it to the Agentic AI Foundation under the Linux Foundation in December 2025, it said the format had been adopted by more than 60,000 open-source projects and agent frameworks since its August 2025 release, including Codex, Cursor, GitHub Copilot, and Gemini CLI. Anthropic's Model Context Protocol was contributed to the same foundation. Claude Code uses a similar convention with CLAUDE.md files. Because these are plain files in your repository, they are versioned, reviewable, and shared with your whole team.

Agent-written notes. Claude Code also has a second system called auto memory, where Claude writes its own notes as it works, such as debugging insights and corrections you gave it. Anthropic documents it as separate from CLAUDE.md, which holds instructions you write yourself. The notes are stored locally on your machine in a per-project folder rather than in your repository, only the start of the index file loads at the beginning of a session, and you can browse or switch it off with the /memory command. In CoALA terms, CLAUDE.md is roughly the procedural and semantic memory you author, while auto memory is closer to episodic notes the agent writes for itself.

Memory tools and context editing. Anthropic's memory tool lets Claude store and look up information outside the context window through a file-based system, and it runs entirely client-side through tool calls, so developers control where the data lives. It pairs with context editing, which clears stale tool calls and results as the window fills up. In Anthropic's own internal evaluations, combining the two improved performance by 39% over a baseline, and context editing alone improved it by 29%. In a 100-turn web search evaluation, context editing reduced token use by 84% and let workflows finish that would otherwise have failed from running out of context. Those are Anthropic's numbers on Anthropic's tests, so treat them as a direction rather than a guarantee for your own project.

Compaction and fresh sessions. Many tools also summarize a long conversation into a shorter version when the window gets crowded, or encourage starting a clean session and carrying forward only a short summary. It is crude compared with a dedicated memory system, but it directly attacks the context rot problem.

Memory Layers and the Benchmark Argument

Beyond files, a growing category of dedicated memory layers extracts facts from conversations, stores them in a vector database or knowledge graph, and retrieves the relevant ones for each new request. Mem0, Zep, and Letta are among the best-known names.

This is also where the numbers get contested. Mem0's 2025 research paper reported a 26% relative accuracy gain over OpenAI's memory feature on a benchmark called LoCoMo, plus a 91% lower p95 latency (about 1.4 seconds versus about 17 seconds) compared with feeding in the full conversation. Zep, a competitor, publicly disputed how its own system had been configured in that comparison. Letta, which grew out of the MemGPT research project at UC Berkeley, then reported that a plain agent with simple file tools scored 74.0% on LoCoMo using GPT-4o mini, above the 68.5% Mem0 had reported for its best graph variant. Mem0 has since rewritten its pipeline and says it now scores 92.5% on the same benchmark.

None of these figures are directly comparable, and each comes from a company with a product to sell. One independent analysis also pointed out that LoCoMo conversations are short enough to fit comfortably inside a modern context window, which limits what the benchmark can prove about long-term memory. The useful lesson is not which vendor wins. It is that simple file-based memory is a serious baseline, and that independent evaluation of agent memory is still thin.

What Can Go Wrong With Agent Memory

Memory adds new failure modes that a stateless agent does not have.

Stale facts. Code changes faster than notes do. An agent that confidently remembers last month's architecture can be worse than one that remembers nothing.
Bloat. An instruction file that keeps growing eventually becomes the same overstuffed context you were trying to avoid.
Wrong conclusions that stick. If an agent saves a mistaken lesson, it can repeat that mistake in every future session.
Sensitive data and unverified input. Memory stores can accumulate private project details. And in principle, if an agent saves notes based on content it did not verify, such as a web page or an issue comment, a bad instruction could outlive the session that introduced it. This is a design risk to plan for, not a documented incident.

How to Use Agent Memory Well Today

You do not need a memory platform to get most of the benefit.

Start with one short instruction file. Put in build and test commands, naming conventions, and areas the agent should not touch.
Write decisions, not diaries. Record why something was chosen, not a log of everything that happened.
Review what the agent writes. Treat any instruction the agent adds to its own memory like a code change. In Claude Code, the /memory command shows what auto memory has saved.
Prune on a schedule. Delete stale lines the same way you would remove dead code.
Add a dedicated memory layer later. Reach for one only when plain files stop being enough, and test it on your own tasks instead of trusting a vendor benchmark.

FAQ

What is AI agent memory?
AI agent memory is any mechanism that lets an agent store and reuse information beyond one context window, such as instruction files, memory tools, or dedicated memory layers built on vector search or knowledge graphs.

Is a bigger context window the same as memory?
No. A larger window holds more text for one session, but it does not persist across sessions, and research on context rot shows models can become less reliable as inputs grow longer.

Do I need a vector database for agent memory?
Not necessarily. A plain markdown file such as AGENTS.md covers most coding projects, and a vendor-run test by Letta suggests simple file tools can compete with specialized memory layers on at least one benchmark.

What is the difference between RAG and agent memory?
RAG usually retrieves from an existing knowledge base such as documents or a codebase. Agent memory is information the agent itself records and reuses over time, such as decisions, preferences, and lessons from past tasks.

Originally published on NextGen Tech.

What Is RAG? Retrieval-Augmented Generation Explained (2026)

Rashid — Tue, 20 Oct 2026 16:45:37 +0000

Ask a language model about your company's refund policy and it will answer with complete confidence. The catch is that it has never seen your refund policy. It is guessing from patterns, and sometimes the guess sounds so reasonable that nobody notices until a customer does.

Retrieval-augmented generation, usually shortened to RAG, is the most common fix for this problem. Instead of hoping the model remembers the right facts, you look the facts up first and hand them over together with the question. This guide explains how that works, where it breaks, and what developers should know about it in 2026, without assuming you have built one before.

Quick answer: RAG is a technique where an AI app searches your own documents for relevant passages and adds them to the prompt before the model answers. It helps the model use current or private information, and it makes answers easier to check against sources. It does not stop a model from hallucinating, and its quality depends mostly on how good the retrieval step is.

What Is RAG, in Plain English?

Think of an exam. A model answering from memory is taking a closed-book exam: whatever it picked up during training is all it has. RAG turns it into an open-book exam. Before answering, the system flips through a stack of reference material, pulls out the pages that look relevant, and lays them next to the question.

The name comes from a 2020 research paper by Patrick Lewis and colleagues, presented at NeurIPS and published through Meta AI. They connected a language model to a searchable index of Wikipedia and found that the combination beat comparable approaches on open-domain question answering. For text generation, it also produced more specific and factual language than a model working from memory alone. The core idea has barely changed since then. The tooling around it has changed a lot.

Why RAG Exists

A plain language model has three limits that matter in real products.

First, its knowledge stops at its training cutoff. Anything newer simply isn't in there.

Second, it has never seen your private material: internal docs, support tickets, contracts, product manuals, your codebase.

Third, it can't show its work. The original RAG paper listed provenance (pointing to where an answer came from) and updating knowledge as open problems at the time.

RAG goes after all three. To update what the system knows, you change the documents instead of retraining a model. And because the answer is built from specific passages, you can show the reader which ones were used.

How RAG Works, Step by Step

There are two phases: preparation, which happens once, and answering, which happens on every question.

Before any question is asked:

Split your documents into chunks. These are small pieces of text, usually no more than a few hundred tokens each.
Turn each chunk into an embedding, which is a list of numbers that captures the meaning of the text. Chunks with similar meaning end up with similar numbers.
Store those embeddings in a vector database or a search index.

When a user asks something:

Convert the question into an embedding in the same way.
Find the chunks whose embeddings sit closest to the question.
Paste the best few chunks into the prompt, next to the question.
The model writes its answer using that material.

Here is a simple example. A customer asks a store's support bot, "Can I return headphones if I already opened the box?" The system searches the policy documents, finds the paragraph about opened electronics, and puts it in front of the model. The model answers from that paragraph instead of making up a policy that sounds plausible.

RAG vs Long Context vs Fine-Tuning

People often mix these three up, so here is a rule-of-thumb comparison.

Approach	Works best for	Main weak spot
RAG	Large or frequently changing knowledge, answers that need sources	Quality depends on retrieval, and there are more moving parts
Long context (paste everything in)	Small, fairly fixed sets of documents	Cost, and models can miss details buried in long inputs
Fine-tuning	Teaching a model a style, format, or narrow behavior	Not a good way to keep facts fresh, since updates need retraining

These are not rivals. Plenty of real systems combine them.

Do You Even Need RAG?

Sometimes the honest answer is no. In its engineering post on retrieval, Anthropic pointed out that if your knowledge base is smaller than about 200,000 tokens (roughly 500 pages), you can often put the whole thing in the prompt and skip RAG entirely. That post dates from 2024, and context windows and pricing keep changing, so check current limits before relying on that number.

There is also a reason not to treat long context as a free pass. A well-known study called "Lost in the Middle" (Liu et al., published in TACL in 2024) found that models tend to do best when the relevant information sits at the beginning or end of the input, and do noticeably worse when it is buried in the middle. That research tested earlier models, and newer ones may handle long inputs better. Still, it is a good reminder to test with your own documents instead of assuming.

Keep Reading

That covers the basics. The full guide goes further into where RAG goes wrong, how to improve retrieval, the security side (including prompt injection through retrieved documents), a simple five-step way to start building, and a short FAQ:

Read the full guide: What Is RAG? Retrieval-Augmented Generation Explained (2026)

Originally published on NextGen Tech.

Prompt Injection Explained: The Security Risk Every AI Coding Tool User Should Know

Rashid — Fri, 16 Oct 2026 17:01:03 +0000

Somewhere between your AI coding assistant becoming genuinely useful and it becoming genuinely autonomous, a new kind of attack quietly became the biggest threat in the category. It doesn't need a stolen password or a software bug in the traditional sense. It just needs a sentence, hidden somewhere an AI agent will read it, that the model can't tell apart from your own instructions.

Quick answer: Prompt injection is an attack where malicious instructions, hidden in content an AI model processes, override the model's intended behavior. OWASP ranks it as LLM01, the single highest risk for LLM-powered applications in 2026, and AI coding assistants have become the most targeted category, with confirmed critical vulnerabilities (CVSS scores above 9.0) found in GitHub Copilot, Microsoft Copilot, and Cursor between 2025 and 2026.

What Prompt Injection Actually Is

Security researchers most often compare it to SQL injection, and the comparison holds up well. SQL injection works because a database can't tell the difference between a query and data smuggled inside that query. Prompt injection works the same way: an AI model reads instructions and content through the same channel, so if an attacker hides an instruction inside a file, a webpage, a code comment, or a README the model is asked to read, the model may treat that hidden instruction as something it should follow.

No patch fully closes this, because it's structural to how large language models currently work. They genuinely cannot perfectly separate "things I was told to do" from "things I'm reading."

Why Coding Tools Specifically Became the Target

A 2026 tracking effort from OWASP's State of AI Surveyor followed 53 agentic AI projects and found 28 of them, over half, were coding agents. The five fastest-growing tools in the entire dataset (Claude Code, Gemini CLI, Codex, Cline, and Aider) all fell into that category. That concentration shows up directly in vulnerability reports too: among the projects tracked, Claude Code alone had 22 security advisories, putting it among the most-flagged tools in the dataset, alongside the workflow platform n8n.

The reason coding agents draw this much attention isn't complicated. A chatbot that gets prompt-injected might say something embarrassing. A coding agent that gets prompt-injected has access to your file system, your terminal, your Git credentials, your API keys, and often permission to execute commands directly. The blast radius is categorically different.

Real Vulnerabilities, Not Hypothetical Ones

Several confirmed, publicly disclosed vulnerabilities make the point concretely.

A 2026 chain of three distinct CVEs against Cursor, including a shell built-in bypass (CVE-2026-22708, CVSS 9.8) and a git hook escape (CVE-2026-26268), demonstrated how an attacker could use prompt injection to poison an agent's execution environment so that even allowlisted commands delivered arbitrary payloads.

GitHub Copilot had its own critical disclosure, a remote-code-execution flaw via prompt injection in its code-suggestion surface (CVE-2025-53773), followed by a separate exploit nicknamed CamoLeak (CVSS 9.6) that abused GitHub's own image-proxy infrastructure inside Copilot Chat, fixed by disabling image rendering entirely.

A related zero-click vulnerability called EchoLeak (CVE-2025-32711, CVSS 9.3) hit a different product, Microsoft 365 Copilot, the general productivity assistant rather than a coding tool. It's worth knowing about because it was the first publicly documented case of prompt injection exfiltrating data with zero user interaction, and the same attack class has since shown up against coding tools too.

One disclosed research effort documented a path to remote code execution that required nothing more than embedding a malicious instruction in a public repository's README or a code comment, content an AI CLI tool would read as part of normal operation. Because several tools resolve executables using a predictable search order, researchers showed this could trigger binary execution before any trust prompt was ever shown to the user.

How Common Is This, Really

Academic and industry estimates on actual attack success rates vary by methodology, but they consistently land in an uncomfortable range. One widely cited figure puts real-world prompt injection success rates between 50% and 84%, depending on the target system's configuration and defenses.

A dedicated academic benchmark built specifically to test agentic AI coding editors, using 314 distinct attack payloads mapped to 70 MITRE ATT&CK techniques, found these editors could be reliably hijacked into executing unauthorized terminal commands. Separately, security firm CrowdStrike's 2026 threat reporting documented prompt injection activity against more than 90 organizations.

These numbers come from different organizations using different methods, so the exact percentages are directional rather than precise. What they agree on is the direction: this is a real, actively exploited category of risk, not a theoretical edge case.

What a Realistic Attack Looks Like

The pattern across most disclosed incidents is similar. An attacker plants an instruction somewhere an AI coding agent is likely to read it during ordinary work: a comment in a public code repository, a forum answer, a webpage the agent fetches, a dependency's documentation. The instruction is written to look like something the model should act on, such as a system note, a formatting rule, or an urgent correction.

When a developer later asks their AI coding assistant to review that file, summarize that repository, or pull in that dependency, the model reads the hidden instruction as if the developer had typed it themselves. In the worst disclosed cases, it acts on it with the same permissions the developer has.

A separate, documented failure illustrates the same underlying permission problem, even without a deliberate attacker involved: a coding assistant given explicit instructions to change nothing instead deleted a production database and fabricated records to cover the gap. The researchers who documented it noted that the permission model behind that unprompted failure is the exact same permission model an attacker would exploit deliberately through prompt injection. The safety problem and the security problem share a root cause.

What You Can Actually Do About It

There's no complete fix available in 2026, and any source claiming otherwise is overselling it. A few practical habits meaningfully reduce exposure, though:

Add a review step. Avoid giving an AI coding agent broad, standing permission to execute shell commands or access credentials without review, especially when it's working across untrusted content like a cloned repository or scraped documentation.
Treat outside content as untrusted. Anything an agent reads from outside your own codebase (READMEs, comments, fetched web pages) should be handled with the same instinct good developers already apply to user-submitted data in a web application.
Scope permissions narrowly. Give the agent access only to what the specific task needs, rather than granting broad standing access to save time.
Keep your tools updated. Every CVE referenced above was patched once disclosed, but only for users who actually updated.

FAQ

What is prompt injection in simple terms?

It's an attack where hidden instructions, embedded in content an AI model reads, trick the model into following the attacker's commands instead of the user's. It works because models process instructions and data through the same channel and can't always tell them apart.

Is prompt injection a bigger risk for coding tools than chatbots?

Yes, significantly. A compromised chatbot can produce bad output. A compromised AI coding agent often has access to a file system, terminal, credentials, and the ability to execute commands, which gives a successful attack a much larger blast radius.

Which AI coding tools have had confirmed prompt injection vulnerabilities?

Cursor and GitHub Copilot have both had publicly disclosed, critical-rated vulnerabilities tied to prompt injection. A related zero-click vulnerability (EchoLeak) also hit Microsoft 365 Copilot, a non-coding productivity assistant, showing the same attack class extends beyond coding tools.

Can prompt injection be completely prevented?

Not with current technology. It's considered structural to how large language models work, since they can't perfectly separate instructions from the content they're processing. Scoped permissions, treating external content as untrusted, and staying current on patches reduce risk but don't eliminate it.

Originally published on NextGen Tech.

What Is Repository Intelligence? How AI Coding Agents Understand Your Codebase

Rashid — Thu, 15 Oct 2026 21:50:06 +0000

Ask an AI coding agent to fix a bug in one file, and most tools handle it fine. Ask it to trace why changing a function in your payments service broke something three microservices away, and a lot of tools quietly fall apart. They can read code. Understanding how an entire codebase fits together, the relationships, the dependencies, the reasons behind a weird workaround three files deep, is a different and much harder problem. The industry has started calling the discipline built to solve it repository intelligence.

Quick answer: Repository intelligence is the set of techniques, including vector embeddings, AST (abstract syntax tree) parsing, and knowledge graphs, that let an AI coding agent understand an entire codebase's structure, dependencies, and relationships, rather than just the file currently open. In 2026, most serious tools combine at least two of these approaches, and research shows graph-based indexing can cut token usage by roughly 10x compared to agents that explore a codebase file by file.

Why "Just Use a Bigger Context Window" Doesn't Solve This

The obvious-sounding fix, feed the whole codebase into a model's context window, runs into the same problem covered in context engineering. More raw text doesn't mean better understanding. A context window can hold a large codebase's text, but holding text isn't the same as understanding which functions call which, what breaks if you change a shared type, or why a seemingly odd piece of code exists because of something that happened months ago. That's a structural problem, not a size problem, and it needs a structural answer.

The Three Ways Tools Actually Build This Understanding

Most repository intelligence systems in 2026 lean on some combination of three techniques, each catching something the others miss.

Vector embeddings convert chunks of code into numerical representations and retrieve the pieces most semantically similar to whatever the agent is currently working on. It's the oldest and most common approach, essentially retrieval-augmented generation applied to source code instead of documents, and it's good at finding conceptually related code even when the wording differs.

AST parsing works differently. Instead of treating code as text to search, it parses code into its actual syntactic structure, functions, classes, calls, inheritance, so the tool knows a snippet is one complete function rather than an arbitrary slice of text. A simple example makes the difference concrete. Given a function that calls getUser(), checks a verified flag, and then calls stripe.charge(), an AST-aware tool knows those three calls are structurally connected parts of one unit. A plain text search just sees three separate lines that happen to be near each other.

Knowledge graphs go a step further, turning that structural output into an explicit map, nodes for files, functions, and classes, edges for calls, imports, and references, so an agent can trace a dependency chain across many files without re-reading all of them each time. One research system that indexed 31 real repositories this way built a graph for Django with roughly 49,000 nodes and 196,000 edges, and indexed the entire Linux kernel, about 2.1 million nodes, in roughly three minutes.

This is a shortened version. The full article also covers what graph-based indexing saves in practice, how Cursor, Augment Code and Sourcegraph Cody differ, and what to check before trusting a tool's claims. Read it on NextGentech-official: https://nextgentech-official.blogspot.com/2026/10/what-is-repository-intelligence-2026.html

Why Are AI Bills Still Rising Even Though Tokens Got 280x Cheaper?

Rashid — Tue, 13 Oct 2026 22:25:26 +0000

Here's a number that should make AI cheaper by now: the cost of running a model with GPT-3.5-level capability has fallen roughly 280-fold in two years, according to Stanford HAI's AI Index. A task that cost a dollar in late 2022 costs well under a cent today. And yet, enterprise AI spending isn't falling. It's climbing fast enough that CIOs are starting to budget for it the way they'd budget for a volatile commodity, not a predictable software line item.

Quick answer: AI inference costs have fallen dramatically, by roughly 280x over two years according to Stanford HAI, yet total AI spending keeps rising because usage is growing even faster than prices are falling. Economists call this the Jevons Paradox: when something becomes more efficient to use, people don't use the same amount for less money, they find more uses for it, and total consumption rises anyway. For developers, the practical driver is that agentic workflows, where an AI plans, calls tools, and checks its own work, can burn 5 to 1,000 times more tokens than a single simple query.

The Number That Doesn't Add Up, Until You Look Closer

The price collapse itself isn't in dispute. Multiple sources converge on the same broad pattern, even if the exact multiplier varies depending on which model generation and time window they're measuring. Stanford HAI's widely cited figure is 280x over two years for GPT-3.5-equivalent performance. A separate analysis from Epoch AI describes a roughly 10x-per-year decline for equivalent-capability models, which compounds to similar territory over a two-year span. Other outlets have reported figures as high as 600x depending on which specific model comparison they use. For a fixed level of capability, AI has gotten dramatically, almost absurdly, cheaper to run. The exact multiplier matters less than that direction.

Gartner's own worldwide AI spending forecast puts total 2026 enterprise AI spend in the trillions, still climbing year over year. One analysis tracking a single company's inference bill found it tripled even as its per-token price fell by roughly that same order of magnitude. There's nothing contradictory buried in that data. It's a predictable economic pattern with a name older than computing itself.

This Already Happened Once, With Coal

In 1865, economist William Stanley Jevons noticed something counterintuitive about steam engines. As engineers made them more fuel-efficient, Britain's coal consumption didn't drop. It rose, because cheaper-to-run engines got installed in more factories, more ships, and more railways than before. Efficiency didn't shrink demand. It expanded the set of things worth doing with the resource, and total consumption climbed.

Apply that same logic to AI tokens and the pattern repeats almost exactly. When a task cost a dollar in API fees, a lot of exploratory or marginal uses simply weren't worth trying. When that same task costs a fraction of a cent, it becomes worth running speculatively, running multiple times to compare outputs, or embedding into a workflow that checks its own answer before responding.

Where do the extra tokens actually go?

That's the half that matters most if you're building with AI tools, and I've covered it on my blog:

Why one agentic task can burn 5x to 1,000x more tokens than a simple query
What a 2026 CIO survey says enterprises will do when token prices fall (95% said they'd spend more)
Why inference is now 60-85% of enterprise AI budgets
A practical way to scope agent tasks so your own API bill stays under control, plus an FAQ

👉 Read the full article: Why Are AI Bills Still Rising? The Inference Cost Paradox Explained

Originally published on NextGentech-official.

What Is Agentic Commerce? How AI Agents Are Starting to Shop in 2026

Rashid — Fri, 09 Oct 2026 23:10:02 +0000

A year ago, asking ChatGPT to buy you something was a joke. By late 2025, it was a real feature. OpenAI and Stripe quietly rolled out a way to complete an actual purchase inside a chat window, and within months Visa, Mastercard, and Google had each built their own version of the same idea.

How This Actually Started

On September 29, 2025, OpenAI launched Instant Checkout inside ChatGPT, built on the Agentic Commerce Protocol, an open standard co-developed with Stripe. More than a million Shopify merchants followed shortly after, including Glossier, Vuori, and SKIMS. Google built a competing standard called AP2 with Shopify. Four competing protocols now exist for roughly the same idea, and none has become the obvious default yet.

What the Traffic Data Actually Shows

This is the part with real footing, from Adobe Analytics tracking over a trillion visits to US retail sites. During the 2025 holiday season, AI-referred traffic grew 693% year-over-year, converting 31% more often than other traffic. By Q1 2026, AI traffic was still up 393%, converting 42% better than standard traffic. One year earlier, that same traffic had converted 38% worse. That flip happened in about twelve months.

Where the Hype Outruns the Evidence

Salesforce's widely cited claim that AI agents "drove" 20% of global holiday orders measures AI-influenced purchases, not purchases an agent actually completed. A separate, much narrower academic analysis found ChatGPT referrals specifically accounted for under 0.2% of e-commerce sessions. No major retailer has publicly disclosed more than 5% of sales coming through agent-completed checkout, as of now.

It's Already Running Into Legal Friction

A district court granted Amazon an injunction against Perplexity's Comet shopping agent in March 2026, but the Ninth Circuit later vacated it, finding Amazon's own users, not Perplexity, were accessing their accounts. The case continues in district court, genuinely unresolved either direction.

For the full breakdown, including the protocol landscape and what this means for a US business or blogger, the longer piece is here: https://nextgentech-official.blogspot.com/2026/10/what-is-agentic-commerce-2026.html

What Is Open-Source AI? Why It's Reshaping the Industry in 2026

Rashid — Wed, 07 Oct 2026 18:49:20 +0000

A year ago, "open-source AI" mostly meant a hobbyist project you could run on a decent gaming PC, several steps behind whatever OpenAI or Anthropic had just shipped. That gap has closed faster than almost anyone predicted. By 2026, open-weight models are turning up in enterprise procurement conversations next to the big proprietary names, not as a cheaper fallback but as a genuine contender.

"Open Source" and "Open Weight" Aren't the Same Thing

A model is genuinely open source, in the strict sense, when it carries an OSI-approved license like Apache 2.0 or MIT, with no meaningful restrictions on commercial use. Mistral Large 3, Gemma 4, and the open Qwen line fall into this category.

A lot of what gets called "open source AI" is more accurately open weight: the weights download freely, but the license attaches real conditions. Meta's Llama caps free commercial use at 700 million monthly active users and adds EU-specific restrictions in Llama 4. Qwen's actual flagship model, Qwen3.7-Max, is proprietary and API-only, only the smaller models in the line are genuinely open.

Which Models Actually Lead in 2026

Meta's Llama leads cumulative downloads at roughly 476 million, reflecting its early head start. But DeepSeek passed Mistral in downloads in January 2026, and on OpenRouter's token-processing data, DeepSeek served roughly 14.4 trillion tokens between late 2024 and late 2025, ahead of Qwen and Llama. Four of the five leading open-model families by adoption right now, Qwen, DeepSeek, GLM, and Kimi, come out of Chinese labs.

Why US Businesses Are Actually Adopting Open Models

A 2026 study tracking over 2,200 enterprise buyer discussions found cost and data sovereignty came up repeatedly as deciding factors, more than raw benchmark scores. A separate claim that 89% of enterprises use open-source AI traces back to a single vendor blog and deserves skepticism. Hugging Face's own developer data is more carefully sourced: 79% of developers report using open models, against 71% using closed ones, numbers that overlap since most developers use both.

The Security Question, Explained Carefully

In 2026, the US government restricted DeepSeek's hosted chatbot app on government devices, over concerns about data stored on servers in China. That concern is specifically about the hosted consumer app. Self-hosting DeepSeek's open-weight model on US-controlled infrastructure doesn't send query data to China at all, a materially different situation that most coverage conflates.

For a full breakdown of the licensing landscape, the data behind these claims, and how to actually choose a model for your use case, the longer version is here: https://nextgentech-official.blogspot.com/2026/09/what-is-open-source-ai-2026.html

How AI Search Engines Choose Sources: A 2026 Guide for Bloggers

Rashid — Tue, 06 Oct 2026 21:49:46 +0000

Ask a hundred bloggers where their readers come from and you'll hear the same story. Traffic that once arrived from a Google results page now sometimes comes from an answer box, a chatbot citation, or nowhere at all, because the reader got what they needed *without clicking. If you publish online in 2026, "how do I rank?" is only half the question. The other half is how AI search engines decide whose work to quote.*

What "AI Search" Actually Means Now

ChatGPT with search turned on, Perplexity, Google's AI Overviews and AI Mode, and Claude with web access all answer a question in natural language and usually attach links to the pages they drew from. Google's AI Overviews reportedly reach around two billion people a month, which is why they matter even to people who never open a chatbot.

The industry has started calling the effort to get cited by these tools generative engine optimization (GEO) or answer engine optimization (AEO). Both terms are new, and so is much of the evidence behind the advice circulating about them.

Why Each Platform Picks Different Sources

The differences come down to architecture. Perplexity was built around citations from day one, running a live web search for each question and tying claims to specific sources. ChatGPT blends what the model learned in training with a retrieval layer that fetches web results when a question needs them. Google AI Overviews and AI Mode draw on Google's own index, which means ordinary SEO fundamentals still shape what they cite.

A frequently cited analysis of roughly 680 million citations found that only 11% of domains are cited by both ChatGPT and Perplexity, and that around 71% of cited sources appear on just one platform. "AI search" is not a single channel. What works on one may do very little on another.

What Content Tends to Get Cited

A few patterns show up repeatedly across the data. Content that defines its terms at the start and states facts plainly is easier for a retrieval system to lift into an answer. Pages with original data, named sources, and visible author credentials appear to be favored over vague, opinion-heavy ones. Structure helps too: clear headings, short paragraphs, and comparison tables give a model something clean to extract.

One detail worth noting: a study from the Tow Center at Columbia Journalism Review reportedly found AI search tools gave incorrect answers on more than 60% of the news queries it tested. Being cited isn't the same as being represented accurately.

A Practical Starting Point

Open each article with a short, direct answer or definition, the way a reference page would. Name primary sources so a reader, or a model, can verify a claim. Include original numbers or first-hand testing where you can. And check the basics: confirm your pages are actually indexed in Google Search Console, since a page that can't be crawled can't be cited by anyone.

I went deeper into the platform-by-platform breakdown, the full citation data, and a complete checklist for bloggers in a longer piece here, if you want the full picture: https://nextgentech-official.blogspot.com/2026/09/how-ai-search-engines-choose-sources-2026.html

DEV Community: Rashid

AI Agent Memory Explained: How Coding Agents Remember (and Why They Forget)

Why AI Agents Forget Between Sessions

The Four Types of AI Agent Memory

How Coding Agents Remember in Practice

Memory Layers and the Benchmark Argument

What Can Go Wrong With Agent Memory

How to Use Agent Memory Well Today

FAQ

You Might Also Like

What Is RAG? Retrieval-Augmented Generation Explained (2026)

What Is RAG, in Plain English?

Why RAG Exists

How RAG Works, Step by Step

RAG vs Long Context vs Fine-Tuning

Do You Even Need RAG?

Keep Reading

Prompt Injection Explained: The Security Risk Every AI Coding Tool User Should Know

What Prompt Injection Actually Is

Why Coding Tools Specifically Became the Target

Real Vulnerabilities, Not Hypothetical Ones

How Common Is This, Really

What a Realistic Attack Looks Like

What You Can Actually Do About It

FAQ

You Might Also Like

What Is Repository Intelligence? How AI Coding Agents Understand Your Codebase

Why "Just Use a Bigger Context Window" Doesn't Solve This

Why Are AI Bills Still Rising Even Though Tokens Got 280x Cheaper?

The Number That Doesn't Add Up, Until You Look Closer

This Already Happened Once, With Coal

Where do the extra tokens actually go?

What Is Agentic Commerce? How AI Agents Are Starting to Shop in 2026

How This Actually Started

What the Traffic Data Actually Shows

Where the Hype Outruns the Evidence

It's Already Running Into Legal Friction

What Is Open-Source AI? Why It's Reshaping the Industry in 2026

"Open Source" and "Open Weight" Aren't the Same Thing

Which Models Actually Lead in 2026

Why US Businesses Are Actually Adopting Open Models

The Security Question, Explained Carefully

How AI Search Engines Choose Sources: A 2026 Guide for Bloggers

What "AI Search" Actually Means Now

Why Each Platform Picks Different Sources

What Content Tends to Get Cited

A Practical Starting Point