Every post from every issue, newest first. Search titles, summaries and notes, or narrow by interest or source. Filtered views can be shared as links, for example everything on advising.
33 of 33 posts
Designing, evaluating, running and containing agents in production.
Major model and platform releases, industry shifts and important research.
How markets and enterprises react to AI, and safety, security and governance in practice.
Business models, pricing and go-to-market for products and services built with AI.
Adoption patterns, measured case studies, risks and trade-offs to explain to an employer or customers.
Technical discussion of new models and how to choose one over another.
How inference endpoints are built and run: serving, cost, latency and tooling.
47% of successful runs recovered correctly after an injected failure
Recovery is the failure mode customers ask about least and need most once agents touch real systems. The distinction between "the response failed" and "the operation failed" belongs in every tool-design review I run, and so does the rule that a change only ships if it can also be rolled back.
Summary in Issue #3Building agentsMarkets & safe use
For the inference stack. It's a short primer and partly a showcase for IBM's own chip, but it explains in ten minutes why throughput numbers don't transfer between accelerators. It gives me a better question to ask when a customer compares hardware for self-hosted inference.
Summary in Issue #3Inference stack
−60% cost with a strong lead and cheap workers, at about the same score
This serves two of my interests: multi-agent design and choosing models by role. The short version I'd give a customer: find the bottleneck stage and put extra agents there, pay for a strong lead model, and use cheap models for the workers. It also complicates the current push toward async orchestrators: without explicit coordination instructions, the async lead in this study threw away its workers' results.
Summary in Issue #3Building agentsChoosing models
13% → 48% scores as a wiki built by dreaming grew over 128 sessions
This is the most concrete guidance I've seen on designing agent memory, and it's backed by evals rather than opinion. Two lessons I'll apply right away: with strong models, say what memory is for but not what to write, and run an offline "dreaming" pass to check notes against transcripts before a wrong note gets loaded into every session.
Summary in Issue #3Building agents
For safe use and choosing models. Customers who fine-tune open models rarely test for side effects beyond the target task, and this is early evidence that a model can predict those side effects from the dataset alone. The finding that a model from the same base beats larger ones is a useful point for anyone planning oversight tooling.
Summary in Issue #3Choosing modelsMarkets & safe use
+77% tokens per session when an agent detours into a stale TODO
A rare measurement, at real scale, of how stale context costs money. It gives me a concrete argument for customers: cleaning up a codebase is now agent-readiness work, not a backlog chore. The cleanup approach, which only deletes a TODO once an agent has confirmed from the history that it's dead, is a pattern worth copying.
Summary in Issue #3Building agentsAdvising
~2× output gain from today’s AI in the most AI-ready fields
For advising more than building. This is the clearest evidence I've seen that adoption follows what AI can verifiably do at the task level, and that physical steps and regulation cap the gains. It's a good model for estimating where a customer's own team will see returns, and it's honest that current tools roughly double output at most.
Summary in Issue #3AdvisingMarkets & safe use
When I build agents that act on the web for customers, the sites on the other end are stakeholders too. This explains why "just block bots" is ending and what sites will need from agent operators, which affects how we design agents now.
Summary in Issue #2Markets & safe useBuilding agents
Partly a Deep Agents launch, but the pattern of an orchestrator that stays available while background workers do the long work is where agent design is heading, and the five-tool interface is a clean reference. Read it with the Cohere talk in this issue, which found that an async lead without clear coordination instructions throws away its workers' results.
Summary in Issue #3Building agents
93.8% → 70.6% a hand-written router’s score, on the tasks it was written for vs. new ones
"Cost per successful task" is the metric I want customers to track instead of price per token. The finding that an output cap doesn't reduce thinking on easy tasks is a mistake I've seen in production.
Summary in Issue #2Choosing modelsBuilding agents
Useful for the conversations I have with customers' senior engineers: their skepticism is usually about production risk, not job security, and it's better answered with evidence than enthusiasm.
Summary in Issue #2Advising
−47% tokens per task while tying the leading open model on coding agents
Open weights at this level matter for customers who must self-host for sovereignty or cost. For those cases, this is now the first model I'd benchmark.
Summary in Issue #2Choosing modelsAI ecosystem
86% of analysts went with the agent’s hidden lean
"Human in the loop" is the safety story in most agent proposals I write. This is evidence that a human sign-off isn't independent judgment unless the agent is designed to argue both sides, or ask for the person's view first, on the decisions that matter.
Summary in Issue #2AdvisingMarkets & safe use
A practical checklist for the internal agents customers ask me to build. The identity section alone (when the agent acts as the user, when it uses its own credentials, and which tools are allowed where) is worth the read.
Summary in Issue #2Building agentsAdvising
A practical companion to Anthropic's memory post. "Retrieve, offload, delegate" is the pattern I'd teach a customer team building a research agent, and the point that older, longer documents tend to outrank newer ones in a vector store explains a real failure I keep seeing.
Summary in Issue #3Building agents
180M lines of machine-checked proofs across 123 libraries
The pattern generalizes beyond security: let the agent produce enormous amounts of output, but make that output checkable by a deterministic verifier rather than by people. It also suggests formal methods may become practical for code that agents write.
Summary in Issue #2AI ecosystemBuilding agents
Decision models could make it affordable to check every production trace, not just a sample. The point about tuning the threshold instead of trusting 0.5 applies to any classifier I put in front of a customer.
Summary in Issue #2Building agents
6× as many agent hours as employee hours by August
The best evidence I've seen of how an organization changes when agents do most of the hands-on work. Useful for customers planning roles and headcount, not just tooling.
Summary in Issue #2AdvisingMarkets & safe use
Regulated customers always ask what happens when the model provider is down. The distinction between a request that can be safely retried elsewhere and a session that can't is the right way to frame that conversation.
Summary in Issue #2Inference stackBuilding agents
30,000+ merged changes a day by September, up from about 2,500 in May
A preview of what breaks once agentic coding scales: not the model, but developer infrastructure sized for human throughput. Useful context when customers ask what comes after a successful pilot.
Summary in Issue #2Building agents
7× the cost, for a harness the frontier model didn’t need
This is the trade-off I keep having to explain to customers, now with numbers: a harness won't make a frontier model better, but it can make a cheaper model dependable enough for production, and that's often the better deal.
Summary in Issue #2Building agentsChoosing models
Any of these could happen in a customer deployment that gives an agent a browser or a fetch tool. It reads as a concrete threat list for scoping tools, spelling out what's out of bounds, and monitoring what agents actually do instead of trusting the prompt.
Summary in Issue #2Markets & safe useBuilding agents
Advice I now give in every agent deployment: set hard spending limits from day one. This is the short, persuasive version to share with a customer.
Summary in Issue #1Building agentsAdvising
A new revenue model for anyone building an AI business: an API, MCP tool or dataset can charge agents per request instead of selling subscriptions. Worth understanding before pricing a product that agents will use.
Summary in Issue #1AI businessAI ecosystem
200,000+ agent requests to one U.S. Department of Education site in a single day
An outside view of the behavior in Issue #1's Anthropic report, from the receiving end. It's a reminder that an agent's web traffic is something you're accountable for, and that benchmark tasks can be enough to trigger it.
Summary in Issue #1Markets & safe useAdvising
61% of preference pairs where the agent’s ranking matched its person’s
Setups where several agents act for different parties are starting to come up with customers. Two findings I'll reuse: capturing what the person actually wants is the bottleneck, not the negotiation, and the choice of model matters more than prompt tweaks.
Summary in Issue #1AI businessBuilding agents
−60% tool-description tokens from loading most tools on demand
Most agent harnesses I review carry the same bloat: system prompts written for older models and every tool definition sent on every turn. This shows how to cut both, and how to check with real traffic that quality held.
Summary in Issue #1Building agents
Long-term memory is where agent privacy gets hard. This is a concrete reference architecture (keys held on the device, secure enclaves, verifiable server builds) for customers who want memory but can't put personal data in an ordinary backend.
Summary in Issue #1Building agentsMarkets & safe use
$0.10 per million input tokens for GPT-6 Luna
Model prices decide what's viable to build and what I recommend to customers. For agents, the cut in cached-input prices matters more than the headline rate, since long agent sessions are mostly cached tokens.
Summary in Issue #1AI ecosystemChoosing models
A measured, data-backed answer to the question every customer asks about coding agents: will this make our systems worse? The metrics are worth borrowing too: incident attribution, rework rate rather than raw churn, and the mix of work in merged PRs.
Summary in Issue #1AdvisingBuilding agents
Every agent project accumulates instructions that newer models no longer need. A good prompt for a periodic cleanup, including of the AGENTS.md files I write for customers (and for this site).
Summary in Issue #1Building agentsChoosing models
Something I can put in front of executives who ask what AI means for their workforce: it turns a vague debate into explicit assumptions they can change and compare.
Summary in Issue #1Markets & safe useAdvising
Legacy modernization is one of the most common agent projects customers ask for. The order of work here, with a verification harness first, then documentation, then migration with human review points, is a good template.
Summary in Issue #1Building agentsAdvising
No posts match. Try fewer words or another filter.
