Luis Unzueta

Principally interested in old and new technology but sometimes also in other kinds of stuff.

[Rohan Paul @rohanpaul_ai]

New Google paper makes a strong case for replacing ever-growing agent histories with a small, explicit execution state.

Long-horizon agents may need far less conversation history than we give them: this paper finds that replacing the growing transcript with explicit current state cuts token use and often improves accuracy.

SKILL.state gives the model only the skill instructions, a structured state, and the latest observation. After each step, the reasoning trace is discarded and only a validated state update survives.

That keeps prompt size roughly constant as the task gets longer.

On a 100-step warehouse task with Gemini-3-Flash, SKILL.state scored 0.94 while using 65,408 tokens. The LangGraph-style baseline scored 0.91 and used 1,062,387 tokens, a 16.2X difference.

The design does have a boundary: it works only when everything needed later can be captured in the state schema.

[marfin @marfinxx]

This Microsoft paper is f*cking wonderful

Microsoft researchers just proved that Frankenstein multi-database setups are killing AI agent memory

Why current agent memory architectures fail:
→ Vector databases lack temporal order and multi-hop relational topology
→ Graph databases introduce massive cross-database serialization I/O latency
→ Traditional RAG pipelines flood LLM context windows with outdated conflicting evidence

Microsoft solved this by introducing Mandol, an in-memory agglomerative engine:

01. Hierarchical Semantic Graphs (Unified Representation)
Agglomerates raw interactions into episodic event chains, entity graphs, and preference trajectories with traceable back-links to source evidence

02. SemanticMap & SemanticGraph (Native Storage Fusion)
Fuses key-value pairs, dense/sparse vector indexes, and graph topology within a single address space, eliminating external database roundtrips

03. Quantitative Denoising & Zero-LLM Arbitration (Smart Retrieval)
Filters noise via Median Absolute Deviation and resolves temporal contradictions across sources without burning expensive LLM inference tokens

Operational telemetry across LoCoMo and LongMemEval under 10 QPS load:

92.21% SOTA accuracy peak → 5.4x search speedup (P99: 94.8ms vs 777.1ms) → 20% prompt token reduction

Hypothesis Verification & Practical Validation:
Microsoft hypothesized that unifying memory representation and replacing similarity search with quantitative in-memory arbitration eliminates cross-session context drift. Practical validation confirmed the findings: Mandol drove a +7.2% accuracy leap on complex multi-hop queries while cutting tail latency by 8.2x

Persistent agent memory is an engineering problem, not a context window problem. The leverage comes from native in-memory fusion, deterministic graph traversal, and mathematical conflict resolution

Read the complete breakdown in the article below ↓

[DAIR.AI @dair_ai]

Banger paper from Google.

If you maintain a skill library for your agents, you might want to check this out.

(bookmark it)

This work separates three things that skill-evolution systems usually collapse into one. Raw execution traces, a persistent wiki of accumulated knowledge, and the executable skills themselves.

Experience gets consolidated into the wiki, and every later skill update builds on that wiki instead of on a scattered optimization history.

Ablations confirm the wiki is what carries a lot of the gain. Two results stand out in particular. Smaller models with evolved skills beat substantially larger models without them. And skills evolved by one model transfer across families, where skills evolved elsewhere sometimes beat self-evolved ones.

Paper: https://t.co/6qftGirTpE

Chat with Paper: https://t.co/rrVzkkR1ij

[chuplung @choopyplug1]

Google's team just dropped a 9-page PDF on Harness Engineering - one formula replaced prompt engineering:

the twist: same Claude Sonnet, same benchmark - change only the harness

the formula: Agent = Model + Harness

here's the playbook in 6 steps:

step 1 ��� add guides - AGENTS.md, rule files, constraint docs - each line is a past agent failure turned into a permanent fix

step 2 → add sensors - linters, tests, validation scripts the agent runs on its own output before a human sees it

step 3 → build the agentic loop - plan, execute, verify, fix - bounded retries, budget caps, escalation when stuck

step 4 → externalize memory - the model forgets every session. the harness remembers state, decisions, and artifacts across all of them

step 5 → enforce permissions - which tools, how many writes, what needs approval. the model doesn't enforce safety. the harness does

step 6 → wire observability - track every tool call, cost, retry. trip wires fire when behavior drifts

the result: your agent stops being a demo and starts being infrastructure - every failure makes the system permanently better, not just the next conversation

this 9-page PDF is what comes after prompt engineering and context engineering

bookmark and build the full system from the article below ↓

[Wildminder @wildmindai]

HOT! MiniMax-H3 Fun Controlnet Union dropped by Alibaba!

all-in-one control for MiniMaxH3
- Canny, Depth, HED, MLSD, Pose
- inpainting
- single 7GB checkpoint
- guidance-distilled for fast 1-pass inference

https://t.co/1n2KnUzIMF

[Avi Chawla @_avichawla]

A harnessed LLM agent, clearly explained!

Two agents can run the same model on the same task and finish as expected. But one of them can spend nearly 3x the tokens to complete the task.

The extra usage originates from the code wrapped around them, which decides what reaches the model's context on each call and how many calls there are.

For instance, consider a tool that returned 50k tokens of JSON at some step. If it stays in the context, the model will continue to read that payload again at every subsequent step.

Tool definitions behave the same way.

A server can expose 50 tools, each with a name, a description, and an input and output schema.

By default, all of them will stay in the prompt from the first call, whether the agent uses them or not.

However, an optimally built harness can avoid that unnecessary cognitive load on the model.

More specifically, one core design principle of harness engineering is to push things out of the model at the right time:

- Memory holds the state that weights and context shouldn't carry.
- Skills hold procedural knowledge. These cover the operating procedures and heuristics that specialize a general model.
- Protocols hold the interaction contracts for users, other agents, and tools.

Do note that the context never disappears permanently.

It is always loaded when needed, and the harness decides how much is loaded and when.

For instance, to manage a 50k token payload, a harness can write it to a file and keep a preview and a path in context, hand the work to a subagent whose context is discarded afterwards, or summarize the older messages once the conversation passes a threshold.

If you want to see this in practice, TrueForge is an open-source harness that already implements these practices.

Tool schemas are deferred unless preloading is switched on, large responses go to a sandbox file, and generated code calls tools back through the harness, so the sandbox never holds the credentials.

The two agents I talked about at the top are from DevRev's Enterprise-Bench. TrueForge solved the same number of tasks as Claude Managed Agents on the same model, using a bit over a third of the tokens and around 40% fewer tool calls.

Here's the GitHub repo: https://t.co/ZjePhhfKIh

(don't forget to star it ⭐ )

I also wrote a full breakdown of where agent tokens actually go inside a run, covering context accounting, the strategies above, and the benchmark in detail, and TrueForge worked with me to put this together.

Read it below.

[Alex Xu @alexxubyte]

What Is Harness Engineering, Explained Visually.

[Hostile VR @BadHostile]

The mod is publicly available, but its installation requires some steps. The author doesn't share the APK file to avoid conflict with Rockstar/Take-Two, so users must create the file themselves using the included instructions and a purchased version of the Android game from Google Play. A simple installer will then help decompile the files and upload them to the Quest. More information on the installation process can be found here:
https://t.co/FfRyPOCALf

[GingasVR @gingasvr]

“Ai assisted vr modding is Garbage slop”

- Luke Ross makes a non Ai cyberpunk mod for $ which is debatably a “slop” mod where it’s just vr camera and you need to use a gamepad

- The Ai assisted cyberpunk mod has full motion controls, a body IK, an API, manual aiming, manual driving, manual driving etc. it’s less “slop” than the non Ai one.

Love to see all the mental gymnastics around this one lol #vr #gaming

[Md Ismail Šojal 🕷️ @0x0SojalSec]

Your 8GB laptop can now serve a 35B frontier MoE at 39 tokens per second.

Your 5090 can run a 284B model interactively.
UC Berkeley just made frontier MoE models actually usable on normal hardware.

- Qwen3.6 35B flies at 39 tok/s on an 8GB RTX 4060 laptop
- DeepSeek-V4-Flash 284B hits 22-25 tok/s on a single 5090
- GLM-5.2 753B runs at 15 tok/s on one RTX PRO 6000
And it’s significantly faster than Ollama.

FreeToken lets you run frontier model locally at interactive speeds on hardware you already own.
No extreme quant, No datacenter required.

- https://t.co/JA8xTgkSxL

[karan @karancl]

the single greatest project you should do if you are trying to become better at ai systems is to take an open weights model and build the entire production system around it. do this by yourself and watching tutorials only when needed.
1. take a pretrained model and understand its inference path. this will help you learn what computational work happens for every token that is generated.
2. build an inference server. put your model behind something like vllm/sglang. then expose it through and api, handle multiple users
3. understand why inference is fast or slow. learn about batching, kv cache, quantization, gpu memory, scheduling, and the tradeoff between speed, cost, and quality.
4. build the backend around the model. add users, login, chat history, databases, caching, request limits, error handling, and basic security.
5. build a simple chat product around it. create a frontend where users can start conversations, send messages, receive streamed responses, and manage their chat history.
6. give the model access to outside knowledge. build a simple rag system that can load documents, retrieve relevant information, and give that information to the model before it answers.
7. give the model the ability to take actions. add tool calling so it can use apis, search, databases, or other functions. then build a simple agent loop around these tools.
8. build evaluation and monitoring. measure answer quality, retrieval quality, latency, errors, token usage, gpu usage, and cost. make sure you can tell when a change makes the system better or worse.
9. make the system reliable and safe. learn about authentication, rate limits, retries, timeouts, failures, data isolation, prompt injection, and safe tool use.
10. deploy the whole system. run it on a cloud gpu, containerize it, and learn how the different parts communicate with each other in production.
11. test it under real load. send many requests at the same time, find the bottlenecks, and learn how to improve throughput, latency, gpu usage, and cost.
12. scale it. move from one model server to multiple servers and eventually learn multi-gpu and distributed inference.
13. automate the whole lifecycle. add testing, model versions, evaluation before deployment, automatic deployment, monitoring, and rollback.
14. keep improving the system. whenever you find a bottleneck, don't immediately watch a tutorial. first understand the problem, form a hypothesis, test it, and only then look for outside help if you are stuck.

this isn't meant to be built in two weeks and will take you months to build depending on your understanding of software engineering. but this has by far been my steepest learning curve in a project coming from a core ml background.

[Andrew Ng @AndrewYNg]

The most important skills in Building and Deploying AI Applications. https://t.co/IyWIKLIzeM

[Akshay 🚀 @akshay_pachaar]

RAG vs. CAG, clearly explained!

RAG is great, but it has a major problem:

every query hits the vector DB. even for static information that hasn't changed in months.

this is expensive, slow, and unnecessary.

Cache-Augmented Generation (CAG) fixes this by letting the model keep static information in its key-value (KV) memory, which is what the model builds internally for every token it reads.

in fact, you can combine RAG and CAG for the best of both worlds.

here's how it works:

RAG + CAG splits your knowledge into two layers.

↳ static data (policies, documentation) gets cached once in the model's KV memory

↳ dynamic data (recent updates, live documents) gets fetched via retrieval

you get faster inference, lower costs, and less repeated work.

the trick is being selective about what you cache.

only cache static, high-value knowledge that rarely changes. cache everything and you'll hit context limits. separating "cold" (cacheable) and "hot" (retrievable) data keeps this system reliable.

you can start today. OpenAI and Anthropic already support prompt caching in their APIs.

one thing to know before you scale it.

prompt caching matches on an exact prefix, byte for byte. your cached layer only gets reused when it sits at the very front of the context in the same order every time.

↳ reorder two cached policy documents and both turn into a miss

↳ cache document A alone and document B alone, then query both, and the second one misses because the model computed its cached state without ever seeing the first

in production this looks like a small fraction of your cached blocks serving almost all the hits. the rest just sits there.

the way out comes from how attention behaves. tokens attend mostly to their own local neighborhood, and only a few reach across document boundaries. CacheBlend recomputes those few and reuses everything else from the separately cached documents.

multi-document queries run two to four times faster, quality holds, and order stops mattering.

it ships in LMCache, which is fully open source.

repo: https://t.co/TXlaLLu04a

(don't forget to star 🌟)

below, i have quoted my article on KV cache management. it covers where prefix caching stops working and how a proper caching layer fixes it.

give it a read.

cheers! :)

[Bozoid @bozoid]

there's a far more impressive GTA 3 Vice City Quest standalone VR build now, with traffic, NPCs and all - plus modern models

very bad time for the small apelab clones on apelab store, huh?

https://t.co/tWp8FuZzMj

[Alex Cui @alexcdot]

Claude's watermark probably doesn't work how you think. As the CTO of GPTZero, I'll explain how Anthropic, Google and OpenAI are building text watermarking in this brief explainer and whether it can be defeated.

Almost all forms of watermarking that are fast and cheap enough for a frontier lab have the same formula, following the KGW method:

In generation:

1. Let's say you've generated n tokens so far. Take those n tokens + a secret key to generate a random hash
2. Use that hash to randomly reweight the probabilities for the n+1 token, and then sample from that new distribution. In the simple case, you could split 50% of all English words into a green or red set based on your hash, and boost the probability of words in the green set.

For watermark detection:

1. For each token, see if it was in the green or red set.
2. To do this, recreate the hash based on the secret key and the text preceding the current token. Then, recreate the green and red set of words.
3. Once you've checked all the words in the text, if the next token is selected disproportionally from the green set more than 50% of the time, you claim the text has the watermark.

I can tell you want to ask the following:

1) Isn't it easy to mess up the hash if you paraphrase the text? The answer is mostly yes, however, you can use a statistical model to get your hash instead of a deterministic function (SIR, Adaptive Watermark). Since the entire watermark is probabilistic, this is fine.

2) Doesn't this make the text much worse? The answer is yes, it does - Yes, it does – but for most people, it's imperceptible (Google claims in human feedback study with 20,000 texts), since there are exponentially many ways to write the same paragraph. DiPmark does something more sophisticated to avoid shifting the text distribution on average. Of course, watermarks fail on short text or highly predictable texts like "2+2=4".

3) Shouldn't it be easy to figure out the green and red sets? The answer is no. You would need an exponentially large number of samples from the watermarker to reconstruct those sets exactly, but it's a risk if the detector is open to the wild (Watermark Stealing)

Still, there are couple challenges that a frontier lab needs to overcome:
1. Their watermark needs to work token-by-token because they are streaming their text to users. Many watermark methods plan sentences or paragraphs at a time, or change the text after its entirely written, in order to make their watermark robust to paraphrasers, and a frontier lab cannot afford to do this yet (SemStamp, PostMark)
2. If the secret key leaks, the watermark is busted. To avoid a large blast damage from this, you need to have a couple secret keys in rotation.
3. There are some texts, like code, that cannot be arbitrarily changed, otherwise the code will break. In those cases, the watermark needs to selectively change words in parts of the text that can tolerate synonyms (i.e. like variable naming) - see SWEET, EWD, Invisible Entropy.
4. They will need to educate their users on how to deal with false positives and false negatives of a detector, which is a big challenge (one we put a lot of effort into)

So, how do I see this playing out in the next 6 months?
1. If Anthropic releases the watermark detector publically, I think they defeat their own watermark. People find reliable watermark removal strategies by testing against Anthropic (AI detectors like GPTZero have an advantage here because they can train against these adversaries once they become popular).
2. If they keep the detector private to the government, like Google has done, it's "safer". However, there are some papers showing trained approaches that work robustly to zero-shot break watermarks without any data, simply because they try to write the text just like a human (Zhang et al. 2024, Watermarks in the Sand). Also, making your detector makes it battle-tested and stronger long-term (my experience).
3. In my testing, the watermarks don't survive intense paraphrasing (especially if you combine word choice and syntax attacks), or human text substitution (rewrite your AI text by plagiarizing human authors). The free paraphrasers I've tried have quickly bypassed Google Deepmind's SynthId for what it's worth.
4. All-in-all, frontier labs are likely okay with this because they expect most users to not attack the watermark, and also because they + European regulators likely don't care past a certain point - its good enough.
5. Overall, I think users of frontier LLMs will not really care about this, because 1) they don't realize watermarks are there, 2) EU will force everyone to conform, 3) this seems more like regulatory hoop-jumping than an earnest effort from frontier labs to expose LLM use

Lastly, people's first concern shouldn't be watermarking, it should be AI detectors!

If you're posting, "its not X, its Y!!", I don't think the watermark is going to make a difference :)

[Matt Dancho (Business Science) @mdancho84]

This is what a company looks like in 2026.

Not people. Not offices. Not salaries.

A folder:

.claude/agents/
engineering/
marketing/
design/
ops/
testing/

Every role. Every department. Every function.

All .md files.

[Wccftech @wccftech]

BetterVR mod transforms Nintendo's Breath of the Wild into full VR after 1,000s of hours reverse-engineering Zelda's engine. https://t.co/dzJrmHXceB

[vartekx @vartekxx]

Google Engineer:

"writing code is forbidden on my teams. the only permitted activity is getting the agent to do your job"

he hasn't written any code since June 2025. neither has anyone on his teams. the agent writes all the code

"code is free to produce now. implementation is abundant. what's scarce is human time, context window, and attention"

bookmark this, then read the article below ↓

[LunchAndVR @LunchAndVR]

Breath of the Wild in VR is so good, it's how a VR mod should be done! I had fun playing & recording this

[NO1ennn @N01ennn]

YOU'RE USING AI MEMORY WRONG. AND I FOUND YOU F*CKING GOLD

a Chinese team at Rutgers (A-MEM) stopped treating memory like a database with fixed slots. they made it a web of notes that link and evolve, like a human mind

every new experience becomes an atomic note: content, keywords, tags, embedding. the LLM finds its neighbors, links them, and rewrites the old notes too

at recall it pulls a whole "box" of connected memories, not one lonely chunk

the result:
> multi-hop F1 27 vs ~9-12 for MemGPT and ReadAgent
> ~1,200 tokens per op vs ~16,900, up to 93% fewer
> scales linearly, still fast at 1M memories

stop dumping chunks into a vector DB. this memory reorganizes itself as it learns

bookmark this