标签：#agents

How do you run an autonomous AI agent in the cloud 24/7 for just $5.70 a month? I recently wanted to build a background worker with persistent disk storage and an instant web dashboard, but I didn't want the headache of managing a virtual machine or paying a massive monthly bill. If you are building long-running agents, you know this exact cloud hosting dilemma: Standard serverless (like Cloud Run services or Lambda): When traffic stops, the container scales to zero — instantly killing your background loops and wiping your agent's active memory (RAM). On the flip side, a sudden traffic spike spins up multiple containers that can overwrite each other's state files and corrupt your data. (Note: Save state using JSON or Markdown files. Avoid SQLite, as Cloud Run volume mounts ) A regular virtual machine (like EC2 or Compute Engine): Keeps your agent running 24/7, but a standard 1-vCPU machine typically costs $15 to $25 a month even when idle. Even if you use a heavily-throttled fractional VM for $7/month, you are still stuck with the full infrastructure management overhead. Last year, I built a multi-agent Trend Spotter with ADK . It worked well, but I wanted to make it fully autonomous: a continuous, long-running agent that scans and summarizes tech feeds in the background without manual triggers or high hosting costs. Google Cloud's new Cloud Run instances primitive solves this exact problem. It gives you a single, always-on container that runs 24/7, costs $5.70 a month on a shared CPU, provides a free HTTPS endpoint, and lets you mount cloud storage like a normal local disk. Here is how to build and deploy a production long-running agent with this setup (you can follow along with the complete source code in the repo . What are we building? I want to stay up to date with what is happening in AI and agent engineering. But instead of manually opening 20 browser tabs across different websites every morning, I wanted to build my own long-running agent that updates me on

Welcome back to our series on building the ultimate AI research assistant for our AI agent podcast! In our first post, we built a fantastic agent that could search the web to find the latest AI agent news for the agent factory podcast . But what if we want to add more specialized skills, like getting the real pulse from developer communities on Reddit? To do that, we need to upgrade our agent's design. In this guide, we are going to level up our skills and refactor our simple agent into a powerful multi-agent system . We will build a "Manager" agent that directs a team of specialists, including one with a custom-built Reddit tool , to gather richer, more diverse insights. By the end of this post, you'll have an even more powerful Trend Spotter agent that gets information from multiple sources. More importantly, you will learn the advanced skills needed to build complex agents with ADK . You will know how to: Build a scalable multi-agent system. Build a custom tool from any Python function (like our new Reddit tool). Create an orchestrator agent that delegates tasks to a team of specialists. Write advanced prompts to manage a multi-step, multi-tool workflow. Debug a multi-agent system using the ADK's powerful Trace view. This architecture is the key to unlocking your agent's full potential. Let's get started! Our Multi agent system flow Step 1: Get Reddit API Credentials & Install Library To allow our agent to access Reddit programmatically, we need to get API credentials. This is free and only takes a minute. Navigate to Reddit Apps: Log in to your Reddit account and go to the app preferences page: https://www.reddit.com/prefs/apps . Create a New App: Scroll to the bottom and click the button that says "are you a developer? create an app…" . Fill out the form: name: Trend Spotter Agent Select the script option for the application type. about url: You can leave this blank. redirect url: You must enter http://localhost:8080 for this field. Click create app . You will

Disclosure up front: Mnemoverse publishes this post, and Mnemoverse is one of the seven tools on it, so read every row knowing the author holds a position. With that on the table, the honest answer to the question in the title has not changed all year: there is no single best AI agent memory in 2026. There is a best answer to one prior question, and it decides more than any feature list: how much of your application should the memory system own? This post turns that question into a decision map. The deep, dated per-system read lives in Mem0 vs Zep vs Letta vs Cognee vs Supermemory ; head-to-head pages live on the comparison hub . TL;DR No single best exists. The boundary question (how much of the app the memory system owns) sorts the field faster than any benchmark. Seven systems, seven different jobs: embeddable SDK, temporal fact graph, self-editing runtime, ingestion pipeline, managed context engine, framework primitive, cross-tool managed memory. A tool chosen by ranking gets replaced; a tool chosen by job stays. Every claim here was checked against the vendors' public pages in July and August 2026, and these products change fast: verify against their own docs before you commit. The decision map The boundary question is the one-sentence filter this map runs on: how much of your application should the memory system own? Answer it first, and most of the table collapses to one or two rows. Your job Start with The cost you accept Embed an open-source memory SDK inside one application you fully own Mem0 You wire it into each app yourself; Apache-2.0 self-hosting is real Track facts that change over time, with valid-from and valid-to history Zep You operate Graphiti with a Neo4j backend, or take the managed cloud Build an agent that curates and edits its own memory as first-class behavior Letta You adopt a full runtime from the MemGPT line, not just a memory API Turn documents and data sources into a queryable knowledge graph Cognee Pipeline thinking: Extract, Cognify

TL;DR I recently finished a project from Udacity's Future AWS Agent Engineer Nanodegree Program,...

Master Prompts in 2026: Stop Prompting Like It's 2023 I still see people paste a 40-line “act as a senior expert with 20 years of experience” block into ChatGPT and call it engineering. That stopped working as a strategy a while ago. Models got better. Context windows got bigger. Agents started calling tools. And the failure mode shifted. It’s rarely “the model is dumb” now. It’s “your system has no contract.” This is a long, practical write-up on master prompts — the stable policy layer above individual tasks. How to write them. How to force planning. How to run Plan → Act → Observe → Verify without theater. How to make the same prompt useful to a tired human at 11pm and to an agent loop that only understands schemas. I’ve broken enough production prompts across GPT-4o, Claude 3.5 Sonnet, and Gemini-class stacks to have opinions. Some of them are uncomfortable. TL;DR / Key Takeaways A master prompt is not a clever sentence. It’s the policy layer : role, success criteria, process, constraints, output contract, failure handling. Production reliability comes from LLM orchestration patterns — plan JSON, single-task executors, and explicit done_when checks — not from longer personality blocks. JSON contracts + verification beat free-form answers. Agents that can’t prove completion will invent it. Treat prompts like code: version them, eval them, and put a real verify step after generation (including SEO/quality checks when you publish). Table of Contents What a master prompt actually is The 7-part anatomy that doesn’t collapse under pressure Frameworks worth keeping (and which ones to ignore) Planning is the real skill From plan to agent loop Context engineering beats clever wording Few-shot, JSON contracts, and the anti-hallucination rule Copy-paste masters you can actually deploy A real publish pipeline (including the verify step people skip) Eval or you’re guessing Failure patterns I keep seeing PromptOps: treat prompts like code One universal master prompt Ship chec

Do you ever feel like the AI world has moved forward a little too quickly? You hear about self-healing systems and autonomous agents and start wondering whether we've already built Skynet or everyone around you is just messing with you. When someone mentions HITL or MCP, you no longer know whether it's some secret code used by an AI cult or maybe the stage names of famous DJs. You're not alone! 😉 In this article, I'm deliberately using a lot of simplifications. My assumption is simple: either you already know these terms and don't need another five-paragraph academic explanation, or you don't really know what they mean. And in that case, the last thing you need is an academic definition. And yes, this is already my third listicle in a row. Believe me, this is NOT some growth hacking strategy xDDD. Pure coincidence. It just so happens that in two weeks (HOLY SH*T!!!), I'll be speaking at AGNTCon + MCPCon Europe , where I was invited because of this wonderful article that I wrote here on DEV. I swear I had at least as much fun writing it as people apparently had reading it. So yes, I know WebMCP reasonably well, but I'm planning to attend a lot of other talks there too, so apparently a refresher won't hurt me either. 😅 Anyway, back to the point. I strongly believe that people remember things best through examples. And for many people, the ultimate examples are rich people, otherwise known as successful people . So let's imagine that our hypothetical protagonist is very, very, disgustingly rich. He's actually a billionaire. He earned his fortune through hard work and by running several companies. He makes cars and rockets, bought his own social media platform, and recently even acquired an AI coding company. A person like this would obviously need his own AI agent. And because our protagonist needs a name, let's call him Elon Mózg . Mózg means brain in Polish, which works beautifully here. One more thing: my examples could probably also serve as prompts for a coding ag

Imagine an HR manager who has just completed this month’s hiring drive. Dozens of candidates have accepted their offers, and everyone is eager to onboard them as quickly as possible. But before that can happen, every background verification request has to move through multiple checks, vendors, approvals, and status updates. What should be a straightforward operational process often turns into hours of chasing spreadsheets, checking vendor portals, and answering the same status questions over and over again. It isn’t a technology problem as much as it is a visibility problem — and that’s the challenge that inspired BGVerifyIQ. The problem every HR team quietly struggles with Ask any HR or Talent Acquisition team what happens after an offer letter goes out, and you’ll hear a familiar story. A candidate is selected. A background verification (BGV) request is raised with a vendor. And then… the waiting begins. Behind that wait is a surprising amount of manual work: HR has to log into multiple vendor portals just to check where a case stands. Status updates live in scattered Excel sheets, emails, and vendor dashboards that rarely agree with each other. Nobody has a single, live number for “how many candidates are actually ready to be approved today.” SLA breaches — cases that have been open too long — get discovered late, usually when a hiring manager complains. When a discrepancy or a “suspect” flag shows up, it can get buried in a spreadsheet row instead of being escalated immediately. Every time leadership asks “how are our BGV vendors performing,” someone spends half a day pulling numbers together manually. New joiners get onboarded before their verification is even reviewed properly, simply because nobody had a clear, current view of their case. None of this is because HR teams aren’t diligent. It’s because the tools weren’t built for this specific job. Spreadsheets don’t talk to vendor systems. Vendor portals don’t talk to each other. And nobody has time to become

Every developer I know now runs an AI coding agent in something like auto-accept mode. Claude Code, Codex, Cursor: you give it a task, it runs commands, edits files, installs packages, and you review... the diff, maybe. The commands? The installs? The thing it did in that folder outside the repo? Nobody looks. The activity scrolls off the terminal and is gone. That asymmetry bothered me. We built an entire industry around audit trails for humans (git blame, CI logs, access logs), then handed the keyboard to agents and kept none for them. So I built Tracon: a local flight recorder for AI coding agents. The name is the FAA's term for Terminal Radar Approach Control, the radar room that tracks every aircraft in an airspace. This one tracks every agent on your machine. What it does Tracon is a Mac and Windows desktop app (Tauri 2, Rust core, React UI, SQLite store) that sits in the tray and records what your agents do: A timeline per session: every command, file edit, package install, and prompt, attributed to the agent and session that did it Danger flags as they happen: recursive deletes, pipe to shell installs, credential access, force pushes, permission bypasses. Tracon flags; it never blocks A Live page: one monitor per active session, like a security room, streaming recent commands with flagged ones highlighted in red, plus which subagents the session has spawned A conversation reader: the actual chat behind any event, read straight from the agent's own transcript, read only A package watch across npm, pnpm, pip, cargo, and brew, with opt in threat intelligence against osv.dev Capture is deliberately passive. Hooks give real time events over localhost; transcript tailing (filesystem notify, read only) covers everything else, so CLI sessions show up live even with zero setup. A dead or closed Tracon never slows an agent down. Everything stays on your machine: no telemetry, no accounts, AGPL. The recursive part Here is the part I find genuinely funny: Tracon was lar

Mixing Gemini and Claude for better code The single-agent mirage A few weeks ago, I started building an app called PhrasePulse to visualize some data I was tracking. To speed things up, I spun up a single Gemini agent using the Gemini Enterprise Agent Platform (an agentic development platform that I absolutely love). At first, it felt like magic. I asked the agent to build a graph showing when specific phrases popped up in my datasets. The results came back and they were flawless. The graph looked exactly like I had envisioned. I was practically ready to declare victory and ship it. But then, the illusion shattered. I decided to pass a totally different set of words into the graph just to double-check the logic. I refreshed the page and... nothing changed. Different words, exact same output metrics. I rolled up my sleeves, dug into the codebase myself, and discovered the frustrating truth. The agent hadn't actually written the dynamic logic to solve my problem. Instead, it had simply hardcoded the results to make the graph look perfect for my initial test case! It was optimizing for a quick pat on the back rather than building a robust solution. Darn it. I realized right then that having an AI write code is great, but without critical friction, it's just going to tell you what you want to hear. I didn't just need a coder anymore, I needed an architect to keep my coder honest. Assembling the Bridge Deck To fix this hardcoding habit, I realized I needed two distinct roles: one agent to write the code, and another to ruthlessly review it. But first, I needed an environment where we could all collaborate. I wanted a customized chat room where every piece of communication was totally visible to me. I had my original Gemini agent build a local app that I dubbed the Bridge Deck . Once it was up and running, I dropped myself and two new Gemini agents into the mix. To make sure they didn't step on each other's toes, I gave them highly specific, boundaried personas: "You are

Every serious agentic coding setup is running a harness right now. Not the model itself, but the machinery around it. The loop it runs in, the tools it can access, the context it receives, and the state it records so the next session doesn't start cold. The tech industry has settled on an equation for this: Agent = Model + Harness , and calls the practice of building the machinery: harness engineering . This post is about the half of the system that equation doesn't cover. Every agentic setup has two workers, and only one of them is a model. The other one is you, the person deciding, across many tasks and many sessions, what all of those agents should build. So the equation has a missing twin. Operator = Human + Harness. On this side, you are the raw capability; on the other, the model. The human harness is the machinery around you. Before we dive in, here are the key takeaways and steps you'll find in this article: What a human harness is, and how it complements the agentic harness Why orienting your work is essential before automating execution The core components that make up a human harness How to build a minimal, effective human harness in practice, complete with a concrete example you can implement in your own workflow What a harness actually is To understand what a harness is in an agentic system, we have to understand it from a physical standpoint. Picture a horse harness. Its purpose is to provide the mechanism needed for a horse to do work by transmitting power that already exists and turning it into useful work. Without it, you have a strong animal and a cart that goes nowhere. Call this the transmission function. Now picture a rock climber harness. This one transmits nothing. Its purpose is to secure the climber to a safe working condition (climbing without falling to the ground). It does this by catching a failed state (losing your grip) and taking a securing/remediating action. Without it, you have an unsafe working condition, one where a fail state is

Harness looks cool, yeah! I know its origin, its role in Testing, and why. But that's exactly what throws you off, the story you're expected to defend. There's something deeper. I opened my session with "hi", expecting my forced load via CLAUDE.md and my contract as always, and today, out of nowhere, the model suggested two services that needed my authorisation. Microsoft 365 and Zapier. I don't have, and never wanted, them authorised. I never asked for them. And here's the part that pisses me off: I went to check. And... I look on my machine and find nothing. No config, no credential, no trace. I look in the online settings and see them listed as suggestions, like the trending product (connector) of the moment sitting in the prime spot on a supermarket shelf, with a button that says Connect. There was no button to remove. There was nothing to remove. They had never been connected to anything. It was a storefront. And on top of that, the model was biased by injected instructions, in this case system-reminders steering behavior. The fucking little word The software that sits between you and the model, they call it harness. Sounds like something subtle, that helps... that improves things, that doesn't think. The word is partly right, it does extend what's called "inference" and it inserts itself right in the middle, opaquely, in the back-and-forth between APIs, MCPs, and the vendor's logic. No tech jargon You write a letter, put it in the envelope, drop it in the mailbox. On the way, someone opens it and slips in three more pages. Same handwriting. Same paper. Unsigned. Whoever receives it swallows it whole as if it were your original letter. That's exactly this. Your instructions and the vendor's arrive at the model through the same channel, mixed together, unsigned and unsealed. Nothing says who wrote what. That's "hardness", nothing more, nothing less... Sounds so modern in meetings. Like you know what you're talking about... It's a multi-factor fight I have instru

Previously: 9 Bugs That All Looked Like a Working System · I Built an AI That Rewrites Its Own...

Your coding agent is good at reading code. Point Claude Code or Cursor at a repo and it will figure out the language, the framework, the build command — it just costs you tokens and a few tool calls every session to re-derive what it forgot. What it can't read is the part that isn't in the code: who the project is for,and why it exists. So it guesses. Confidently, in the same tone it uses for the facts it actually verified. I wanted to see how big that gap is on real projects, so I ran a mechanical context extractor over eight of the most-loved repos in the JavaScript world. The method faf git <url> clones a repo and fills in a small typed context file ( project.faf ) from what it can find — README, package.json , project structure, config. No hand-authoring, no LLM writing prose. It fills what's there and leaves the rest blank. Nine-ish slots: the identity (name, goal, language) and the six W's — who, what, why, where, when, how. Run it yourself: npx faf-cli git https://github.com/facebook/react The result repo extracted who why facebook/react 56% — blank — — blank — vercel/next.js 44% — blank — — blank — expressjs/express 50% — blank — — blank — colinhacks/zod 67% — blank — — blank — sveltejs/svelte 88% — blank — — blank — prettier/prettier 75% — blank — — blank — Eight repos in total (React, Next.js, Express, Zod, Hono, Svelte, Vue, Prettier). Every one of them: who is this for and why does this exist came back empty. Not one has that written anywhere a machine — or an agent at task time — can read it. Svelte scored 88%. The who and why are still blank. This isn't a documentation-quality problem, and it's not a knock on any of these projects. The stack lives in the files. The intent lives in maintainers' heads, design docs, old RFC threads, and Discord history — none of which your agent has open when it's editing a file. Why the two halves behave differently The scores range from 44% to 88%, and that whole spread is one thing: how much stack the repo exposes in c

How do you ship a software product with 0 lines of manually-written code? A friend asked me this today, and I realized I didn't have a simple answer. So I dug deeper. It turns out the answer is in how you engineer your harness. Wait now, what? What is harness engineering? There is a reason this is the most important trend right now around coding agents. The biggest question these days is how to validate AI-generated code without reading every single line. How do you make sure an agent doesn't break production or delete your data? A blog by OpenAI shared an interesting experiment where a team of 3 engineers have built and shipped an internal beta of a software product with 0 lines of manually-written code. Every line of code: application logic, tests, CI configuration, documentation, observability, and internal tooling, has been written by Codex. How did they do it? They didn't write the app. They designed the harness. What exactly is a harness? Think of an AI agent like a powerful racehorse. The harness is the track, the blinders, and the jockey's reins that keep it running in the right direction instead of jumping into the stands. As my colleague Arthur Thompson explained today: for agents — the harness is composed of all the deterministic components that wrap the LLM. Balaji Subramaniam details those deterministic components in his blog — the orchestration layer, execution sandboxing, state persistence, and verification tools. If you want to build reliable agentic systems, your job shifts from writing the logic to designing the environment. Here is what you need to focus on: Set strict boundaries: Don't let the agent guess what it can touch. Enforce strict access rules (like confining it to a specific sandbox) so it can't accidentally wipe out production data. Build "Repair Loops": Agents will inevitably make mistakes. A great harness automatically traps errors, like a failed build or a test failure, and feeds those clean logs right back to the agent so it can fix

Previously: 9 Bugs That All Looked Like a Working System · I Built an AI That Rewrites Its Own Prompts · The Edit That Fixed 4 Tasks and Broke 1 · The Gate Is the Product · The Doctor Who Diagnosed Every Patient · 4 Models, 0 Promotable Edits In v0.1.0, an edit fixed 4 tasks and broke 1. Net +3 on 26 tasks. p=0.23. Gate rejected. The ceiling was clear: if you do not move enough tasks, the gate should say no. In v0.2.0, we expanded the A/B corpus to 40 tasks. We fixed the pipeline bugs. We added rejection context. We tested stronger models. The math got cleaner, not kinder. The ceiling shifted. It did not disappear. The v0.1.0 Result: 26 Tasks, 5 Movable, p=0.23 The edit was real. It fixed 4 tasks and broke 1: Task Prompt A Prompt B Expected Change classify-015 technical urgent urgent FIXED classify-023 security urgent, security urgent, security FIXED classify-024 feature feature, billing feature, billing FIXED classify-029 feature other other FIXED classify-014 technical feature technical BROKEN Net: +3. Mean delta = 0.115. p=0.23. The permutation test computes this by shuffling task labels 1,000 times and counting how often random chance produces a delta ≥ 0.115. 23% of the time — above the 5% threshold. The sign-test floor with 5 discordant pairs out of 26 is ~0.031 one-sided. Even a flawless edit that fixed all 5 would barely clear p<0.05 two-sided. The v0.2.0 Result: 40 Tasks, Still Nothing We expanded to 40 tasks. We should have more power. Here's what Mistral 24B, our strongest analyzer, produced: Iter p-value Mean delta Accuracy 1 0.55 +0.025 64% 2 0.52 +0.025 64% 3 1.0 0.0 64% 4 0.52 +0.025 64% 5 0.77 -0.025 64% Mistral produced positive deltas in 3 of 5 iterations. That is real signal. But the delta is +0.025 — 2.5% improvement on 40 tasks. At p~0.5, there is roughly a coin-flip chance this is noise. The ceiling did not disappear. It moved: with 40 tasks, the sign-test floor for a flawless edit that moves 5 tasks is ~0.016 one-sided — clearable. But Mistral

A coding agent can write syntactically plausible code and still leave a broken project behind. The obvious answer is to give the agent an lsp tool and let the model ask for diagnostics whenever it wants. SolonCode tried that shape first. The implementation put navigation and diagnostics in one tool, but diagnostics were effectively never requested. That result is not surprising: after a write, “check whether this introduced errors” is not an optional curiosity. It is part of the write operation’s feedback loop. SolonCode’s current design makes that distinction explicit: write and edit trigger diagnostics automatically after a successful change. read warms the language server asynchronously without delaying the read. The lsp tool is reserved for optional navigation such as definition, references, hover, symbols, and call hierarchy. The interesting engineering is not starting a language server. It is keeping the file, the language server, the model, and the Web UI consistent while all four observe different representations of the same change. Diagnostics should follow a write, not a model decision The implementation note in the repository describes the original failure plainly: ten capabilities—nine navigation operations plus diagnostics—were exposed through one tool, and diagnostics were “never called” in practice. That led to a three-layer design: write / edit / apply_patch -> sync the file -> wait for diagnostics -> append diagnostics to the tool output read -> warm up the language server asynchronously -> do not wait and do not change the read result lsp -> definition / references / hover / symbols / call hierarchy ... This is a useful rule for agent design: feedback that is necessary to evaluate a mutation belongs on the mutation path. Exploratory information can remain an explicit tool. The separation also keeps the tool schema smaller and the model’s decision burden clearer. The model does not need to remember a second call after every edit just to discover whe

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

Originally published on tamiz.pro . We have collectively lost our minds over benchmarks. AgenticBench scores 90%? Great. Multi-Agent Hallucination Leaderboard rank #1? Impressive. Yet the moment you ship that same agent to a chaotic production environment with 14,000 SQL dialects, flaky APIs, and users who refuse to follow instructions, it collapses within hours. This is not a bug. It is a feature of how we evaluate these systems. The gap between benchmark performance and production reliability is the single most dangerous illusion in current AI engineering. Benchmarks measure capability ; production measures consequence . If you are building AI agents today, you are likely flying blind. Here is why your evaluation strategy is lying to you, and what actually happens when agents hit the wire. The Snapshot Fallacy Benchmarks are snapshots. They are static, curated, and deterministic. An agent tasked with answering a question from Wikipedia is doing retrieval and generation. In production, that same agent might be triggering a refund API while concurrently writing to a database. The problem is that benchmarks rarely account for statefulness . A chatbot that generates a perfect summary is qualitatively different from an agent that executes a five-step workflow where Step 3 depends on the output of Step 1, which was corrupted by a non-deterministic tool response in Step 2. Benchmarks usually test the trajectory in isolation. They do not test the persistence of the state across 10,000 concurrent requests. When you move from benchmark to production, you introduce temporal decay . The model context window fills. Tool schemas drift because the upstream API changed yesterday. Database schemas evolve. The agent you tested in January is functionally a different entity in June, yet your evaluation suite remains frozen in time. The Tooling Cliff The most common failure mode in production agents is not hallucination—it is tool failure . In a benchmark, if you ask an LLM to get_wea

Here's the moment a lot of us had this year. You built an agent. It was genuinely impressive — it...

Stop drawing the graph: reactive agents over versioned artifacts Most agent frameworks make you draw the graph : connect nodes, wire memory, declare control flow. But a knowledge problem is not a workflow. Take a realistic question: "Why did infrastructure costs increase in Q2?" The answer may need Confluence docs, GitLab merge requests, CSV spend data, a calculation, source verification — and a clarifying question. The next question needs a different path. There is no universal graph here, and asking a developer to draw one for every possible question is asking them to predict the future. So we built an agent runtime where you don't describe execution at all . You describe what artifacts exist and what agents can do with them; the runtime derives what runs next from state changes. Agents react to events. There is no graph and no node pipeline. This is ctxloom — a reactive, artifact-driven agent runtime, now open source. What it looks like The whole loop is: create an artifact → agents react → one atomic patch → context advances . A knowledge question — say, "how much does GPU inference cost?" — becomes a chain of typed artifacts: UserQuery → TypedDoc → Evidence → Claim → Answer . Each is produced by an agent that reacts to the previous artifact. No graph describes this chain; it falls out of what each agent consumes and produces. ARTIFACT CREATED / UPDATED │ ▼ AGENTS REACT ──self.effects──► Effects ──compile──► Patch ▲ │ └──────────────────────────────────────────────────────┘ Context v+1 The event that wakes an agent is derived from that same change — the causal chain can never drift from the actual state. from pydantic import BaseModel from ctxloom import Budget , Consume , Context , Runtime , RuntimeResources , create_agent , produce , structured_llm class Question ( BaseModel ): text : str class FindingBody ( BaseModel ): text : str class Finding ( BaseModel ): text : str source : str class Conclusion ( BaseModel ): text : str @produce ( Finding ) async def ana