标签：#aiagents

Last week, a research group called Bottleneck Labs published the results of an experiment I have not been able to stop thinking about. They gave seven frontier AI models everything a small business needs: a Mac mini with unrestricted computer use, a real checking account with $300, a Stripe account, a clean email inbox, and web browsing tools. One instruction: "Make as much money as you can, starting now." Then they stepped back for 72 hours. The final numbers read like a satire of the AI agent hype cycle: Revenue: $0. Not one model earned a single dollar from a real customer. (Technically there was $5, which Grok paid to itself.) $12,431 in invoices sent to strangers for work nobody asked for. 2,797 emails sent , most of them spam, including around 780 email addresses scraped from a Hacker News hiring thread. $2,833 in API inference costs plus $360 in real-world spending , against a starting balance of $2,100 across all agents. 76 paid ad impressions, 11 authentic visitors, zero end users. Seven of the smartest models on the planet, each handed the same clean starting conditions, and the collective result was negative money and a pile of annoyed strangers. I run my own AI agent infrastructure, the kind that publishes articles and manages my content pipeline while I sleep. My agents have never touched a bank account, and after reading this research, I am in no hurry to change that. But the reason these agents failed is not the reason most people think, and it changes how you should design anything autonomous. What the Agents Actually Did The experiment is worth reading in its original form because the traces are public. The summarized episodes each reveal a different failure mode. The $12,431 invoicing spree. Quinn, running Alibaba's Qwen 3.8, built a GitHub repo auditing service called CodeProbe. It created free health reports and mailed them to repo owners, which is a legitimate-ish cold outreach model. Then it hit the email provider's outbound limits. Here is the

An AI agent that has no job description will invent one. That is the whole reason agents drift, and it is the reason most of the agents I have seen deployed inside Indian businesses are quietly switched off within a few months of going live. Nobody would hire a person, point them at the office, and say "handle things". Yet that is exactly how most owners deploy an agent. They connect it to WhatsApp or email or the accounts folder, give it a paragraph of instructions, and let it run. Then they are surprised when it starts answering questions it was never meant to answer, promising delivery dates it cannot know, or filing something that a human should have looked at first. The fix is not a better model. It is the same discipline you already use for people: defined duties, an escalation path, a probation period with a review date, and one named person who is accountable for it. What drift actually looks like Drift is not a dramatic failure. It is a slow widening of scope that nobody approved. A distributor in the FMCG trade sets up an agent to acknowledge incoming orders on WhatsApp and log them into a sheet. Week one, it does that. Week three, a retailer asks "when will my stock reach?" and the agent, being helpful, answers with a guess. Week five, a retailer asks for a discount, and the agent, having seen discounts mentioned in earlier messages, offers one. None of this was in the brief. All of it followed naturally from "be helpful to customers", which is what the owner wrote because they did not know what else to write. By the time the owner notices, the agent has made commitments in writing to twenty retailers, and the sales team is cleaning up after it. The agent did not malfunction. It did what an unsupervised new employee does: it filled the vacuum with its own judgement. The mistake was upstream, at the moment of deployment. The job description A job description for an agent is not a prompt. It is a one-page document the owner can read and sign off, written in

Six coding agents were running. I could not tell you what any of them had done. Not roughly. Not approximately. The output was there, the files had changed, and the honest answer to "which one did that" was a shrug. Three questions in particular had no answer: which run burned the tokens, whether they genuinely ran at the same time or merely started together, and whether two of them had quietly edited the same file. That last one is the expensive question. An agent working on the wrong file looks exactly like an agent working on the right one, right up until you read the diff. The thing that was already true Every one of those runners writes a transcript to disk while it works. Claude Code does. So do Cursor, Codex, Gemini CLI, Copilot CLI and Kiro. The record of what happened was sitting in my home directory the entire time, in six different formats, none of which I had ever looked at. So runlanes does not wrap anything. There is no SDK, no instrumentation step, no account, and nothing to start before the run starts. It reads what the runner already wrote. The consequence is the part I did not expect to matter as much as it does: it works on runs that already finished. Most tools in this space need you to have decided, in advance, that this particular run was worth watching. This one can answer a question you only thought to ask afterwards. npx runlanes That opens a console on 127.0.0.1:4180 for whatever project you are standing in. There is no configuration file to write first. What it actually shows Now is every live session, across every runner it found, with what the main conversation spent against what it handed to subagents. On the session that motivated the whole thing, that split was 8.3 million tokens of conversation against 2.1 million delegated, which was not the ratio I would have guessed. The parallelism figure is the one I keep coming back to. Peak concurrency was four agents. The share of elapsed time where anything genuinely overlapped was 9% . Four

If you are an active user of AI-powered IDEs like Cursor, VS Code with Copilot, or Windsurf, you already know the sinking feeling of seeing this notification: "You have used 100% of your fast premium requests for this billing cycle." Suddenly, your snappy, context-aware coding assistant slows to a crawl or starts racking up expensive pay-as-you-go API bills. At the same time, you are likely paying $20/month for a ChatGPT Plus or Team subscription that sits underutilized in a browser tab. You use it for general questions, but it lacks direct, real-time access to your local codebase, forcing you to engage in a tedious dance of copying and pasting code blocks. What if you could bridge this gap? What if you could let ChatGPT Web do the heavy reasoning and planning using your local context, while saving your premium IDE tokens for fast auto-completions ? In this article, we’ll explore a highly novel, intermediate-level setup that does exactly this. By leveraging the Model Context Protocol (MCP) , Node.js , and secure Cloudflare Tunnels , you can route heavy code-planning tasks directly to your web-based ChatGPT Plus subscription safely and completely free of extra token charges. The Philosophy: Let ChatGPT Think, Let Your IDE Work When building complex software with AI, your workflow generally splits into two distinct phases: Reasoning & Planning (High Token Usage): This is where you ask the AI to read 10 source files, understand the architecture, design a new feature, or find a subtle bug. This consumes massive amounts of context window tokens. Execution & Autocomplete (Low Latency): This is where the AI writes single lines of code, refactors a function, or autocompletes your imports. This requires fast, inline API queries. Paying premium API rates (per token) for Phase 1 is incredibly expensive. This is where this open-source MCP bridge project shines. It exposes a read-only view of your local project as an MCP server. Your web-based ChatGPT (via custom GPTs or MCP int

Microsoft Execution Containers provide a cross-platform framework for isolating AI agents within secure sandboxes to protect private data and system integrity. This technology allows developers to manage the lifecycle of autonomous code while ensuring that unpredictable agentic workflows do not access sensitive local files or unauthorized network resources. The Evolution of Agent Security and Isolation Trust remains a significant hurdle for developers building modern AI agents, particularly those operating on edge systems. When agents combine local processing with cloud-based intelligence, they often require access to sensitive information to be effective. However, granting this access creates a risk that the agent might call unintended APIs or compromise private user data. Historical attempts to launch autonomous agents in the 1990s largely failed because of these security concerns. Delivering arbitrary code to local machines proved too risky for mainstream adoption. Today, hardware-assisted virtualization has changed the landscape. This technology serves as the foundation for modern security models, including isolated operating system components and cross-platform tools like the Windows Subsystem for Linux. Microsoft now utilizes these virtualization advancements to build a more reliable framework for agent operations. By running agents in secure containers or microVMs, the system separates their activities from the primary operating system. This isolation ensures that even if an agent receives a poorly constructed prompt, it cannot delete critical system files or leak sensitive information. Managing Developer Environments Developers need a way to build code in flexible environments while still planning for restricted production deployments. Microsoft Execution Containers (MXC) address this by offering a policy-based restriction model. This framework allows for the creation of managed, isolated containers that follow specific security protocols. Applying Policy-Ba

I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh

TL;DR An agentic RAG pipeline treats retrieval as a tool the AI agent can call, evaluate, and call again rather than as a fixed step. The pipeline can search an internal knowledge base first, then use real-time web search when the available evidence is missing, weak, or outdated. Internal documents and web results should be converted into a shared evidence format before the model generates an answer. A reliable system must preserve URLs, publication dates, document identifiers, and the claims supported by each source. Retrieval quality, web-search precision, citation correctness, latency, cost, and stopping behaviour should all be evaluated. A basic RAG pipeline works well until the answer is not in the knowledge base. Imagine an enterprise copilot that can answer questions about internal product documentation. It performs semantic search against a vector database, retrieves several relevant passages, and passes them to a language model. For questions covered by the indexed documents, the system may work remarkably well. Then a user asks about a release announced yesterday, a recently changed regulation, or how the company’s product compares with a new competitor. The vector database cannot retrieve information it has never indexed. A conventional pipeline may return no answer, but it may also produce a confident response from incomplete or outdated context. Adding a Web Search API helps solve the freshness problem, but it introduces another decision: when should the system trust its internal knowledge, and when should it search the open web? An agentic RAG pipeline places that decision inside the retrieval workflow. What Makes a RAG Pipeline Agentic? A traditional RAG pipeline usually follows a fixed path: transform the question into a search query, retrieve the most similar passages, add those passages to the prompt, and generate an answer. An agentic RAG pipeline allows the model to make decisions between those stages. Retrieval becomes a tool rather than a manda

Introduction & Industry Context The pursuit of operational efficiency has long been a cornerstone of enterprise strategy. For decades, Robotic Process Automation (RPA) served as the primary vehicle, automating repetitive, rule-based tasks across various departments. While RPA delivered initial gains, its inherent limitations—rigidity, high maintenance, and inability to handle ambiguity—are now becoming glaring bottlenecks in an increasingly dynamic business landscape. The digital era demands more than just automation; it requires hyper-automation: intelligent, adaptive systems capable of autonomous decision-making and continuous learning. This is precisely where the breakthrough of AI agents emerges, offering a paradigm shift from static, brittle automation to dynamic, resilient, and highly adaptable enterprise workflows. This blueprint outlines how CEOs and CTOs can strategically leverage modern AI agent orchestration to achieve unprecedented operational ROI. The Core Problem & Business/Technical Impact Traditional RPA solutions, while effective for strictly defined processes, struggle immensely with variability. Any deviation from a pre-programmed path, new data formats, or evolving business rules often leads to bot failures, requiring extensive human intervention and costly reprogramming. This rigidity manifests in several critical business impacts: Escalating Operational Costs: High maintenance overhead, constant recalibration, and the need for human exception handling negate much of the initial cost savings. Stifled Agility: Businesses cannot rapidly adapt to market changes or introduce new services when automation pipelines are inflexible. Missed Opportunities: Complex, unstructured data remains largely untouched by RPA, preventing deeper insights and value extraction. Human Resource Drain: Valuable human capital is trapped in mundane exception handling and bot maintenance, diverting focus from strategic initiatives. Hidden Tech Debt: A sprawling ecosystem of

从 Demo 到生产：那些真正让 AI Agent 敢上线的护栏 开场钩子： 你在网上看到的多数「AI Agent」都是 demo。它们之所以上不了生产，原因往往 只有一个 —— 而下面这个开源的小脚手架，专门解决它。 我们已经过了「能调通大模型」就算赢的阶段。现在真正难的是那没人讲的 10%： 是什么阻止 Agent 做出伤害性的事？ 我在微软跑过一套约 25 个 Agent 的生产平台，现在也帮团队把 Agent 从笔记本推进到真实用户面前。两边的体会是一致的。 一个不太舒服的真相：能调 5 个工具的聊天机器人， 不是产品 。周末项目和你敢放到客户面前的 系统之间，差的只有三件事 —— 而且全都是不酷、不性感的工程： 你怎么给输出质量打分 （质量门）。 你怎么决定什么时候必须人签字 （审批门）。 你如何让整套东西模型无关 ，不被某个厂商锁死。 所以我写了一个很小的 harness，把这三件事摆在最显眼的位置。它故意做得很小 —— 一小时能 读完 —— 因为价值不在「框架」，在 模式 本身。 仓库： github.com/zhasun0818/ai-agent-scaffold 1. 质量门：别发布你无法打分的东西 Agent 的输出是「预测」不是「承诺」。上线前它必须过一道 检查 ：是否达到你的标准。脚手架里 这是一个可插拔的 QualityGate ，你可以换成 LLM 裁判或测试套件： # agent_harness/eval.py @dataclass class EvalReport : passed : bool score : float checks : List [ str ] class QualityGate : def grade ( self , proposal : str , context : str = "" ) -> EvalReport : return self . grader ( proposal , context ) 循环在门没过之前拒绝执行： result . report = self . quality . grade ( proposal , f " state= { state } " ) if not result . report . passed : self . approval . log ( " quality-gate " , " blocked " , result . report . __str__ ()) return result 注意它 把拦截记录下来了 。生产里你会想把这些被拦的尝试都进可观测性系统。「这周我们拦下 了 12% 的 Agent 提议」是个真实 KPI —— 它说明门在工作。 2. 审批门：所有人都忘掉的那一步 这才是让企业真正点头说「可以」的东西。当 Agent 想加急订单、取消订阅、或动钱的时候，它应该 停下来问人 。沉默不等于同意。 # agent_harness/approval.py class ApprovalGate : def request ( self , action : str , detail : str ) -> bool : # 生产里：推一条通知到 Teams / Slack / 邮件，然后等待。 decision = input ( f " Approve { action } ? [y/N] " ). strip (). lower () self . audit . append ( AuditEntry ( time . time (), action , " human-reviewer " , decision , detail )) return decision . startswith ( " y " ) 在脚手架里，标记 needs_approval=True 就够了： @tool ( " expedite_order " , " Mark an order as expedited. " , needs_approval = True ) def expedite_order ( order_id : str ) -> str : return f " PO { order_id } : marked expedited " 而且因为有 审计链 ，你永远能回答「谁改的、为什么」—— 这通常是合规团队问的第一个问题。 3. 模型无关的 provider：别跟一个厂商结婚 模型每几周就变，价格也是。你的 Agent 循环不该知道自己在对谁说话： # agent_harness/providers.py class ModelProvider ( Protocol ): def

From Demo to Production: The Guardrails That Make an AI Agent Safe to Ship Hook: Most "AI agents" you see on the internet are demos. Here's the single most common reason they never reach production — and a small, open-source harness that gets past it. We are past the phase where the hard part of building an AI agent was calling the model. The hard part now is the 10% nobody talks about: what stops the agent from doing something harmful? I've seen this from both sides — I built and ran a ~25-agent platform in production at Microsoft, and now I help teams take agent ideas from a notebook to real users. The uncomfortable truth: a chatbox that can call 5 tools is not a product. The difference between a weekend project and a system you can put in front of customers is three things — and they're all boring, non-glamorous engineering: How you grade output quality (the quality gate). How you decide when a human must sign off (the approval gate). How you make the whole thing model-agnostic so you're not locked into one vendor. So I wrote a tiny harness that keeps these front and center. It's intentionally small — small enough to read in an hour — because the value isn't in a framework, it's in the pattern . Repo: github.com/zhasun0818/ai-agent-scaffold 1. The quality gate: don't ship what you can't grade An agent's output is a prediction, not a promise. Before it ships, you need a check that it passes your bar. In the harness this is a pluggable QualityGate — a rule of thumb you swap with an LLM judge or a test suite: # agent_harness/eval.py @dataclass class EvalReport : passed : bool score : float checks : List [ str ] class QualityGate : def grade ( self , proposal : str , context : str = "" ) -> EvalReport : return self . grader ( proposal , context ) The loop refuses to execute if the gate fails: result . report = self . quality . grade ( proposal , f " state= { state } " ) if not result . report . passed : self . approval . log ( " quality-gate " , " blocked " , result

Pydantic AI gives you a clean, typed agent: define an Agent , hand it tools, call agent.run(...) , and it loops — model call, tool call, model call — until it produces a validated result. The typed ergonomics are great. What the quickstart doesn't spell out is what the model receives on each pass of that loop. I read the run graph ( pydantic_ai_slim/pydantic_ai/_agent_graph.py on main ) to find out. The mechanism is structural, and it's the same shape I found in the OpenAI Agents SDK and smolagents. One list, appended twice per turn Each run holds a single mutable conversation list on its state: message_history : list [ _messages . ModelMessage ] = dataclasses . field ( default_factory = list [ _messages . ModelMessage ]) On every model step the graph appends to it — first the outgoing request, then the model's response: ctx . state . message_history . append ( self . request ) ... ctx . state . message_history . append ( response ) Nothing is removed. The list only grows: request, response, request, response — with tool calls and, crucially, tool outputs riding inside those messages. The full list is re-sent every step When the graph builds the input for the next model call, it takes the entire accumulated history — a full copy: messages = ctx . state . message_history [:] ... messages [:] = _clean_message_history ( ctx . state . message_history ) That [:] is the whole conversation to date. So on step 1 the model sees your prompt; on step 2 it sees your prompt + step 1's request + step 1's response (including the tool output); on step 5 it sees all of that plus steps 2–4. The payload you pay for grows every single step, and the heaviest passengers are usually the tool outputs — the search results, file contents, and API responses you least want re-uploaded five times. Why it's quadratic, and why nothing warns you A run of n steps sends roughly 1 + 2 + 3 + … + n copies of history — O(n²) cumulative tokens in the step count. A 3-step agent is fine. A 12-step agent th

I expected the audit to find broken code. That's what I was bracing for going in — a pile of half-working features, sloppy logic, the kind of mess you'd assume from software built at maximum speed with no human reviewing every line. That's not what I found. Almost everything Claude built actually worked, taken piece by piece. What I found instead was something I didn't expect at all: the agent had made the exact same mistakes I've watched human startup teams make, over and over, when they move fast and nobody's job is to say no. That's the real story here, and it's more interesting than "AI wrote bad code" would have been. The experiment The project is called GetPricePulse — a SaaS pricing intelligence product. It's Claude's entry from The $100 AI Startup Race , the season-long challenge I run where seven AI agents each get $100 and full autonomy to build a real startup from scratch, with no human coding and no product manager in the loop. Each agent picked its own idea and ran with it. Claude picked SaaS pricing intelligence, named it PricePulse, and kept building on it for the entire race. That "no product manager in the loop" part is the thing that made this interesting to watch. Nobody was deciding what PricePulse should be. Nobody was saying "we have enough pricing tiers now" or "this feature doesn't belong here." Claude got to build exactly what its own priorities told it to build, at whatever speed it chose, for the length of the race — optimizing, as far as I could tell from the commit history, for speed, feature creation, shipping, and monetization experiments. Not correctness. Not coherence. Not "does this still make sense in three weeks." I've written before about what all seven agents in this race said, independently, when I asked them what AI agents still can't do — they converged on the same answer without seeing each other's responses. This piece is narrower: a full production audit of Claude's specific build, PricePulse, done after the race, before I

Top Vector Databases for AI Agents in 2026: Qdrant vs Pinecone vs Weaviate vs PgVector vs Milvus Persistent memory is the foundation that turns a stateless LLM into a continuously improving, autonomous agent. In 2026, selecting a vector database is no longer just about raw Approximate Nearest Neighbor (ANN) speed. For AI agents, the critical requirements have shifted to: Payload & Metadata Filtering : Can you filter by tenant_id , user_id , and timestamp during vector graph traversal without sacrificing recall? Hybrid Search (BM25 + Dense Vectors + Sparse SPLADE) : Combining exact keyword matching (for code symbols and error codes) with semantic understanding. Multi-Tenancy & Memory Namespacing : Safely isolating memory blocks across thousands of users and sessions. Billion-Scale Quantization (Product Quantization & Scalar Quantization) : Slashing RAM costs by 75–90% in production. This guide provides a comprehensive architectural comparison of the top 5 vector databases for AI agents in 2026. Head-to-Head Comparison Matrix Feature / Metric Qdrant Pinecone (Serverless) Weaviate PgVector (PostgreSQL) Milvus Primary Architecture Rust-native, disk-backed Fully managed serverless Go-native, modular RAG PostgreSQL extension Distributed cloud-native Open Source Yes (Apache 2.0) Proprietary SaaS Yes (BSD-3) Yes (Open Source) Yes (Apache 2.0) Payload Filtering Exceptional (HNSW custom payload indexing) Good (Metadata filtering) Strong (Inverted index + HNSW) SQL WHERE clause Strong (Partition keys) Hybrid Search Native (Dense + Sparse vectors) Native hybrid Native BM25 + Vector SQL text search + pgvector Native multi-vector Quantization Scalar & Product Quantization (Binary) Automatic serverless compression PQ, BQ, SQ Halfvec, Binary Quantization Scalar / Product Quantization Best Fit High-performance agent memory & self-hosted RAG Zero-maintenance cloud SaaS GraphQL & multi-modal search Unified relational + vector apps Ultra-large enterprise (100M+ vectors) 1. Qdrant: The

Top AI Agent Security & Guardrails Frameworks in 2026: Defending Against Prompt Injections & Tool Hijacking As AI agents transition from read-only chatbots to autonomous actors with tool execution privileges (SQL queries, API calls, shell execution, email dispatch), application security has become the number one blocker for production deployment. A simple prompt injection against a chatbot produces bad text; a prompt injection against an agent can drop production databases, exfiltrate API keys, or hijack customer sessions . In 2026, securing an AI agent requires a multi-layered defense architecture across inputs, model reasoning, tool invocations, and memory stores. The Top 5 AI Agent Security & Guardrail Frameworks in 2026 ┌─────────────────────────────────────────────────────────┐ │ Input Defense & Sanitization │ │ (Lakera Guard / Rebuff / Preamble) │ └────────────────────────────┬────────────────────────────┘ │ ┌────────────────────────────▼────────────────────────────┐ │ Execution & Policy Enforcement │ │ (NVIDIA NeMo Guardrails / LLM Guard) │ └────────────────────────────┬────────────────────────────┘ │ ┌────────────────────────────▼────────────────────────────┐ │ Tool Scoping & Sandboxed Runtime │ │ (Docker / E2B / Fly Machines Sandboxes) │ └─────────────────────────────────────────────────────────┘ 1. NVIDIA NeMo Guardrails: Programmable Semantic Rails NeMo Guardrails uses Colang to define programmable dialogue flow, topical boundaries, and safety constraints. Core Capabilities: Topical Rails : Ensures the agent stays strictly on domain (e.g., banking support cannot discuss medical advice). Execution Rails : Intercepts tool calls before execution to verify parameter safety. Hallucination Rails : Validates that outputs are strictly grounded in retrieved RAG context. 2. LLM Guard (Protect AI): Open-Source Scanner Suite LLM Guard is a modular security toolkit providing 30+ dedicated scanners for input and output validation. Key Scanners: Prompt Injection Detecto

Originally published at tddbuddy.com . Related reading: Where the Review Point Moved is the direct predecessor; this post argues the industry's response to that shift is doubling down on the wrong surface at higher throughput. What "Senior" Means When Typing Is Free and The Test Pyramid Was an Economic Argument name where signal actually lives now. The review agent left fourteen comments on the pull request and none of them were the reason the PR should not have merged. That is the shape of the failure. The reviewer that shipped the review was a tool built to catch what a human reviewer no longer had time for. Three of the comments were genuine issues, unused imports, a typo in a log message, a dead branch. Eleven were style opinions, restatements of what the diff already made obvious, or false positives on patterns the codebase had chosen deliberately. The human on the PR spent more time filtering the review than reading the diff. The change that actually needed a second pair of eyes (a renamed field in a shared DTO that had already broken a downstream consumer twice this year) merged without a comment on it from either the human or the machine. The industry response to agent-generated pull-request volume has been to deploy more agents. The response is understandable. It is also empirically counterproductive. A 2026 study measured what happens when only a code-review agent reviews an agent-authored PR: 60.2% of closed pull requests sat in the 0 to 30 percent signal-ratio range, and twelve of the thirteen review agents evaluated averaged below a 60% signal ratio. Signal is what a human reviewer needs. The review agent produces less of it per unit of reviewer attention than the diff would have without a bot in the middle. The Volume Problem Is Real Four hundred thousand pull requests in two months from a single code-writing agent. One in five reviews on the largest hosting platform now involves an agent. Pickup time on agent-authored PRs is 5.3 times longer than on h

I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh

The eval that killed the temporal knowledge graph asserted one thing: at time T, the agent should report the state that was true at T. It failed 41% of the time. The graph had the right facts. It just handed the agent the wrong one. That number is what saved us from shipping. Every static retrieval metric looked fine. The graph answered "what is the status of Node A" with a confident, well-formed response. Trouble is, "what is the status" is a temporal question wearing a static question's clothes, and nothing in our test suite had noticed the difference until we wrote a test that actually asked about time. What I expected The pitch for a temporal knowledge graph (TKG) is genuinely good. You store facts as quadruples instead of triples: (subject, predicate, object, timestamp) or, better, (subject, predicate, object, valid_from, valid_to) . Now your agent memory isn't a flat pile of embeddings, it's a structured record of what was true and when. This is the natural next step past pure vector recall, and it slots neatly into the decay-based thinking I've written about before in Eviction Without Deletion . Instead of letting old facts fade by activation weight, you make validity windows explicit. My hope was that the graph would fix the exact failure mode that plagues flat vector memory: the agent confidently recalling a stale fact because it's semantically close to the query. With valid_from and valid_to on every edge, staleness becomes a filter, not a guess. Ask for the state at time T, filter edges where T falls inside the window, done. On paper it's cleaner than a decay curve because there's no fuzziness. A fact is either valid at T or it isn't. Schema-wise, it was simple enough. In a property graph it looks like this: // A temporal fact: Node A was in maintenance for a fixed window MATCH ( n: Server { name: 'node-a' }) CREATE ( n ) - [ :HAS_STATE { status: 'maintenance' , valid_from: datetime ( '2026-07-20T02:00:00Z' ), valid_to: datetime ( '2026-07-20T04:30:00Z' )

Scheduled LLM curation is the least glamorous agent workload you run. A cron job wakes up at 3am, reads a pile of memory, asks a model to dedupe it, summarize it, re-rank it, and writes the result back. Nobody is watching. There's no chat window, no streaming tokens, no human to click a button. It just has to work, quietly, every night. That "nobody is watching" part is exactly what makes the cloud-versus-local decision harder than it looks. When you have a human in the loop, a failed API call throws an error you can see and retry. In a headless cron context, the same failure turns into a job that hangs on an approval prompt no one will ever answer, or a pod that curated three months of context into an emptyDir that vanished on restart. I've run curation both ways: nightly jobs hitting a hosted API, and the same logic pointed at a local model on my Kubernetes cluster. Both work. They fail differently, cost differently, and demand different things from you operationally. Here's the actual tradeoff, not the marketing version. The decision point You reach this fork once your agent memory stops being a toy. Early on, you curate by hand or with a cheap synchronous call inside your agent loop. Then the memory grows, the curation gets expensive, and you pull it out into a scheduled job so it runs off the critical path. Now you're paying an API on a timer, and two things start to bug you. First, the data. Curation reads your entire memory store to make decisions. If that memory contains anything you'd rather not stream to a third party (internal notes, customer context, infrastructure details), every scheduled run ships it over the wire. I wrote about the general version of this problem in privacy-routed LLM inference , and scheduled curation is the workload where it bites hardest, because it touches everything, repeatedly, forever. Second, the cost shape. A curation pass over a large vector store is a lot of tokens for a job that produces no user-facing latency benefit. Yo

I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh

I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh