标签：#LLM

Introduction https://pg-blogs.netlify.app/posts/10-building-reliable-llm-apps-in-python/ closed with a section on picking the right model per task and caching a shared prefix. That was the entry point into a bigger discipline: LLM spend is an engineering variable, not a fixed bill — one you can measure and reduce with the same rigor you'd apply to query latency or memory footprint. This post goes deeper on four levers: how input/output pricing actually works and why the prefix is usually where the money goes, the exact cache_control shape and how to prove a cache hit instead of assuming one, the Batches API for work that isn't latency-sensitive, and model routing — a cheap model triaging requests and escalating only the hard ones. The throughline is honest: measure before you optimize. Every lever here has its own cost; misapplied, it makes things slower or pricier, not cheaper. Token Economics: Why the Prefix Is the Bill LLM providers price input and output tokens separately, and output always costs more — generation is autoregressive (each token depends on every one before it), while input can be processed in parallel. Representative pricing from the current model catalog: Model Input Output Claude Opus 4.8 $5.00 / MTok $25.00 / MTok Claude Sonnet 5 $3.00 / MTok $15.00 / MTok Claude Haiku 4.5 $1.00 / MTok $5.00 / MTok Two things follow: A long system prompt, tool list, or RAG context is billed as input on every request , not written once. Send a 20K-token system prompt on 10,000 requests and that's 200M input tokens — at Opus 4.8 rates, $1,000 before the model has generated a single output token. The shared prefix , not the user's actual question, is usually the dominant cost. Verbose output costs twice — once directly (more output tokens billed at the higher rate), and again because the next turn's history carries that verbosity forward as input. Asking for concise output and setting a sane max_tokens is a cost control, not just a style choice. This is why the tw

Introduction Building Reliable LLM Applications in Python put it plainly: treat model output as a hypothesis to verify, not a fact to trust. Testing Best Practices in Python put the same discipline in pytest terms: a suite only earns trust by asserting the right things at the right level, unhappy paths included. This post is where those two ideas meet — a pytest assertion either passes or fails against a fixed expected value; an LLM's output is a paragraph of prose that might be right in spirit while differing token-for-token from anything you wrote down in advance. Evaluating it takes a harness, not an assert . That harness has three parts: a golden dataset of representative cases with known-good expected behavior, scoring that turns each case into a pass/fail or a number, and regression testing that runs the harness on every change and fails the build when the score drops. Making RAG Accurate in Python already gave you half of this story — recall@k, precision@k, MRR, nDCG measure whether retrieval found the right chunks. This post measures the other half: whether the generated answer built from those chunks is actually good, which is a genuinely different question a retrieval metric can't answer on its own. Everything below is illustrative, non-executed Python, grounded in the same Anthropic SDK shapes as posts 10/11. The Golden Dataset: Curating Cases, Not Just Inputs A golden dataset is a small, hand-curated set of (input, expected behavior) pairs that represents the ways your application is actually used — not a random sample, and not just the cases that already work. Each case needs enough structure to be scored automatically later: from dataclasses import dataclass , field @dataclass class EvalCase : id : str category : str # "extraction", "qa", "summarization", ... input : str # the prompt/question sent to the system under test expected_exact : str | None = None # non-None only for cases scorable by exact match must_contain : list [ str ] = field ( default_f

Introduction Building Reliable LLM Applications in Java put it plainly: treat model output as a hypothesis to verify, not a fact to trust. Testing Best Practices in Java put the same discipline in JUnit terms: a suite only earns trust by asserting the right things at the right level, unhappy paths included. This post is where those two ideas meet — a JUnit test either passes or fails against a fixed expected value; an LLM's output is a paragraph of prose that might be right in spirit while differing token-for-token from anything you wrote down in advance. Evaluating it takes a harness, not an assertEquals . That harness has three parts: a golden dataset of representative cases with known-good expected behavior, scoring that turns each case into a pass/fail or a number, and regression testing that runs the harness on every change and fails the build when the score drops. Making RAG Accurate in Java already gave you half of this story — recall@k, precision@k, MRR, nDCG measure whether retrieval found the right chunks. This post measures the other half: whether the generated answer built from those chunks is actually good, which is a genuinely different question a retrieval metric can't answer on its own. Everything below is illustrative, non-executed Java, grounded in the same Anthropic Java SDK shapes as posts 10/11. The Golden Dataset: Curating Cases, Not Just Inputs A golden dataset is a small, hand-curated set of (input, expected behavior) pairs that represents the ways your application is actually used — not a random sample, and not just the cases that already work. Each case needs enough structure to be scored automatically later: public record EvalCase ( String id , String category , // "extraction", "qa", "summarization", ... String input , // the prompt/question sent to the system under test String expectedExact , // non-null only for cases scorable by exact/programmatic match List < String > mustContain , // key facts a correct answer must mention (programma

Introduction Every agent needs tools, and every tool needs a way to reach the model. Building Agentic Workflows in Python built that connection by hand — a hand-written JSON schema, a loop that dispatches on block.name . LLM Frameworks vs. the Raw SDK in Python showed LangChain's @tool turning a plain function into that same schema via bind_tools . Both are still bespoke : the tool lives inside one process, wired to one agent, in one language. The Model Context Protocol (MCP) solves a different problem: it standardizes the wire format between an AI application and a tool server, so the server doesn't have to be rewritten per agent, per framework, or per language. This post covers what that buys you, builds a minimal MCP server and a client that consumes it — both on the official Python SDK — and gives an honest answer to when reaching for a protocol is worth it over a direct tool call. The Problem MCP Solves Without a shared protocol, every pairing of agent framework and tool needs its own glue code: a LangChain @tool wrapper, a hand-rolled schema for the raw SDK, a different wrapper again for whatever framework a teammate picks next — an integration per framework, per tool. That's an M×N problem. MCP flattens it to M+N. A server exposes tools, resources, and prompts once, over a standard JSON-RPC protocol. Any host application — Claude Code, Claude Desktop, VS Code, or your own agent — creates an MCP client that speaks that same protocol, regardless of which framework built the host. Write the server once; every MCP-aware host can use it without new integration code. The protocol itself is intentionally boring: JSON-RPC 2.0 messages for lifecycle negotiation, tool discovery, and tool execution. Discovery ( tools/list ) and execution ( tools/call ) are the two calls that matter for this post: // tools/list response (abbreviated) { "jsonrpc" : "2.0" , "id" : 2 , "result" : { "tools" : [ { "name" : "get_account_balance" , "description" : "Look up the balance for an ac

Introduction Every agent needs tools, and every tool needs a way to reach the model. Building Agentic Workflows in Java built that connection by hand — a hand-written Tool schema, a loop that dispatches on toolUse.name() . LLM Frameworks vs. the Raw SDK in Java showed LangChain4j and Spring AI turning an annotated Java method into that same schema via reflection. Both are still bespoke : the tool lives inside one process, wired to one agent, in one language. The Model Context Protocol (MCP) solves a different problem: it standardizes the wire format between an AI application and a tool server, so the server doesn't have to be rewritten per agent, per framework, or per language. This post covers what that buys you, builds a minimal MCP server and a client that consumes it — both on the official Java SDK — and gives an honest answer to when reaching for a protocol is worth it over a direct tool call. The Problem MCP Solves Without a shared protocol, every pairing of agent framework and tool needs its own glue code: a LangChain4j tool wrapper, a Spring AI @Tool method, a hand-rolled schema for the raw SDK — three integrations for one capability, repeated for every tool and every framework you add. That's an M×N integration problem. MCP flattens it to M+N. A server exposes tools, resources, and prompts once, over a standard JSON-RPC protocol. Any host application — Claude Code, Claude Desktop, VS Code, or your own agent — creates an MCP client that speaks that same protocol, regardless of which framework built the host. Write the server once; every MCP-aware host can use it without new integration code. The protocol itself is intentionally boring: JSON-RPC 2.0 messages for lifecycle negotiation, tool discovery, and tool execution. Discovery ( tools/list ) and execution ( tools/call ) are the two calls that matter for this post: // tools/list response (abbreviated) { "jsonrpc" : "2.0" , "id" : 2 , "result" : { "tools" : [ { "name" : "get_account_balance" , "description"

I'm probably not the only one who checks every few months whether a GPU alternative has finally shipped, mostly so I can cancel a few subscriptions. Nobody doubts it's physically possible or that people have tried. The real question is why it hasn't actually happened, and the answer is economic and structural, not technical. GPUs are not uniquely ideal. They're uniquely general LLM workloads are dense matmul, high parallelism, memory-bandwidth-bound compute. GPUs handle this well but weren't built for it specifically. An ASIC purpose-built for transformer inference should beat a GPU on perf-per-watt and perf-per-dollar, and in narrow slices, it already does: Groq's LPU beats GPUs on single-stream inference throughput for models that fit its architecture Cerebras' WSE cuts interconnect overhead by putting the whole model on one wafer Google TPUs have run production workloads for years and are now sold externally via GCP So specialized hardware can win, sometimes even in production. The real question isn't whether something can beat a GPU, it's why none of these have dented Nvidia's share. 1. The capital barrier Custom silicon needs hundreds of millions in NRE cost, access to TSMC's leading-edge nodes with multi-year allocation queues, and several iterations before a design is commercially viable. That caps the field to hyperscaler balance sheets or venture funding measured in billions. The barrier isn't just the chip either. CUDA, the surrounding tooling, and production pipelines took a decade of capital and engineering to mature, and matching that means rebuilding all of it, not swapping a part. That's a second capital sink on top of the silicon itself. There's also a timing risk specific to fixed-function silicon: if the underlying model architecture shifts significantly, an ASIC taped out for today's transformer variant can become dead weight, while a GPU just needs a software update to run whatever comes next reasonably well. That risk hasn't actually played out,

In-process cron ( node-cron , @nestjs/schedule , OS crontab) runs inside one Node process. That is fine for a single instance, but it does not survive restarts gracefully, deduplicate across replicas, or share infrastructure with your other background jobs. BullMQ stores queues and schedulers in Redis . Job Schedulers (BullMQ 5.16+) are the recommended way to enqueue recurring work on a cron pattern or fixed interval. The same workers that process one-off jobs also process scheduled ones, with retries, backoff, and concurrency you already get from BullMQ. This post covers Job Schedulers in plain Node.js, operations and pitfalls, a NestJS setup with @nestjs/bullmq , and a runnable demo with a fast cron heartbeat and a daily cleanup cron. Prerequisites Node.js version 26 Redis at redis://localhost:6379 (included in the demo docker-compose.yml , or use Postgres and Redis containers with Docker Compose ) npm i bullmq For the NestJS section: npm i @nestjs/bullmq bullmq BullMQ 2.0+ does not require a separate QueueScheduler instance. Use the Job Scheduler API ( upsertJobScheduler ), not the deprecated repeat option on queue.add() . Mental model Piece Role Queue Holds jobs waiting to run Worker Executes jobs Job Scheduler Factory that enqueues jobs on a schedule Scheduled job A job instance produced by a scheduler A scheduler id is stable across deploys. Calling upsertJobScheduler with the same id updates the schedule in place instead of creating duplicates. Queue and worker Share one Redis connection config between the queue and the worker: import { Queue , Worker } from ' bullmq ' ; const connection = { host : ' localhost ' , port : 6379 }; const queue = new Queue ( ' reports ' , { connection }); const worker = new Worker ( ' reports ' , async ( job ) => { console . log ( `[ ${ job . name } ]` , new Date (). toISOString (), job . data ); }, { connection }, ); worker . on ( ' failed ' , ( job , error ) => { console . error ( job ?. name , error . message ); }); Start the

Honestly it's not a new concept. this feature already existed in models before. problem was the models were just weak. Looping only works if each attempt gets the agent closer to the correct solution. Earlier models weren't consistent enough for that. They often misunderstood feedback, repeated the same mistakes, or got stuck in an infinite loop. Instead of improving with each iteration, they frequently failed to make meaningful progress, eventually consuming large numbers of tokens without solving the problem. The Context Window Limitation Earlier language models had much smaller context windows. As the agent went through more iterations, the conversation history and reasoning gradually filled the available context. Once the context window was exceeded, older messages had to be dropped or compressed into summaries. As a result, the agent could forget previous failed attempts, lose important clues or reasoning, and sometimes repeat the same mistakes it had already made. So what did modern models actually fix? Bigger context windows Models can now hold way more of the conversation/history without forgetting, so the agent doesn't need to spin up a fresh session every few iterations. it can just keep looping with the full history of what failed and why. modern models also got way more consistent earlier if you asked a model to fix the same bug 5 times you'd get 5 different half-baked answers, now it actually converges toward the real fix. and tool use got better too . Old models could write code but couldn't run it and read the actual error, now they call a test runner, see the real failure, and fix that exact thing which is literally what makes the "verify" step possible. And then there's inference it is simply the process of a model generating an answer. like when you type "write a java binary search," the model reads your prompt, thinks, and generates code that whole process is inference. every time the model generates text, that's one inference. now here's the thin

In Part 1 , we learned that building great AI applications isn't just about writing better prompts. It's about providing the right context . But that naturally leads to another question: How much context can an AI actually understand? If you've used ChatGPT, Claude, Gemini, Cursor or any AI coding assistant for a while, you've probably experienced something like this. 🤔 "Didn't I Already Tell You That?" Imagine you're debugging a production issue with an AI assistant. You start by explaining the architecture. Then you share the API flow. Then database schema. Then logs. Then stack traces. After 30 minutes of conversation, you ask: "So what's causing the bug?" Instead of giving the answer, the AI responds: "Could you share your database schema?" You stare at the screen. "I already did..." Sometimes it even forgets details from earlier in the same conversation. Naturally, people assume: The AI has bad memory. The model is unreliable. The conversation is broken. In reality, something completely different is happening. You're running into one of the most important concepts in modern AI systems: The Context Window. Understanding this concept changes how you interact with AI—and more importantly, how you build AI-powered applications. 🧠 Before We Talk About Context Windows… We first need to understand something much smaller. Tokens. Almost every AI provider mentions them. Pricing is based on them. Context windows are measured using them. Yet many developers still think: 1 token = 1 word That isn't true. 🔤 What Exactly Is a Token? A token is the basic unit of text that an AI model processes. Humans naturally read text as: Characters Words Sentences Large Language Models don't. Before text reaches the model, it's converted into smaller pieces called tokens by a tokenizer. The model never sees your original sentence. It only sees a sequence of tokens. Think of a tokenizer as a translator between humans and AI. You write English ↓ Tokenizer ↓ Sequence of Tokens ↓ LLM The toke

Back when we introduced MCP support , we ended on a teaser: Phase 3 would tackle Sampling —letting servers request completions from the host instead of only exposing tools and resources to it. NodeLLM 1.17 delivers on that, and pairs it with a second, unrelated but overdue improvement: precise control over how tool calls execute, now available consistently in both core and the ORM persistence layer. 🔄 MCP Sampling: Closing the Loop Sampling inverts the usual MCP direction. Instead of the client asking the server for tools, the server asks the client to run an LLM completion on its behalf. This lets an MCP server offer LLM-powered capabilities—summarization, classification, drafting—without needing its own API key or provider integration. createLLMSamplingHandler answers those requests using a real NodeLLM instance, so a server's tool ends up powered by whatever model you configure client-side: import { createLLM } from " @node-llm/core " ; import { MCP , createLLMSamplingHandler } from " @node-llm/mcp " ; const llm = createLLM ({ provider : " openai " }); const mcp = await MCP . connect ( { command : " node " , args : [ " ./sampling-server.mjs " ] }, { sampling : createLLMSamplingHandler ( llm , " gpt-4o-mini " ) } ); const tools = await mcp . discoverTools (); // The server only advertises sampling-backed tools once it sees // the client declared sampling support during the handshake. If you need full control over how a sampling request is answered—routing by model hint, injecting your own guardrails—pass a plain handler function instead of { llm, model } . It receives the raw sampling/createMessage params and returns a CreateMessageResult , so you decide exactly how (or whether) to answer. ⚡ Concurrent Tool Execution When a model returns several independent tool calls in the same turn, NodeLLM has always executed them one at a time. That's safe by default, but wastes time when the calls don't depend on each other—three weather lookups for three different cities, s

Fable and Opus may not be the most comfortable tools for engineers who learned to code by hand. I started thinking about this after reading Simon Willison's recent note . His point is simple: with a strong coding agent like Fable, it may be better to let the model exercise its own judgment than to spell out every condition yourself. Instead of writing detailed rules like "run tests for larger features, but not for small copy changes, except for design changes...," you can simply say: write and run tests where appropriate. The same applies to cost. Rather than deciding manually which tasks should go to which model, you can ask the agent to choose an appropriate lower-cost model and delegate the work to a subagent. Manual cars and automatics This is a rough analogy, but it feels similar to driving a car. People who enjoy driving often like manual cars. They want to choose the gear themselves. They want to feel the engine speed and have the car respond directly to their intent. For people who simply want to get somewhere, an automatic is easier. Software engineers are similar. If you have written code professionally for a long time, you usually have your own way of working. You may want to get the types right first. You may prefer small diffs. You may have a specific sense for how granular tests should be. You may even have an order in which you like to read an unfamiliar codebase. (At least, I hope you do.) For someone with that kind of style, a highly autonomous model like Fable or Opus can feel a little too automatic. The stronger the model, the more small instructions get in the way This is the same structure as management in human organizations. A junior member needs concrete instructions: read this document from this angle and summarize it in this format. A senior member can take a rougher assignment: I want to solve this problem, so investigate it, come up with an implementation plan, and move it forward. Of course this does not mean throwing work over the wall.

What We Built in This Guide In the previous guide, we went from RAG to cloud deployment. In this guide, we systematically implemented everything needed to take that system to production . evals/ dataset.py # Evaluation dataset eval_rag.py # Context Recall · Relevancy · Faithfulness observability/ traced_rag.py # RAG pipeline tracing with @observe() (Langfuse v4) traced_agent.py # Trace each Agent step security/ input_validator.py # Prompt injection detection output_validator.py # PII masking and leakage detection guardrails.py # Rate limiting, security log integration secure_rag.py # RAG with guardrails llmops/ prompt_registry.py # Prompt version management (v1.0–v1.2) ci_eval.py # Quality gate (Overall ≥ 75% to deploy) cost_tracker.py # API cost tracking finetuning/ prepare_dataset.py # Convert to Alpaca format train_lora.py # LoRA fine-tuning (r=8, 2 min on CPU) inference.py # Compare with base model multiagent/ search_worker.py # Search specialist worker quality_worker.py # Quality check specialist worker orchestrator.py # Task decomposition and result integration 14_multiagent.py # Execution script governance/ ai_registry.py # AI system inventory risk_assessor.py # Risk assessment (score 0.18 → LOW) audit_logger.py # Audit log (Article 12 compliant) compliant_rag.py # RAG with AI disclosure (Article 50 compliant) Key Design Decisions from Each Chapter Chapter 2: Evals Combining rule-based (Context Recall, Answer Relevancy) with LLM-as-a-Judge (Faithfulness) strikes the right balance between speed, cost, and coverage. Chapter 3: Observability (Langfuse v4) Adding @observe() decorators is all it takes to start recording traces. The critical v4 change: you must call get_client() after load_dotenv() . Chapter 4: Security Defense in Depth is the principle: Input validation → System prompt → Output validation → Rate limiting — four layers of protection. Chapter 5: MLOps / LLMOps On every push to GitHub, Evals run automatically. Only when the quality threshold (Overall

Introduction Through Chapter 7 (Multi-Agent) , we have a complete, functioning AI system. The final step is building organizational infrastructure to operate AI safely over time. [Before] Technical safety Security → Block malicious input Evals → Measure quality [Now] Organizational / regulatory safety Governance → Know what AI systems are in use Risk mgmt → Classify and assess risks Audit logs → Record who did what, when EU AI Act → Regulatory compliance EU AI Act Status (as of June 2026) The EU AI Act came into force on August 1, 2024, with full enforcement on August 2, 2026 . Transparency rules (disclosing when users are interacting with AI, labeling AI-generated content) also take effect on that date. AI systems are classified into three risk tiers: Risk Level Description Examples Prohibited Not permitted Social scoring, manipulative AI High Risk Strict regulation Hiring, credit scoring, law enforcement Limited Risk Transparency obligations Chatbots, AI-generated content Minimal Risk No regulation Spam filters, game AI Our RAG system's classification: Limited Risk (chatbot). We are required to disclose to users that they are interacting with AI. Directory Structure pgvector-tutorial/ ├── existing files └── governance/ ├── ai_registry.py # ★ AI system inventory ├── risk_assessor.py # ★ Risk assessment ├── audit_logger.py # ★ Audit logging └── compliant_rag.py # ★ Governance-compliant RAG 1. AI System Inventory — governance/ai_registry.py Most organizations lack a systematic inventory of their AI systems, making risk classification and compliance planning difficult. Knowing what you have is the essential first step. # governance/ai_registry.py """ AI system inventory Centrally manage all AI systems in use across the organization. Forms the foundation for technical documentation required by EU AI Act Annex IV. """ from datetime import datetime from dataclasses import dataclass , asdict from enum import Enum class RiskLevel ( Enum ): UNACCEPTABLE = " prohibited " HIG

TL;DR— Most production AI teams build safety layers using the content-moderation mental model: classify input, classify output, block or pass. But the incidents that actually take down AI systems in production look like distributed-systems failures— retries amplifying bad state, cascading errors across agent steps, silent drift with no rollback path. Guardrails need to borrow from SRE, not from trust-and-safety. Ask a team how they handle AI safety in production and you'll get the same answer almost every time: an input classifier, an output classifier, maybe a moderation API bolted on the side. This is the content-moderation mental model— filter bad stuff in, filter bad stuff out. It's borrowed wholesale from trust-and-safety teams who spent a decade building spam filters and abuse detectors. It's also the wrong model for most of what actually breaks AI systems in production. The incidents that page you at 2am rarely look like a jailbreak slipping past a classifier. They look like distributed-systems failures: a retry loop that amplifies a bad tool call, a hallucinated intermediate result that poisons every downstream step, a silent shift in output distribution that nobody notices until a customer complains three weeks later. These are not content problems. They're systems problems, and they need systems solutions. The Cascade, Not the Jailbreak Consider a typical agent pipeline: retrieve context, call a model to plan, call tools, call a model again to synthesize, maybe loop if a tool fails. Each step has some non-zero error rate. In a single-call chatbot, that error rate is the whole risk surface. In a five-step agent chain, errors compound, and worse, they compound non-linearly because failed steps often trigger retries, and retries on a stateful action are not free. A model that hallucinates a tool argument doesn't just produce one bad output— it produces a bad state that the next step reasons over as if it were true. If that next step is another LLM call, it wi

Semantic coherence is not a quality metric or an alignment outcome. It is the structural condition that determines whether meaning remains stable, interpretable, and legitimate as the system accelerates. In the broader architecture of sovereign AI, semantic coherence is the component that ensures meaning does not fragment under pressure. Semantic coherence is the difference between a system that understands meaning and a system that merely produces plausible output. The Perception Semantic coherence is often treated as a linguistic property: clarity, consistency, interpretability, explainability, or “staying on topic.” In this perception, coherence is something evaluated externally — a measure of how well the system’s outputs align with human expectations. This view assumes coherence is a surface behaviour: does the output make sense does it follow logically does it stay within context does it appear consistent But this perception is fundamentally flawed. It treats coherence as an effect rather than a structural property. When coherence is treated as external, it becomes subjective, fragile, and easily destabilised by acceleration. The Reality Semantic coherence is not external to the system. Semantic coherence is the system. A system is coherent when its meaning remains stable across: acceleration optimisation pressure boundary transitions external inputs internal state changes If the architecture cannot maintain coherence internally, then: meaning fragments behaviour becomes inconsistent transitions lose legitimacy boundaries collapse under pressure governance becomes interpretive A system without semantic coherence does not understand meaning. It performs meaning. Semantic coherence is not about producing sensible output. It is about being structurally incapable of semantic drift. What Semantic Coherence Actually Is In sovereign AI, semantic coherence is the architectural logic that ensures: meaning remains stable under acceleration semantics remain consistent ac

Book: Observability for LLM Applications — Tracing, Evals, and Shipping AI You Can Trust Also by me: Agents in Production — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub Your triage agent has been in production for three months. The traces look clean. Every span is green, every run terminates, the p95 latency is flat, the token bill is boring. Then support forwards you a screenshot: the agent routed a billing refund to the security queue. You pull the trajectory. Nothing is broken. The agent called a reasonable tool with reasonable arguments, got a reasonable result, and picked the wrong queue with total confidence. That is silent drift. The trace shows you what the agent did. It does not tell you whether what it did was any good. Between a model provider's minor version bump, a prompt tweak someone shipped on Tuesday, and the slow shift in your incoming traffic, the quality of your agent's decisions moves. It rarely announces itself with an error. It shows up as a support ticket, then a second one, then a churned account. You catch it the same way you catch a memory leak: with a baseline and an alarm, not by staring at dashboards. Decision quality is a distribution, not a number The failing traces in Chapter 12 of Agents in Production are the easy case. Twenty retries of the same empty search is visibly wrong. You see the loop count in the invoke_agent parent and you know. Most quality regressions are not visible in a single trace. They show up only when you look at the distribution of decisions across thousands of runs. So the first thing to instrument is the decision itself. If you followed the tracing chapter you already emit a small fixed vocabulary per chat span: span . set_attribute ( " gen_ai.agent.step " , 3 ) span . set_attribute ( " gen_ai.agent.decision " , " call_tool " ) span . set_attribute ( " gen_ai.

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub In June 2025 two engineering teams posted opposite advice in the same week. Anthropic shipped How we built our multi-agent research system : an orchestrator dispatching subtasks to worker agents, beating a single agent by 90.2% on breadth-first research. A few days later Cognition, the team behind Devin, published Don't Build Multi-Agents , arguing that parallel subagents without shared context produce fragile systems. Both were right. They were describing different workloads. Anthropic's research agent is embarrassingly parallel: four workers go read four things and come back with four small summaries. Cognition's target is writing code, where every edit depends on every other edit and context cannot be sliced. Most people get the plumbing wrong, not the decision. Once you have two agents that need to coordinate, you have to choose how they talk. That choice decides your failure modes long before the models do. Handoffs vs a shared bus There are two ways to wire agents together, and they fail differently. A handoff transfers control. Agent A finishes, hands the whole conversation to Agent B, and steps out. This reads well in a demo. In production it means the transcript grows on every hop, and by the fourth agent you are paying to re-read a conversation nobody trimmed. Handoffs also lose the parent: once A hands off to B, nobody is holding the original task to check the final answer against it. A shared bus keeps a supervisor in charge. Workers never talk to each other. They receive a small typed task, do the work, and return a small typed artifact to the supervisor, which composes the result. This is the shape of Anthropic's research

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub The agent works on your laptop. It passes evals. Your manager asks when it ships and you say Monday, because the modeling is done. Then you try to put it behind a load balancer and it falls apart, because you deployed it like a web service. An agent is not a web service. A web service answers in milliseconds and forgets. An agent thinks for minutes, burns tokens across two or three providers, streams partial output to a browser, and sometimes decides to call delete_invoice on the eighth turn. Every deployment decision you make flows from one question: what does this thing do to your infrastructure while it is running? Here is how to package it, where to hold state, and how to scale a workload whose bottleneck is a model call you do not control. The shape is decided by the longest step The single rule that saves you the most pain: an agent's deployment shape is decided by its longest step, not its average step. A support chatbot answers in two seconds. A code-review agent thinks for six minutes. A research agent runs for forty. You cannot put all three behind the same HTTP endpoint and expect any of them to survive. Pick the pattern that matches the longest step, then cap the rest with timeouts. Under 30s → stateless HTTP endpoint (Cloud Run, Fly.io). 30s to 5m with a user watching → streaming over WebSocket or SSE. 5m to an hour, async → queue plus worker (Temporal, Inngest, or Redis). Longer than an hour → still queue plus worker, whether you like it or not. Do not hold an HTTP request open for forty minutes. Something you did not know existed will kill it at the worst moment: a proxy, a CDN, a load-balancer idle timeout. Package it: p

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub On April 2, 2026, Microsoft shipped agent-framework 1.0 and, in the same blog post, moved AutoGen into maintenance mode. Semantic Kernel went with it. Three overlapping projects folded into one package with stable APIs and long-term support. Microsoft framed the move as a consolidation. If you had an AutoGen project that morning, you woke up with a migration. That is the shape of this whole category. The framework landscape you pick from today is not the one you picked from a year ago, and it will not be the one you pick from next year. So the useful question is not "which framework is best." It is "which framework has which wedge, and which trade-off comes with it." Here is an honest read on six frameworks worth installing in 2026, and when to reach for each. The churn is the feature, not the bug Before the tour, one thing that changed the math: the wire formats underneath these SDKs converged. Every framework here speaks MCP for tools. Most support A2A for cross-framework handoffs. Model Context Protocol started as an Anthropic proposal at the start of 2025 and is now the default way agents pick up external tools. That convergence means the framework you pick locks you in less than it used to. You are still locked at the abstraction layer, though. Migrating a production system from CrewAI to Pydantic AI is a rewrite of every Agent definition and every tool decorator. The pick is sticky. Choose it with that in mind. LangGraph : durability as the wedge Reach for LangGraph when your agent has to survive a crash. It models the agent as a graph with checkpointers backed by Postgres or SQLite, so a workflow that dies at step seven resumes a

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You ship an agent that resolves billing disputes. It works in the demo. Two weeks later a support ticket lands: the agent tried to refund $4,000 on a $19 charge. You read the trace. The model returned a JSON blob, your code did json.loads , pulled amount , and passed it straight to the payments API. No cap. No type. No check. The model hallucinated a number and your code trusted it. The model is stochastic. Your code does not have to be. The gap between those two facts is where most production agent bugs live, and it is exactly the gap Pydantic AI is built to close. The wedge is types Most agent frameworks hand you an Agent object and a bag of strings. Pydantic AI hands you Agent[Deps, Output] — a generic parameterized by its dependency type and its output type. The IDE and your type checker read those parameters. So does the runtime. Install pulls in the framework plus an optional tracing extra: pip install "pydantic-ai[logfire]" The smallest program that earns its keep: from dataclasses import dataclass from pydantic import BaseModel from pydantic_ai import Agent , RunContext @dataclass class Deps : customer_name : str class SupportReply ( BaseModel ): reply : str escalate : bool agent = Agent ( " anthropic:claude-opus-4-8 " , deps_type = Deps , output_type = SupportReply , system_prompt = " You are a support agent. " , ) A tool is a plain function whose type hints become the schema the model sees, and the run returns the validated SupportReply : @agent.tool def customer_name ( ctx : RunContext [ Deps ]) -> str : return ctx . deps . customer_name result = agent . run_sync ( " What is my name? " , deps = Deps ( customer_name = " Ana "