标签：#AI

May 29 I wrote my first AI trainwreck story. June 18 I finished #15. People keep asking if this was...

📖 Originally published on my blog . Part of a series on building with Claude Code. For a while I'd watch the AI work and quietly grumble: a fairly big task, and it would finish one module before starting the next, while I just sat there waiting for it to clear one before the other's turn came up. The work itself was fine—it was just slow. Slow because it was stuck in a queue. Then it clicked: a lot of these modules have nothing to do with each other, so why make them go one after another? Split them up, let several agents work at the same time, done. What I want, and where it stops What I want is simple: the same work, for roughly the same tokens, with the wall-clock time cut way down. But let me put the boundary up front— not every task can be split this way . This is just an approach I've worked out for myself; take what's useful. The prerequisite: a clean architecture For several agents to work at once without stepping on each other, the prerequisite isn't the AI—it's your architecture . That task of mine could be split because it was already several modules, talking to each other through interfaces, with internal implementations that don't affect one another—as long as each one honors the interface contract, it can be built independently. Loosely coupled, highly cohesive, in other words. And I'd nailed that design down together with opus before writing a line: opus helps me think it through and lays out options, but I'm the one who decides . You can't cut corners here. Forcing parallelism onto an architecture you haven't cleanly split is like cutting a tangle of yarn into a few pieces that are all still knotted together—it only gets messier. Who runs the show, who plans, who does the work With the design settled, it's time to assign roles. The split I tend to use: opus runs the show —holds the big picture, hands out work, does the final check; sonnet does the TDD planning —per the design, it lays out how each module gets tested and implemented; haiku writes the

Wiring an LLM as a first-class Yjs peer is architecturally sound — but it invalidates three silent assumptions your collaboration stack already makes about peer symmetry: throughput, undo ownership, and presence cadence. You've tuned a Yjs provider under real collaborative load. You know the feeling before you can name it — one heavy client starts lagging the room, presence updates stutter, and you end up adding a debounce somewhere and calling it done. Now imagine that client generates text at 3,000 words per minute, never goes offline, and has its own awareness cursor. That's not a sidebar feature. That's a new class of peer, and your collaboration architecture wasn't designed for it. The Demo Is Real — But It Skips the Hard Parts In April 2026, a working demo wired an LLM as a genuine server-side Yjs document peer — same transport as the human editors, same CRDT, its own awareness state. The implementation uses y-prosemirror and the standard awareness protocol directly. If you've shipped TipTap collaboration, you already have every dependency it needs. The architecture is correct. Making the agent a server-side peer — rather than a client-side bolt-on posting diffs over a REST endpoint — gives you one convergence model instead of two, real presence semantics for the agent, and a clean separation between the LLM streaming layer and the document state layer. But the demo establishes the peer model. It doesn't stress-test what happens to your existing assumptions once that peer is running. The Silent Assumption Every CRDT Implementation Makes Here it is — the assumption baked into the Yjs awareness protocol, the undo manager, and your backpressure strategy, the one nobody wrote down because it was always true until now: All peers produce operations at roughly human speed. Not identical speed. Human typists vary. But they land in the same order of magnitude. The entire design space — how often you broadcast awareness, how you scope undo history, whether you need per-

AI Coding Agents Need a Control Layer AI coding agents are getting good enough that the problem is changing. A year ago, the question was mostly: Can this thing write useful code? Now, for a lot of builders, the better question is: How do I supervise this thing once it is actually doing work? That shift feels important. Claude Code, Cursor, Codex, and similar tools are not just autocomplete anymore. They can plan, edit files, run commands, review code, and work across larger chunks of a project. That is powerful. It also gets messy fast. The bottleneck is moving The hard part is no longer just picking the best coding agent. It is figuring out how to manage agent work once multiple tools or sessions are active. Questions start showing up: What is each agent doing right now? What changed? What still needs human review? Where did approval happen? Which agent owns which task? Did two agents touch the same part of the codebase? What should be paused, redirected, or stopped? What happened while I was focused somewhere else? That is not really a prompting problem. It is a control problem. The current workflow is mostly duct tape A lot of agent workflows seem to rely on some combination of: terminal tabs tmux sessions git branches git worktrees editor diffs notes issue trackers rules files memory vibes That works for a while. But once agents become more autonomous, or once a builder runs more than one agent at a time, the workflow starts to need a real operating layer around it. Not because the agents are bad. Because the agents are getting useful enough to need supervision. The missing layer The layer I keep thinking about has a few jobs. State What is running? What is paused? What needs attention? Ownership Which agent owns which task, branch, file, or objective? Review What changed, and what still needs a human to look at it? Approval Where should the human say yes before work continues? Intervention When should a builder pause, redirect, compare, or stop an agent? Memor

The obvious counterargument to everything I'm building is this: Google already does it. You type "best AI tools for video editing" into Google and an AI Overview surfaces a curated list, synthesized from the same kind of data I maintain, without requiring a click. My three directory sites — Top AI Tools , Find Games Like , and Open Alternative To — are competing with a feature baked into the world's dominant search engine. I launched these sites on 2026-04-23, built on an architecture that runs at about $25/month . Traffic is essentially zero — the sites have been indexed for three weeks and organic crawling takes time. The question I keep returning to isn't whether Google will eventually index my pages. It's whether anyone will prefer clicking through to my site over reading the AI Overview box that already answered the same question. Here's my honest, falsifiable position. The bet, stated plainly By October 2026 — six months post-launch — at least one of the three sites will show organic click trends in Google Search Console indicating real query traffic to specific comparison or filtered-browse pages. I define that as: at least 200 non-homepage organic clicks per month, sustained for two consecutive months, from queries I didn't directly drive through social or newsletter posts. If that doesn't happen, I'll publish the Search Console screenshots and write a post explaining what I got wrong. I'm committing to that here. The counterargument I take seriously AI Overviews have gotten genuinely good at list-and-compare synthesis. If you search "open source alternative to Notion" today, Google often returns a four-item structured list with one-sentence descriptions directly in the Overview box. My Open Alternative To site covers that territory. The AI Overview absorbs the zero-click version of that query. The optimistic response is: "my site appears as a citation source." The pessimistic response is: "Google consumes your signal and stops sending clicks." The pessimist

In the world of Generative AI, there is a massive difference between asking for a "pancake recipe" and asking for "eligibility criteria for phase III immunotherapy trials." In specialized fields like healthcare, a standard vector search often fails because medical terminology is dense, specific, and unforgiving. 🏥 Today, we are building a High-Precision Medical RAG (Retrieval-Augmented Generation) engine. We will move beyond simple semantic search by implementing Hybrid Search (Dense + Sparse vectors) using the powerhouse BGE-M3 model, storing it in Qdrant , and fine-tuning the results with FlashRank . This approach ensures that technical medical terms (like EGFR L858R mutation ) aren't lost in the "vibe" of a vector space. Keywords: Hybrid Search , Medical RAG , BGE-M3 Embeddings , Qdrant Vector Database , Clinical Trial Retrieval . The Architecture: Why Hybrid Search? Traditional RAG relies on "Dense Vectors" (semantic meaning). However, in clinical trials, keywords matter. A patient searching for "Pembrolizumab" needs that exact drug, not just "something related to cancer." By using BGE-M3 , we get the best of both worlds: Dense Retrieval : Captures the context and intent. Sparse Retrieval (Lexical) : Captures specific keywords and medical codes. Reranking : Re-evaluates the top hits to ensure the most clinically relevant document is on top. graph TD A[User Query: Medical Case] --> B{BGE-M3 Encoder} B -->|Dense Vector| C[Qdrant Collection] B -->|Sparse Vector| C C --> D[Hybrid Search Results] D --> E[FlashRank Reranker] E --> F[Top K Relevant Documents] F --> G[LLM: Final Synthesis] G --> H[Actionable Clinical Insight] Prerequisites 🛠️ Before we dive in, make sure you have your environment ready: Qdrant : Our high-performance vector database. BGE-M3 : A state-of-the-art embedding model that supports dense, sparse, and multi-vector retrieval. FlashRank : An ultra-fast, lightweight reranking library. LangChain : To orchestrate our RAG pipeline. pip install qdrant-c

A few weeks ago, I started exploring the Afriex MCP server. The setup was surprisingly straightforward. Connect your MCP client. Configure your API key. Verify the connection. Done. But then I ran into a different problem. Not a technical problem. A prompt problem. The Blank Prompt Problem Once everything was connected, I found myself staring at an empty prompt box. What should I ask? Sure, I could retrieve balances. I could create customers. I could generate virtual accounts. But what were the most useful workflows? What were the prompts that would actually help developers build real products? This isn't a problem unique to Afriex. It's becoming a common challenge across the entire MCP ecosystem. The infrastructure exists. The tools work. But many developers don't know where to start. MCP Changes How We Build Traditionally, integrating a payment API looked something like this: Read documentation Find the endpoint Write HTTP requests Parse responses Build business logic With MCP, the workflow looks very different. You can simply tell your AI assistant what you want to build. For example: Create a customer onboarding flow that: - Collects customer details - Generates a virtual account - Displays payment instructions Build it using Next.js and TypeScript. Instead of manually stitching everything together, the AI can interact with infrastructure through the MCP server. That's incredibly powerful. But only if you know what to ask. The Idea That's what led me to build the: Afriex MCP Prompt Cookbook A collection of practical, production-oriented prompts designed specifically for developers building with Afriex MCP. The goal is simple: Copy. Paste. Build. Instead of starting from scratch every time. The cookbook is open source and available on GitHub: https://github.com/SonOfUri/afriex-mcp-cookbook Feel free to explore the prompts, use them in your own projects, and contribute new recipes. What's Inside The cookbook is organized around real-world use cases. Not API endpoi

Most engineering reading lists are optimized for knowledge accumulation. Modern engineering rewards bottleneck elimination. Last week, a junior engineer showed me a "Top 10 Books Every Engineer Should Read" list. It looked almost identical to the lists I saw ten years ago. The same classics. The same process books. The same assumption: Read enough books and you'll become a better engineer. That's not how most high-performing teams learn. The best engineers I know don't build learning plans around books. They build learning plans around constraints. The Problem with standard reading lists Most reading lists assume that knowledge is universally valuable. In practice, engineering value is highly contextual. A backend engineer struggling with database contention does not need another chapter on Agile. A team spending thousands of dollars per month on LLM inference does not need a generic software craftsmanship book. A startup fighting latency issues does not need a leadership framework. They need solutions to the bottleneck directly in front of them. Reading lists rarely account for this. They optimize for completeness. Engineering rewards relevance. The Shift Most Engineers Miss The fundamentals still matter. Distributed systems matter. Databases matter. Networking matters. Operating systems matter. They are not obsolete. But they are no longer sufficient. Modern systems introduce constraints that barely existed a few years ago: AI inference costs Context window limitations Agent orchestration Evaluation pipelines Semantic caching Non-deterministic workflows Model routing Human-in-the-loop systems Many traditional reading lists never touch these problems. Yet these are exactly the problems teams are solving every day. The challenge is no longer simply writing correct software. The challenge is building reliable systems on top of components that are inherently probabilistic. What Changed For decades, engineers mostly worked with deterministic systems. Given the same inp

AI Agent 的记忆系统通常只解决一个问题：「记住」。gbrain 存知识图谱，Hindsight 存向量，Memory tool 存偏好。三个仓库堆满数据，但你问 Agent「我上周看的那篇关于 Agent memory 的文章说了什么？」——它答不上来。不是因为记不住，是因为它的记忆系统没有「采集」这一层。 这就是 Knowledge-and-Memory-Management（KMM）的定位：不是另一个记忆数据库，而是一个 知识采集 → 精炼 → 召回 → 同步 的全链路插件。v0.0.2 把这条链路做完了。 架构思路：把「采集」和「记忆」解耦 KMM 不做记忆存储，它只做三件事： 采集 — 从 40+ 工具把原始知识拉进来 精炼 — 把原始材料变成结构化笔记 + 知识图谱节点 同步 — 写 OneDrive，让所有设备共享同一个知识池 下方是三层采集管线示意： 层 工具数 代表工具 网页 9 Scrapling (CF 绕过)、Chrome DevTools Protocol、GStack Browser 视频 12 抖音批量转录、yt-dlp、Whisper ASR (99 语种) 文档 9 SenseNova PDF/PPT/Word 引擎、MinerU、book_cache (710+ 本) 3 层召回：不让任何一条知识掉队 搜索时先查本地 FTS5（毫秒级），没命中就走 Hindsight 向量（语义近似），再不中就落 gbrain 知识图谱（关联推理）。三层兜底，基本不存在「查不到」的情况。 代码片段：rclone 做云盘双向同步 KMM 的 CloudSyncEngine 不造轮子，直接用 rclone 做统一同步层。核心代码很直白： class CloudSyncEngine : def __init__ ( self ): self . _check_rclone () def _check_rclone ( self ): result = subprocess . run ([ " rclone " , " version " ], capture_output = True , text = True ) if result . returncode != 0 : raise RuntimeError ( " rclone not installed " ) def bidirectional_sync ( self , local_path , remote_path ): """ 双向增量同步，每 4h 自动执行 """ cmd = [ " rclone " , " bisync " , local_path , remote_path , " --resync " ] return subprocess . run ( cmd ) 这没什么黑科技，关键是架构决策：用 rclone 支持 12+ 云盘（OneDrive / 阿里云盘 / 百度云盘 / Dropbox / Mega / 天翼云等），不需要为每个云盘写专属 SDK。一份配置，双向同步，cron 每 4 小时自动执行。 一个完整的采集流 用户丢过来一个抖音视频链接 → collect_video() 自动走三条线并行： yt-dlp 下音频 → Whisper ASR 转文字 → PaddleOCR/EasyOCR 提关键帧文字 。输出汇总后 → generate_note() 写结构化笔记 → create_note() 入 gbrain 知识图谱 → sync_to_cloud() 推 OneDrive。全自动，零人工参与。 踩过的坑 不要用 Python 重写云盘同步 。KMM v0.0.1 试过直接调各云盘 REST API，token 刷新、分片上传、断点续传全要自己处理，维护成本极高。v0.0.2 切到 rclone bisync 后问题归零。 视频分析不只看语音 。抖音很多技术号用字幕 + PPT 画面讲内容，语音只占信息量的 60%。必须 OCR 做画面补充，否则丢失大量知识。 去重不做在采集层 。采集层只管拉，去重交给 gbrain 的 content_hash 和 nightly_maintenance 的 orphan compaction，职责分离更干净。 适用场景 如果你的 AI Agent 已经跑了一段时间，积累了几千条笔记 / 几百个知识图谱节点，但你还是觉得「它好像什么都不懂」——问题很可能出在知识摄入链路上。KMM 适合你已经有一套记忆系统，缺的是一个自动化的知识采集和同步层。 仓库： github.com/mage0535/Knowledge-and-Management ，MIT 协议，PR

GitHub added a tiny field to the Copilot usage metrics API this week that is going to create a lot of very confident spreadsheets. Enterprise and organization admins can now see ai_credits_used in the user-level Copilot usage reports. One field. Per user. Available for single-day and 28-day reports. It is not the invoice, and GitHub is careful to say it is a consumption signal rather than a billed total. Still, the shape is obvious. Now AI usage can sit next to adoption, activity, team, department, cost center, and whatever else the company already exports into a dashboard. That is useful. It is also exactly how a tool metric becomes a management metric. And once that happens, the question is no longer "can we measure AI usage?" The question is "what weird behavior will this metric create?" every useful metric becomes a temptation I understand why this field exists. If a company is paying for Copilot, especially with usage-based pieces attached to more expensive models and premium features, it needs some way to understand consumption. Platform teams need budget signals. Engineering leaders need adoption signals. Procurement needs something more concrete than "people seem to like it." Finance will eventually ask why one org burns through credits much faster than another. That is normal. The problem starts when a consumption signal is treated as a productivity signal. High AI credit usage might mean a developer is doing valuable work with agent mode, code review, test generation, refactoring, or research. It might also mean the developer is stuck, repeatedly asking the model to solve the wrong problem, generating code that gets deleted, or using a heavyweight model where a small one would have been fine. Low AI credit usage might mean a developer does not need much help. It might mean the work is mostly design, review, debugging, incident response, mentoring, or architecture. It might mean the codebase is small and well understood. It might mean the developer is skept

This is a submission for the June Solstice Game Jam What I Built Turing's Mirror is a...

Every time you open a new session with an AI coding tool, it starts from zero. It does not know what you decided yesterday, what failed last week, or what comes next. You have to explain the project again. And again. EGC (Extended Global Context) fixes this. EGC is a local runtime that gives every AI coding tool you use a persistent memory. At the end of each session, the AI saves what it learned: decisions made, what failed, your preferences, what comes next. At the start of the next session, it loads that state back automatically. One install. Every tool. Every session. Website: https://fmarzochi.github.io/EGCSite What it looks like in practice You open Claude Code on a project you have not touched in two weeks. Without typing anything: State loaded from egc-memory via ~/.egc/state/Projects--MyApp.md Context and preferences acknowledged. Ready to pick up: - Test full install on a clean machine - Add GEMINI.md with session memory protocol - Publish v1.0.1 fix after clean install test passes The AI already knows what you were building, what decisions you made, what failed, and exactly where you stopped. You did not type anything. You just started working. How it works EGC ships two MCP servers that run locally during every session. egc-memory: 14 tools for persistent memory Tool What it does get_state Loads project memory at session start update_state Saves decisions, preferences, and next steps store_decision Persists a single decision to SQLite query_history Returns past decisions by timestamp search_history Full-text search with BM25 ranking working_memory_set Stores transient context with a TTL lesson_save Records cross-session knowledge with confidence decay lesson_recall Retrieves active lessons above a threshold detect_patterns Surfaces repeated commands and recurring errors compress_observations Compresses hook events to save token budget State files live at ~/.egc/state/<project-slug>.md . One file per project. Plain Markdown. Human-readable. egc-guardian:

There is a class of feature that used to be impossible to ship for free: anything that needed a language model. You wired up an API key, you ate the per-token bill, and every prompt your users typed went off to someone else's server. For a small public tool, that math usually killed the idea before it started. That changed. Recent versions of Chrome ship a language model, Gemini Nano, and expose it to any web page through the Prompt API . The model runs on the user's own machine. No API key. No inference bill. No data leaving the browser. We put this into a real, live tool, a free Mermaid diagram editor where you describe a diagram in plain English and the browser writes the Mermaid code for you. This post is the developer's version of that story: how the API actually works, the code that makes a small on-device model trustworthy, and an honest accounting of what you gain and what you give up. What "AI in the browser" means in 2026 The important word is built-in . This is not WebGPU plus a 4 GB model you download and run yourself. The model ships with Chrome, and you talk to it through a small standard-track JavaScript API. As of Chrome 148, the Prompt API is stable for web pages (it had been available to extensions since Chrome 138). It is the general-purpose member of a growing family of built-in APIs: Prompt API ( LanguageModel ): general natural-language prompting, now multimodal (text, plus image and audio input). Summarizer, Writer, Rewriter, Proofreader : task-specific, text-to-text. Translator and Language Detector : backed by expert models, desktop only. The Prompt API is the one you reach for when you need something the task APIs don't cover, like "turn this description into Mermaid source." So that is the one this post focuses on. The 15-line version Here is the whole happy path. Check availability, create a session, prompt it. // Feature-detect first. Old browsers won't have this at all. if ( ' LanguageModel ' in self ) { const status = await LanguageMod

I run a homelab with four RTX 3090s — 96 GB of VRAM, 44 CPU cores. For two weeks I tried to make it my daily driver for local LLM inference instead of paying for cloud APIs. I got it working. Then I looked at the numbers and subscribed to a paid API anyway. Here's the uncomfortable part, and the optimizations that still made it worth doing. ## The setup 4× RTX 3090 (Ampere — no native BF16), 96 GB VRAM total, 44 cores Models: Qwen3.6-35B-A3B (Q8_0, MoE) and Qwen3-Coder-Next (Q6_K, hybrid) llama.cpp in router mode + OpenWebUI Ceiling I hit: ~105 tokens/second ## The 6% problem The wall wasn't compute. GPU utilization sat at 6%. The bottleneck was CPU orchestration — llama.cpp dispatches across multiple GPUs sequentially, so the cards spent 94% of the time idle waiting on each other. Throwing more VRAM at it does nothing for this. ## What actually moved the needle | Change | Effect | |---|---| | --ubatch-size 512 | +40% throughput | | KV cache quantization (Q4_0) | 4× VRAM savings | | Speculative decoding (n-gram) | 2.5× speedup on repetitive tasks | | YaRN rope scaling | context extended to 1M tokens | Two things surprised me: MoE models tolerate aggressive quantization far better than dense ones — inactive experts don't eat bandwidth, so the quant hit lands softer. The 3B active -parameter model was great at local decisions but fell apart on coherence past ~300–400 lines of code — fine for a function, not for cross-file consistency. ## The conclusion I didn't want At ~11 kWh/day, plus hardware depreciation, against current API pricing, the math doesn't favor local for interactive work. The single biggest improvement to my daily AI workflow was paying for an API. Local still wins for privacy, high-volume batch jobs, or uncensored experimentation — but not as a general cloud replacement. It's an economics problem, not a capability one. I wrote up the full cost breakdown and the exact llama.cpp router configs on aipster.com . If you're weighing a local rig, I also benc

For 13 years I have worked in production at a steel-tube manufacturer. Not in an office — on the floor, with the machines, the night shifts, the handovers at 6 a.m. A few years ago I started building software in my free time. Not tutorials for their own sake — tools that solve problems I actually see every day. Why a factory worker writes code In production you learn one thing fast: it does not matter what looks good on a slide. It matters what works at shift handover. That perspective turned out to be my biggest advantage as a self-taught developer — I know the problem before I write the first line. What I have built PIPEZ — a shift & part-count PWA. Offline-capable, running on Cloudflare Workers + D1, live in production to capture shift and piece-count data that used to live on paper. A tool-management app. A multi-user client-server app with optimistic concurrency and a local AI assistant, used daily in the office to manage the lifecycle of dies in tube production. DeepCode — an agentic AI coding client. Electron + React + TypeScript, with its own tool loop, a swarm mode, and CI/tests. The project I am proudest of. Plus multi-agent systems, RAG pipelines, and n8n automations that run every day. The stack Python/FastAPI, TypeScript/React, Node, Docker, PostgreSQL + pgvector, Cloudflare Workers, MCP, computer vision. Writing in public I will be writing here about the bridge I keep coming back to: real production experience plus building with AI. If you are automating something messy and real, I would love to compare notes.

Project Log #9: My AI Agent Works on My Phone. But What About Yours? Okeke Chukwudubem Okeke Chukwudubem Okeke Chukwudubem Follow Jun 20 Project Log #9: My AI Agent Works on My Phone. But What About Yours? # ai # webdev # programming # productivity 1 reaction Add Comment 3 min read

Day 9. Template matching works. But screen sizes, resolutions, and Android versions might break everything. Eight days ago, the agent was an idea. Now it can read text, handle interruptions, and find icons on a screen. But there's a question I've been avoiding: does it work on any phone other than mine? The Cross-Device Problem Every screenshot I've taken, every icon I've cropped, every coordinate I've mapped—it's all on one device. My phone. Same screen size. Same resolution. Same Android version. Same DPI. Template matching relies on reference images that look exactly like the target on screen. Change the screen density, change the icon size, change the font scaling, and the match confidence drops. Suddenly "send_button.png" doesn't match anymore, and the agent can't press send. This isn't a bug in my code. It's a fundamental challenge in computer vision: reference-based matching breaks when the visual context changes. Today's Experiment I tested the same agent on a friend's phone—different manufacturer, different Android version, slightly larger screen. The results were humbling. Task My Phone Friend's Phone OCR (text recognition) ✅ 95% accuracy ✅ ~90% accuracy Find "Mom" in contacts ✅ Found ✅ Found Template match: send button ✅ 94% confidence ❌ 62% confidence Template match: back button ✅ 91% confidence ❌ 58% confidence OCR held up reasonably well because text is text. Fonts might change slightly, but the characters are the same. But the icons—the send button, the back arrow—were rendered at a different size and slightly different pixel arrangement on my friend's device. The agent failed to send the message. Why This Matters An AI agent that only works on one phone isn't an agent. It's a script. If I want this to be useful to anyone else—or even to myself if I change phones—it needs to be device-agnostic. Possible Solutions I'm Exploring Solution Pros Cons Multi-resolution icon library Simple. Just crop icons at different DPIs. Tedious. How many variants are eno

Securing LLM Agent Teams: Inside NRT-Defense v0.4.0 Multi-turn autonomous LLM agents are expanding rapidly in safety-critical systems. However, a major vulnerability has been exposed by Lee et al. (2026) in the NRT-Bench paper : adaptive multi-turn attacks can exploit disjoint model vulnerabilities, causing a 8.7% to 12.1% loss of Critical Safety Functions (CSFs) . To solve this, I am open-sourcing NRT-Defense , an adaptive multi-turn defense framework designed to monitor agent sessions and reduce the attack success rate to <1% . The Threat: Context Drift and Disjoint Exploits Standard guardrails evaluate prompts in isolation (single-turn). Attackers leverage this by spreading an exploit across multiple conversational turns. Turn by turn, the context drifts until the agent team completely bypasses its safety containment. The NRT-Bench paper demonstrated this in a simulated nuclear power plant control room with 5 operator roles, 4 attack channels, and 6 critical safety functions. The results were alarming: Metric Value Attack success rate 8.7% — 12.1% Sessions analyzed 149 Models tested 4 frontier LLMs Vulnerability overlap Nearly disjoint The key finding: vulnerabilities are nearly disjoint across models . An attack that works against GPT-4 may not work against Claude. This means model diversity is itself a defense — but only if you can detect and respond to attacks in real-time. The Solution: 3-Step CMPE Defense nrt-defense neutralizes this threat through a continuous, multi-component pipeline: Per-Turn Message Analysis: Evaluates channel risk and turn-escalation metrics. Each message is scored for adversarial content using keyword detection, pattern matching, and channel-specific risk weights. Real-Time CSF Monitoring: Tracks 6 operational critical safety functions simultaneously. Risk accumulates over turns and triggers alerts when thresholds are breached. Context-Aware Misdirection Prompt Engineering (CMPE): When an anomaly is detected, instead of a blunt reject

"These are not your friends. These are not conscious beings. These are not sentient interlocutors.”

So ... what's your In the Weights score?