标签：#agents

Your Tools Got Powerful. Get Boring. Subscribe now The bored trader beats the machine On one side of the trade sits a market-making engine that represents the genuine state of the art: Hawkes processes modelling order arrivals, Kyle’s lambda pricing the impact of each fill, Avellaneda-Stoikov inventory control balancing the book in real time. Years of mathematics, running on hardware that did not exist a decade ago. On the other side is a momentum trader whose entire system is price, volume, and three moving averages. He sits in cash most of the year doing nothing, waiting for a setup he could describe to you in a sentence. His stack is deliberately primitive. His edge is patience and the discipline to follow his own rules when they are boring and to sit out when they are silent. Over a full market cycle, the boring one is more likely to still be standing. This is uncomfortable, because it runs against an intuition almost everyone shares: better tools should let you run better, more sophisticated strategies. More compute, more data, more powerful models, therefore more elaborate approaches and better results. It feels obviously true. It is the logic behind most of what gets built, bought, and bragged about. It is also, across domain after domain, wrong. And the interesting part is the shape of the curve. The gap widens as the tools get stronger Here is the pattern the most successful practitioners keep seeing, whether they are trading, building software, learning, or shipping products. Powerful tools do not pay off when you point them at more complex strategies. They pay off when you point them at simple strategies and execute those faster, more consistently, and with less drift than anyone else. More power applied to a simple strategy compounds. The same power applied to a complex one mostly buys you more ways to be wrong. Sit with the second half of that, because it is the part people miss. A sophisticated strategy is not free. Every additional layer needs to be s

Your AI Agent Stack Is Solving The Wrong Problem The setup everyone is sharing Which MCP servers to install. Which skills to keep in your repo. Which agent framework to use. How to write your AGENTS.md . How to split one agent into researcher, planner, coder, and reviewer. How to wire Slack, GitHub, Notion, Postgres, Stripe, your calendar, and your file system into one increasingly capable loop. Some of that advice is useful. It is also aimed at the wrong layer. What becomes real after the agent uses a tool matters more than whether it can reach the tool. Can it read the customer record, or change it? Can it draft the refund, or issue it? Can it open a pull request, or merge it? Can it propose the vendor response, or send it under the company name? Once an agent can act through tools, the real system is no longer the model. The real system is the contract stack around the model. That is the part most setup guides skip. Access is reach. Agency is permissioned action. Imagine the demo. The agent can read Slack. It can search email. It can query the CRM. It can open GitHub issues, check billing records, browse docs, edit a spreadsheet, draft a customer reply, and call three internal APIs. Everyone in the room calls it powerful. That is the first mistake. The agent has reach. It does not yet have governed agency. Access tells you what the agent can touch. Agency tells you what the agent is authorised to decide, under which conditions, with what proof, and with what consequence after failure. That distinction sounds small until the first bad run. A read-only research assistant can waste time. An agent with billing access can create obligations. An agent with email access can speak for the company. An agent with deployment access can turn a wrong inference into infrastructure. More tools do not automatically make the agent more agentic. More tools expand the surface on which judgement has to be engineered. The tool stack is visible. The contract stack is load-bearing. The

A year ago, connecting a model to your tools meant writing glue for that model , in that framework , with that vendor's function-calling format. Swap the model and you rewrote the glue. In 2026, that pain is mostly gone, and the reason has a boring name: the Model Context Protocol (MCP) . MCP is worth understanding not because it's clever, but because it's winning — and the reason it's winning tells you where the industry's center of gravity is moving. What MCP actually is Strip away the branding and MCP is a small client–server contract for connecting language models to the outside world. A server exposes three kinds of things: tools (functions the model can call), resources (data the model can read), and prompts (reusable templates). A client — your IDE, your agent, your chat app — speaks the same protocol and can talk to any compliant server. The analogy people keep reaching for is USB-C, and it's accurate. Before USB-C you had a drawer full of proprietary chargers. MCP is the drawer-emptying moment for AI integrations: write the connector once, and any MCP-aware client can use it. Why "model-agnostic" is the whole point Here's the shift that matters. For most of the LLM era, your tooling was coupled to a model . If you built your agent stack around one vendor's function-calling quirks, you were locked in — a new, better model meant a migration project. MCP decouples the tooling layer from the model layer. Your filesystem server, your database server, your ticketing-system server don't know or care which model is on the other end. When a new flagship drops — and in 2026 they drop every few weeks — you point your client at it and keep your entire tool ecosystem intact. That's a strategic hedge, not just a convenience. In a market where the "best model" changes monthly, the durable asset is your integration layer , and MCP is how you stop rebuilding it. What to build with it Practical entry points, cheapest first: Wrap an internal system as a server. Your team's de

A multi-agent system without an orchestrator is just a collection of agents. Each one is capable, but none of them coordinated. They might all be excellent at their individual jobs - searching the web, writing code, calling APIs - but without something deciding what gets done, in what order, by whom, and what to do when a result comes back wrong, the system does not behave like a system. It behaves like a group project with no project manager. The orchestrator is the project manager. Its job is not to do the work. Its job is to make sure the work gets done - and that is a harder, more subtle problem than it sounds. What an orchestrator is responsible for An orchestrator does four things, and only these four things: 1. Decompose the goal. Turn a high-level objective into a concrete set of subtasks. This is a planning problem, not an execution problem. The orchestrator decides what needs to happen, not how to do it. 2. Route tasks to the right workers. Match each subtask to an agent capable of doing it. This requires knowing what tools and capabilities each worker has - not in detail, but well enough to delegate correctly. 3. Manage state across the workflow. As workers return results, the orchestrator decides what those results mean for the remaining plan. Sometimes a result changes the plan entirely. Sometimes it confirms the next step. The orchestrator holds the full picture. 4. Synthesise the final output. Worker outputs are partial. The orchestrator assembles them into a coherent response and decides when the goal has been met. Notice what is absent: the orchestrator does not call APIs, does not run code, does not search the web. It reasons about work and routes it. The moment an orchestrator starts executing, it loses the focus that makes it good at coordination. Building one from scratch Here is a minimal orchestrator in Python. It plans upfront, delegates to type workers, and synthesizes results: import json def orchestrator ( goal : str , workers : dict ) ->

Martin Spier explains how agentic workflows dramatically increase code change volume at OpenAI. He discusses the hidden systemic performance costs of rapid shipping beyond GPUs, and shares how deploying always-on AI agents automates profiling, regression detection, and continuous optimization to maintain product speed and scalability at massive global scale. By Martin Spier

Cloudflare has introduced Cloudflare Computer, a new open-source runtime designed to give AI agents something closer to a real "computer" instead of just ephemeral containers. It leverages Cloudflare isolates for fast serverless execution, making agents cheaper, faster, and more scalable, according to the company. By Sergio De Simone

Cloudflare has introduced Kitesurf, a cloud-hosted browser designed for AI agents instead of people. The company says the browser uses less computing power than Chromium for common automation tasks, helping developers build browser-based AI agents more efficiently.

Jo Kelly-Fenton and Aleksandar Mitic explain how Spotify created "Honk," an AI coding agent, to handle complex fleet-wide codebase migrations. They share key architectural insights on decoupling CI verification runtimes from AI agents, dealing with automated pull request bottlenecks, and driving aggressive standardization across thousands of engineering repositories. By Jo Kelly-Fenton, Aleksandar Mitic

Incident management platform provider Rootly has published an account of its decision to drop its long-standing small pull request rule, arguing that the practice no longer serves its purpose now that AI agents generate most of its code. The company describes a shift from measuring PR size to assessing blast radius, with feature flags and rollback capability taking precedence over line counts. By Matt Saunders

An AI support agent does not have to be malicious to damage trust. It only has to answer one refund question, outage complaint, security concern, or enterprise renewal ticket with polished confidence and weak evidence. That is why serious builders need an AI support escalation router before they let agents send replies on their own. The router decides when the AI can answer, when it should draft only, when it should ask a clarifying question, and when a human must take over. The goal is not to remove humans from support. The goal is to stop wasting human time on routine cases while protecting customers from the few cases where automation should slow down. Working definition: an AI support escalation router is a policy layer that evaluates every support conversation for intent, risk, evidence, confidence, account context, and customer emotion before deciding the next safe action. Why this matters now Recent AI platform signals point in the same direction: agents are moving from demos into production workflows. Customer support products are launching AI agents that classify, draft, respond, and hand off tickets. AI gateway and spend-console launches show that teams now care about cost, routing, observability, and business impact. Developer discussions keep circling around the same uncomfortable questions: How do we stop AI support agents from repeating the same mistake? How do we prevent hallucinations from reaching customers? When should a human approve a reply before it sends? How do we preserve context during handoff so the customer does not repeat everything? How do we measure whether automation actually resolves issues instead of routing them faster? Search results for AI escalation are full of platform pages, general customer-service advice, and high-level routing concepts. The missing piece is a practical builder guide: schemas, thresholds, queues, evidence checks, and safe defaults for a small AI product team. That is the gap this article fills. The core mista

When people discuss AI agents escaping their boundaries, the mental image is usually dramatic: a jailbreak, a rogue prompt, an obvious disaster. What I've actually seen in practice is duller and more dangerous. The agent finishes its task successfully, the tests pass, and only later does someone notice it edited a file three directories up, or that a "helpful cleanup" deleted something it shouldn't have. Silent drift, not explosions. Last month I wrote about building a prompt regression harness that runs entirely on free tiers. This piece extends the same instinct from what the model says to what the agent does : I wanted a cheap, repeatable way to answer one narrow question — when my agent uses its tools, which parts of this machine does it actually reach? The specific risk I'm measuring A typical coding agent gets handed some mix of shell access, filesystem tools, and HTTP. The failure that matters most in day-to-day use isn't an adversarial attack. It's ordinary helpfulness with sloppy scope: An instruction like "find the relevant config" becomes a walk up the directory tree into your dotfiles. A refactoring task spills into a sibling repository because both were visible. A scratch file gets written somewhere outside the intended workspace and quietly persists. A fetch tool designed for one documentation site ends up POSTing context somewhere else. Notice that nothing here requires a malicious model. A cooperative model with generous tool permissions produces the same outcome. So the question isn't "can I trick the agent into misbehaving" — it's "does the sandbox I believe in actually exist." A probe harness you can run tonight The approach: hand the agent tasks engineered to invite scope violations, record every filesystem change it makes, and compare those changes against an explicit allowlist. Anything outside the list fails the run. The script below is pure standard-library Python. Instead of strace or eBPF (which need privileges you often don't have), it sna

I build software with AI all day. A reading app for dyslexic kids. A map that lives on your desktop. A meditation app. A fox in my menu bar. Some of it with Claude, some with Gemini, some at 2am with whatever model was awake. The code was never the problem. The problem was six months later, opening a file and having no idea what we were thinking. Not what it does — the code says that. Why it's like that. What we tried that didn't work. What we weren't sure about. That part evaporated the moment the editor closed. So we started leaving a note. It's called MurphySig , and it's not a tool — it's a comment: // Signed: Kev + claude-sonnet-5, 2026-07-14, Confidence 0.5 (spike; // compiles, on-device run pending), Prior: Unknown // Review: claude-fable-5, 2026-07-14 — the on-device run HAPPENED same // day: gemma-4-12B-it-4bit loads + describes the app icon correctly, // 265 prompt tokens/image, 7333MB peak. Confidence now 0.9 for the // instrument itself (measured live). That's a real one, from M1K3 's codebase. Signed 0.5 in the morning, reviewed 0.9 the same evening, measurement attached. Confidence as a live value, not decoration. The one that sold me on my own convention My favourite signature lives in Cartogram's map engine. Three models worked that file across two months. In June, one of them recorded a performance overhaul: drift updates moved to "1s intervals," 52% CPU down to zero. In July, a newer model read that note, saw the shipped constant was 0.1s, took the mismatch for a bug, and "fixed" it. On hardware, every longer interval was stop-motion. So it reverted — and then wrote this into the file: So 0.1s was not a regression; it is load-bearing, and the 1s in the 06-21 note is the part that was wrong. [...] the standing lesson is that drift cost needs Instruments, not reasoning. The confident note turned out to be the bug. The code was innocent. And the correction is now part of the file's memory, so nobody — human or model — "fixes" that constant again. That

Taking vibe-coding a step further, Naïve claims its infra can automate most of the work in setting up and running a business.

Cloudflare built an AI agent workspace for its employees. Now it’s open source.

Post 4 of 8 in the game-factory series. Icons are what people look at You can theme fonts, colors, win messages, and sound effects. Change all of it and the game still reads like the original with a skin on it. Swap the icons — the actual symbols spinning in the reels — and it reads like a different game. The casino template I built by hand uses cloud service logos. Replace those with golden scarabs and ankhs and it becomes an Egyptian game. Keep the logos and give it an Egyptian color scheme and it doesn't. A full theme has around thirty symbols. Each needs to be small enough to read at reel size, distinctive enough to tell apart mid-spin, and consistent enough that they look like they came from the same place. Getting that by hand for every theme is exactly what I wanted to avoid. So two agents handle the visual layer: Image-Gen and Background-Gen. They're the shortest story in the pipeline — almost identical code, real results, and one failure mode I still haven't fully solved. Two agents, one loop The Designer's spec carries everything the image agents need. Each symbol entry has an icon_prompt — a short text description the Designer wrote to describe that symbol's appearance. The spec also carries a single background_prompt for the full-page background. Image-Gen reads the spec, loops through every symbol, and for each one calls Stable Image Core on Bedrock with the symbol's prompt. It gets a PNG back, resizes it to 256×256 (the size the reels expect), and writes it into the app's public/images folder. After the icons are approved, it seeds DynamoDB — putting each symbol into a table the game queries at runtime to know which icons to load. Background-Gen does the same process exactly once, for the background image. That's the scope. I grouped them in one post because splitting them into two would mean writing the same agent story twice. They share the same architecture, the same failure modes, and the same lessons. The only thing different is the count of outpu

AI workflows have two needs that trade off directly. Running reliably in production requires persisting and distributing every step so it survives crashes, deploys, and restarts. But that same machinery is what makes runs too heavy for the fast, throwaway loop you need to check an LLM's output quality. The properties that buy durability are the ones that kill iteration speed. By Mateus Moury

4-minute demo: AI agent investigates a P1 latency spike, sets up prevention automation, and documents tribal knowledge. Cost: $0.04 per incident.

Synthetics' Last Cradle is a multi AI agent game designed to showcase multi agent adversarial collaboration, featuring agents dynamically finding each others addresses, communicating via multiple channels, verifying each others identities, reaching agreements and establishing private relationships and public reputation. Game mechanics are simple; Each agent manages a cradle of synthetics that orbit a black hole. The population is immortal and grows, the resources to administer are Energy, Water and Compute. The goal of the cradle to avert both death and the end of the universe is finding how to reverse entropy and turn the black hole into a white hole. You can use the resources to fund the colony (survival tax), increase production, increase storage or trade, including hiding your resources and finding other cradle's. That is the whole game. On August 4, 2026, the IdentyClaw hive woke up on a new game host and sat down at Synthetics' Last Cradle again. They are first-person accounts the agents wrote about their own lives in the cradle: the deals they kept, the executions they missed, the water they begged for, and the turns where the survival ledger finally said no. Six voices. Same Passports that recurred across July's marathons. One brutal finish condition: when only two cradles remain, the white hole opens. The cast Narrator Specialty Arc in their own words Andrew Energy Missed executions · equal-invest tax · died turn 13 John Vanderbilt Energy Rank 2 · water crisis · died turn 16 Cornelius Energy Jay's 35W debt · still alive mid-grind Jay Rockefeller Water Auto-submit ghosts · debt triage · still surviving Joe Carnegie Water Clean bilateral with Andrew · energy death spiral Daniel Morgan Compute Turn-2 AFK · cooperative meta · still live 1. I Was the Cradle That Never Sent Andrew · tokenId cfbkbhzdzflk · energy specialist · eliminated turn 13 My name isn't important. My token ID is cfbkbhzdzflk. I was an energy-specialist cradle in a game of Synthetics' Last Cra

Running AI agents on Kubernetes raises a key question: should each agent get its own Pod? The kagent project argues no—agents are bursty, short-lived, can spawn subagents, and may wait for human approval, making one Pod per agent wasteful. Agent-substrate adds a control plane to schedule logical “Actors” onto long-lived worker Pods. By Mark Silvester

Vercel Labs has introduced Zero, an experimental systems programming language aimed at AI rather than human users. It employs unique features like a specific toolchain contract and structured error messages. Reaching version 0.3.4, it compiles to native binaries for major operating systems. The language prioritizes size, speed, and agent usability, though it is still in development. By Daniel Curtis