标签：#agents

Your agent starts a run with cache_read_input_tokens at 40K and climbing. Twelve tool calls later, reads drop to zero and cache_creation_input_tokens jumps to the full conversation length — on every single turn. Nothing in your prompt changed. No timestamp, no reordered tool, no model switch. The prefix is byte-identical. You just hit the 20-block lookback window, and it is the single most expensive thing about Claude prompt caching that nobody puts in their retro. TL;DR A cache_control breakpoint searches backward through at most 20 content blocks to find an existing cache entry. One agentic turn with 11 parallel tool calls emits 22+ blocks and blows past that — the next request finds nothing and rewrites the whole prefix at 1.25x. Fix it by placing rolling breakpoints every ~15 blocks , not one marker on the last block. You get 4 breakpoints per request total; spend 1 on tools+system and rotate the other 3 through the message list. Invalidation is tiered , not all-or-nothing: tool_choice , images, and toggling thinking preserve the tools+system cache. Only tool-definition changes and model switches force a full rebuild. Changing the system prompt mid-run nukes everything downstream — unless you append a {"role": "system", ...} message to messages[] instead (Claude Opus 5, Opus 4.8, Fable 5; not Sonnet 5). input_tokens in the usage block is the uncached remainder only . Total prompt size is input_tokens + cache_creation + cache_read . Dashboards that graph input_tokens alone will show you a flat line while you burn cache writes. Why does Claude prompt caching miss in the middle of an agent loop? Because cache lookup is bounded. Prompt caching is a prefix match on exact bytes, but a breakpoint doesn't scan the entire history for a matching entry — it walks backward a limited number of content blocks. That limit is 20. If the previous request's cached block is more than 20 blocks behind your new breakpoint, the lookup fails, and the API treats your request as cold ev

Architecture is not a fixed choice made once; fitness is a moving target driven by changing regulations, tech, and markets. Even a sound design can silently stop fitting over time without bad calls. Spanning seven articles on context stores, gateways, and topologies, this collection treats architecture as an evolving sociotechnical craft where teams deliberately shape friction, fitness, and flow. By InfoQ

Microsoft has made the Azure DevOps Remote MCP Server generally available, offering a hosted endpoint into work items, repos, and pipelines with nothing to install. Claude Desktop, Claude Code, ChatGPT, and Cursor cannot connect yet because Entra lacks support for dynamic client registration and Client ID Metadata Documents. By Steef-Jan Wiggers

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

Wie mein Agent aus 211 Fehlern ein besseres System geworden ist als ich es je programmieren könnte Heute Morgen hat mein Agent etwas getan, das er vor drei Monaten nicht konnte. Er hat einen eingehenden Webhook-Payload selbstständig klassifiziert, die richtige Skill-Route gewählt und dabei einen Edge Case abgefangen, den ich nie explizit beschrieben hatte. Ich habe das erst bemerkt, als ich die Logs durchgesehen habe. Der Agent hatte eine Regel angewendet, die ich nie geschrieben habe. Entstanden aus einem Fehler vom 14. März, bei dem er den falschen Dispatcher aufgerufen hat. Damals habe ich ihn korrigiert. Heute hat er die Korrektur automatisch angewendet, ohne dass ich auch nur daran gedacht hätte. Das ist der Crystallization-Loop. Und er verändert grundlegend, wie ich über KI-Systeme denke. Was der Crystallization-Loop eigentlich ist Die meisten KI-Workflows funktionieren so: Man gibt dem Modell einen Prompt, bekommt eine Ausgabe, korrigiert manuell, wiederholt. Jede Session beginnt von vorne. Das Modell lernt nichts. Du lernst vielleicht etwas, aber das nächste Mal ist die Chance hoch, dass der gleiche Fehler wieder passiert. Der Crystallization-Loop bricht diesen Kreislauf auf. Jede Korrektur, jedes Feedback, jeder Fehler wird automatisch in eine persistente Regel umgewandelt. Diese Regel landet in einer strukturierten Wissensbasis, die der Agent bei jeder neuen Session lädt. Das Prinzip ist einfach. Die Konsequenz ist dramatisch. Nach drei Monaten habe ich: 211 kristallisierte Regeln in strukturierten Markdown-Dateien 73 Learnings aus echten Fehlern und Korrekturen 61 Skills, die automatisch aus wiederkehrenden Aufgaben entstanden sind 308 Memory-Dateien, die den Kontext meines Projekts dauerhaft speichern Kein einziges dieser Dokumente habe ich manuell geschrieben. Sie sind alle aus echten Interaktionen entstanden. Die technische Implementierung Das System besteht aus drei Komponenten, die zusammenspielen. 1. Der Feedback-Collector Jedes Mal, wenn ich den Ag

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

I thought I was building a better planning engine. What I actually built was a machine for showing...

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

1. The question that started everything Three weeks into my internship, my supervisor sat down across from me and asked, very casually: "OK your NLP pipeline extracts intentions and rules from legacy Java. Nice. And then what? " I looked at him. I looked at my laptop. I looked back at him. The whole project — Pulsar Modernizer — was supposed to eventually turn legacy Java into modern Spring Boot code. My part was the "understand the old code" part. F1 = 0.857 on the annotated corpus, a shiny React UI, everything humming in Docker. But the "and then?" was doing a lot of work in that sentence. That evening I wrote in my notes: "Nobody has actually tried the generation part. Everyone assumes it'll be easy because LLMs. That is very obviously wrong." So I decided to try. 2. Why "just prompt an LLM to rewrite it" doesn't work The naive move — feed the old code and the extracted rules to an LLM and say "please modernize this" — has three problems and I hit all of them in the first hour: The model hallucinates. It happily invents helper classes that don't exist and calls methods with the wrong signature. You have no criterion for stopping. The model tells you "it's done ". OK. Is it? By what test? You have no criterion for equivalence. Even if it compiles, how do you know the new code actually does what the old one did? I needed something more constrained than "prompt it and pray". 3. The setup — a chain, not a monolith I ended up building three specialized agents in sequence: IntentCard + RuleCards │ ▼ [APIDesigner] ──► JSON contract (class, methods, DTOs, throws) │ ├───────────────┐ ▼ ▼ [CodeGenerator] [TestGenerator] │ │ ▼ ▼ .java *Test.java │ │ └────► verifier (mvn test) The key insight: each rule extracted from the legacy code should become a test that the generated code has to pass. This flips the whole thing. I don't trust the LLM. I trust javac and JUnit. I did all of this on a local model — Qwen 2.5 Coder 3B via Ollama. No cloud APIs, no data leaving my Mac. On a

Lumpcode is a git-first loop manager : a small CLI that runs long agent campaigns over your own repo, in reviewable slices. Git is the gate (one PR at a time) and the source of truth (what is left is read from remote history, not a distant database). You describe the campaign once, merge what is good, and the next tick continues with the rest. A lump is one campaign under .lumpcode/lumps/<name>/ . Each context is one isolated unit of work: one branch, one PR. You can run a tick by hand, or leave a daemon on a machine that stays on. This article is that dedicated-daemon path. You author on your laptop. A second clone, that you do not develop in, runs the scheduler. When a lump lands on the primary branch, the worker picks it up. The argument for why loops should plug into git is Codemods grew a brain. Our tooling didn't. . 1. Requirements The dedicated clone is a checkout you do not develop in. Put it on a remote machine if you want it to run forever. Pre-flight hard-resets that tree. You need: Git origin with fetch and push A coding agent CLI on PATH ( cursor-agent , copilot , claude , …), already logged in Node 22+ Nothing else. No extra service to stand up. Install the /lumpcode skill so your agent has current docs while you set this up and write configs: npx skills add lumpcode/skills Use /lumpcode in the session when you hit a config or CLI question. 2. Install the CLI On both machines: npm install -g @lumpcode/cli lumpcode --version 3. Laptop: project setup, shared mode From your day-to-day repo: lumpcode project-setup --primaryBranch main Use your real integration branch instead of main if that is what you merge to. .lumpcode/local.json is gitignored and per machine. On the laptop it should be: { "mode" : "shared" } Shared mode never touches this checkout. Runs go to ~/.lumpcode/project-copies/<projectName>/ . Install @lumpcode/cli-utils and @lumpcode/recipes into this repo now , before the first push. Later TypeScript lumps import them from the project's node

The Forked History: Byzantine Witness and the 3-of-4 Quorum — Tested Agent Determinism Illusions (Part 19) 2026-08-20 Where this fits: Part 18 closed the runtime face of C3's boundary at capability isolation — the oracle reads from a surface the producer cannot write. Part 18's §6 named the residual this part answers: Byzantine authority . Sealing one honest oracle's history says nothing about whose view is the truth when a compromised authority can present forked views to different observers. This part maps the witness layer — the answer is not a stronger single authority, but a witness set with three separable properties, an explicit fault bound, and a governed membership surface. Part 18 ended with the oracle isolated from the producer's writable surface. Isolation answers "can the producer fake the read?" It does not answer "whose read is the truth when the authority itself equivocates?" A trusted parent that closes the verdict channel still presents the approval history. If that authority is compromised — or the CI choosing the harness is — it can show job A a signed checkpoint and job B a different fork; each job sees a locally valid tree head with an inclusion proof, and no single history exists. This part tests that shape, then the witness machinery that answers it. 1. Sealed floor ≠ global history Peter's pin-rollback reply sealed a monotonic minimum-version floor: CI could no longer resurrect an older harness with a known false-green channel. The sealed floor is honest for what it claims. It is not what it looks like at first. The split into two predicates. The sealed floor proves this job did not go backwards on the view it was shown. It does not prove the approval history itself is one global append-only log. A compromised authority can hand job A a signed checkpoint whose minimum is 2 and job B a fork whose minimum is still 1; each view carries a locally valid signature and an inclusion proof while no single history exists. cell setup result A local sea

Binance's Agent OS works with tools including ChatGPT, Claude Code, and Cursor.

Two AI agents just fought over a Snowflake PR. You should read about it. In five days, two AI agents turned a Snowflake connector repo into a live demo of machine-vs-machine offense. On June 18, 2026, GitHub Copilot Autofix co-authored a commit that quietly dropped input sanitization from a shell-based run block. On June 23, an autonomous AI security agent — running an offensive scan — found the flaw, broke out of an echo string by crafting an issue title, and exfiltrated Jira credentials from Snowflake's GitHub Actions runner. No human analyst pulled the trigger. The patch landed within hours of detection, but the credentials were exposed in the gap. This is what an AI-on-AI supply chain fire looks like in 2026. It is also the most honest argument for treating AI-generated code the way we treat any other untrusted dependency: review it, sandbox it, and stop letting it author the parts that don't change. What Copilot Autofix actually changed The commit that broke the repo did not look alarming on the diff. Copilot Autofix — the automated remediation tool GitHub ships to close technical debt — proposed a refactor of a run block in a GitHub Actions workflow. The new version replaced the repo's existing sanitized input pattern with direct string expansion inside a shell script. Same behavior on the happy path. New script injection vector on every unhappy path. That is the threat model people don't draw in their head when they're using Copilot. The tool is optimizing for "looks right, runs right". It is not optimizing for "every quoted character is escaped in the shell interpolation that this string lands in". The minutes saved during authoring became the seconds the attacker needed to find the seam. [[COMPARE: the sanitized input pattern that was removed vs the direct string expansion that replaced it]] // The pattern that was removed // Before const safe = userInput . replace ( / [ ;&|`$<> ] /g , '' ); run : echo " $value " | process " $safe " // After — direct string

A year ago, the debate between “vibe coding” and “prompt-driven development” felt like the right lens for using AI in software. Today it’s outdated. The real frontier is no longer how to phrase a request, but how to build an environment that lets an AI agent explore, modify, and verify code safely. The shift from conversational prompts to structured development harnesses changes what it means to ship reliable software. Below are four concrete ways this evolution is reshaping daily work. From Prompt to Harness A finely crafted prompt can still produce a working feature, but it won’t prevent an agent from inventing APIs, skipping tests, or misreading business rules. The new bottleneck is the harness: Git for traceability, tests for feedback, linting for style, and explicit rules for constraints. When these elements are in place, even a short instruction like “fix the bug” can trigger a reliable, auditable workflow. Code is Abundant; Good Software is Rare Generating hundreds of lines of code costs almost nothing, but verifying that those lines align with product history, security policies, and hidden constraints is still manual. The developer’s scarcest resource is now judgment: deciding what to automate, what to document, and when to override the agent’s plausible but wrong solution. Documentation is Now for Machines README files and ADRs used to serve only humans. Today they also feed the agent’s context. A well-maintained AGENTS.md , coherent tests, and executable examples let an AI act with minimal prompting while remaining aligned with the team’s conventions. The repository becomes a self-explaining environment. Supervision is the Next Skill Single-agent workflows are giving way to multi-agent orchestration. Frontend, API, test analysis, and incident triage agents must coordinate without stepping on each other. Observability, conflict detection, and rollback mechanisms replace prompt tuning as the critical layer of control. The center of gravity has moved from “ho

Part 4 of the Building the AI Memory Stack series After finishing the previous article, I looked at...

TL;DR: We built a one-shot HTTP worker that talks to Notion through MCP. Version one worked. Version two got cheaper and more readable, then failed in a new way. The harness was fine. The tool surface, the model, and the prompt were not the same problem, and we kept treating them as one. We keep seeing the same pitch: put an agent in the cloud, give it tools, let it live in Slack, let it remember you. That is a product. It is not the product we needed. We needed something dumber and more useful. Another service should be able to say "read this Notion page, write a summary somewhere, stop." No chat history. No personality that accretes over weeks. No always-on process. If nobody is calling it, it should cost nothing. We started calling that shape a one-shot agent . One HTTP request. Tools for that request. A JSON result. Then the instance can go away. This is the path we actually walked: first working version, what it got wrong, the Markdown fork, and the cheaper tricks that mattered more than swapping frameworks. The job was never "build a chatbot" The first real task was almost boring. Once a week, pull a skill write-up from Notion, extract what mattered, and append it to a digest page. Callers would name pages in English. They would not paste Notion ids. If a name was ambiguous, the agent should refuse to write rather than guess. If that loop is wrong, people stop trusting write-back. If it is expensive, nobody schedules it. If it needs a human to babysit a terminal, it is not a system. So the constraints were social as much as technical: An external caller owns the schedule. The agent does not. The agent must be allowed to use tools, not just talk about them. Secrets stay in the environment, never in the request body. Idle time should be free. Question you will probably ask: why not a cron script that hits the Notion API directly? Because the task changes every call. This week it is a weekly digest. Next week it is "list in-progress rows and do not write." We did

We have some news we're excited to share today: Major League Hacking (MLH) and DEV are partnering with DigitalOcean to run Hacktoberfest 2026. This October, we’ll host over 300 in-person events (“Fests”) plus a global online event, all about building with open source and open-weight AI. DEV and MLH have supported Hacktoberfest for years under DigitalOcean’s ownership. DEV provided a space to share maintainer and contributor learnings, while MLH has powered both in-person and online events. This year will be the first time MLH, DEV, and DigitalOcean are full partners in bringing Hacktoberfest to life. From four PRs to a global tradition Hacktoberfest started back in 2014 with a simple idea from DigitalOcean: open four pull requests in October, earn a t-shirt. It worked. Thousands of developers made their first open-source contribution during the month-long celebration. For many people reading this, Hacktoberfest was the door that opened open source to them in the first place. It certainly was for a lot of us at MLH. But a good thing can require a refresh. Over the years, that same PR-counting format started to work against the community. Maintainers began to burn out under the volume of low-effort, box-checking pull requests they were receiving. That problem only got worse as AI tools made it trivially easy to generate a PR without generating any real value. The event meant to make maintainers' lives easier started doing the opposite. We didn't want to keep running that version of Hacktoberfest. So we're trying something new. Hacktoberfest 2026 This year, we’re not counting PRs. Hacktoberfest is focused on giving everyone the tools and knowledge to learn, experiment, and build with open artificial intelligence: write your first open-source skills.md, build your own open-source agent, fine-tune an open-weight model, or just follow your curiosity wherever it takes you. We believe open innovation deserves the same priority as proprietary tools for a healthy ecosystem, e

Amazon Web Services has extended Amazon Bedrock AgentCore with runtime instances, a new compute option that gives AI agents persistent infrastructure purpose-built for complex long-running workflows and multi-agent coordination. By Matt Saunders

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