A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. This closing post covers red-teaming your own system, operating it in production, and the honest state of the art.
A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. Red-teaming, production monitoring, and the honest state of the art.
"Guardrails" is the umbrella term for the runtime checks that sit around a model and screen what goes in and comes out — content classifiers, moderation models, topic and format validators, PII detectors. They're a real and useful layer, distinct from the architectural defenses, and they come with their own design rules: layer them, fail safe, and never mistake them for a wall.
"Guardrails" is the umbrella term for the runtime checks around a model — content classifiers, moderation models, topic and format validators, PII detectors. They're a real and useful layer, distinct from architectural defenses, with their own design rules: layer them, fail safe, and never mistake them for a wall. This post covers building the layered defense in practice.
Injection defense usually focuses on what goes into the model. But an equally dangerous class of bug lives on the way out: whatever the model produces gets passed to another system — a browser, a shell, a database, another service — that trusts it. If the model can be made to emit a malicious payload, and your code renders or executes it, the injection escapes the model and lands in your infrastructure.
Injection defense usually focuses on what goes into the model, but an equally dangerous class of bug lives on the way out: whatever the model produces gets passed to another system that trusts it. If the model can be made to emit a malicious payload and your code renders or executes it, the injection escapes the model and lands in your infrastructure — XSS, SQLi, SSRF, exfiltration.
Everything before this post raised the probability barrier against injection. This post lowers the impact — and impact is what actually protects you. The load-bearing defense against prompt injection isn't a prompt or a filter; it's an architecture where a fully-hijacked model still can't do anything catastrophic, because it was never granted the power to.
Everything before this raised the probability barrier against injection; this post lowers the impact — and impact is what actually protects you. The load-bearing defense isn't a prompt or a filter but an architecture where a fully-hijacked model still can't do anything catastrophic: least privilege, the confused-deputy trap, human-in-the-loop, and the dual-LLM pattern.
Between filtering the input and re-architecting the system sits a tempting middle ground: make the prompt itself more resistant. Delimiters, spotlighting, instruction placement, and defensive system prompts all raise the cost of an attack. None of them close the hole — because they are all still text in the one channel the attacker also writes to — but used well they meaningfully shift the odds.
Between filtering input and re-architecting the system sits a tempting middle ground: make the prompt itself more resistant. Delimiters, spotlighting, instruction placement, and defensive system prompts all raise the cost of an attack — but none close the hole, because they're all still text in the one channel the attacker also writes to. The value is knowing exactly how much they buy.
The first instinct when facing prompt injection is to inspect the input and block the bad stuff. It's a reasonable layer — but a treacherous one, because it creates a feeling of safety far larger than the protection it provides. This post covers the input-side defenses that are genuinely worth having, and draws a hard line around what they can and cannot do.
The first instinct against injection is to inspect the input and block the bad stuff. It's a reasonable layer but a treacherous one — it creates a feeling of safety far larger than the protection it provides. This post covers the input defenses genuinely worth having, and draws a hard line around what they can't do (starting with: indirect injection bypasses them entirely).
You can't defend against what you can't categorize. Prompt-based attacks come in a few structurally distinct shapes — direct injection, indirect injection through content the model reads, and jailbreaks that target the model's safety training — and each demands a different defense. This post maps the attack surface so the rest of the series can defend it systematically.
You can't defend what you can't categorize. Prompt-based attacks come in structurally distinct shapes — direct injection, indirect injection through content the model reads, and jailbreaks targeting the model's safety training — and each demands a different defense. This post maps the attack surface so the rest of the series can defend it systematically.
Prompt injection is the defining security problem of LLM applications, and — unlike SQL injection, which it superficially resembles — it has no clean fix. The reason is structural: a language model reads instructions and data through the same channel, and cannot reliably tell which is which. This opening post explains why that makes injection fundamentally hard, and reframes the goal from "prevent it" to "contain the blast radius."
Prompt injection is the defining security problem of LLM applications, and unlike SQL injection it has no clean fix — because a model reads instructions and data through the same channel and can't reliably tell them apart. This opening post explains why that makes injection fundamentally hard, and reframes the goal from prevent to contain the blast radius.
A fine-tune that looks great on a handful of hand-picked prompts can be quietly broken — overfit to your training data, worse than the base model you started from, or catastrophically forgetful of skills it used to have. Without real evaluation you can't tell, and shipping a fine-tune you haven't measured is shipping a guess.
A fine-tune that looks great on a handful of prompts can be quietly broken — overfit, worse than the base model, or catastrophically forgetful. Without real evaluation you can't tell, and shipping a fine-tune you haven't measured is shipping a guess.
A compiled DSPy program is an artifact — you optimize it once, save it, and serve it — which turns the framework's compile step into an ordinary part of a build pipeline rather than something that runs on every request.
A compiled DSPy program is an artifact — optimize once, save, and serve — which turns compilation into a build step, and makes a model swap a recompile rather than a prompt rewrite.
The two systems everyone builds — retrieval-augmented generation and tool-using agents — are where DSPy's declarative approach pays off most, because they are exactly the multi-step pipelines whose prompts are hardest to tune by hand.
RAG and tool-using agents are where DSPy's declarative approach pays off most — they are exactly the multi-step pipelines whose prompts are hardest to tune by hand.
Everything in this series — the budget, the system prompt, retrieval, memory, tools, and compaction — comes together as a pipeline that assembles the right window on every single turn, deliberately rather than by accident.
The budget, system prompt, retrieval, memory, tools, and compaction come together as a pipeline that assembles the right window on every turn — deliberately rather than by accident.
Strands's agent loop is deliberately small: a prompt goes in, the model decides, tools run if needed, results feed back, and it repeats until the model is done. What makes it distinctive isn't the loop's shape — every agent has one — but that Strands exposes it plainly and lets the model drive it, with only three ingredients you provide.
Strands's agent loop is deliberately small: a prompt goes in, the model decides, tools run if needed, results feed back, and it repeats until the model is done. Three ingredients you provide, and a loop the model drives.
Model selection is the most commonly botched cost decision, because the intuitive answer — pick the cheaper model — is measured by the wrong number. The right number is cost per completed task, and by that measure the more capable model often wins. Paired with it is the least-known lever of all: auditing prompts written for an older model against your current one.
Model selection is the most commonly botched cost decision, because the intuitive answer — pick the cheaper model — is measured by the wrong number. The right number is cost per completed task, priced on the tail not the median.
A "chain" is just Runnables composed with LCEL — but the word names the central idea of LangChain: build applications by wiring small, standard components into pipelines rather than writing monolithic prompt-and-parse code. Thinking in chains is thinking in composable steps, which is what makes LangChain applications modular, testable, and maintainable.
A chain is just Runnables composed with LCEL — but the word names the central idea of LangChain: build applications by wiring small standard components into pipelines rather than writing monolithic prompt-and-parse code.
What if the optimizer's update step were not a numeric gradient but a paragraph of natural-language reflection? That is the bet behind reflective optimizers — and one of them rivals reinforcement learning while using a fraction of the rollouts.
What if the optimizer's update step were not a numeric gradient but a paragraph of natural-language reflection? That is the bet behind reflective optimizers — one of which rivals RL with a fraction of the rollouts.
This is the payoff of the whole framework: you hand an optimizer your program, your metric, and some examples, and it searches for the instructions and demonstrations that make the program measurably better — the prompts you never had to write.
The payoff of the framework: hand an optimizer your program, metric, and examples, and it searches for the instructions and demonstrations that make the program measurably better — the prompts you never had to write.
Some of the biggest cost decisions are architectural — whether to feed knowledge through retrieval or bake it into a model, whether to prompt a big model or fine-tune a small one, and whether to rent tokens or run your own — and each trade turns on your volume and your task.
Some of the biggest cost decisions are architectural — retrieval versus long context, prompting a big model versus fine-tuning a small one, and renting tokens versus self-hosting — each turning on your volume.
When context threatens to overflow, you compress it; and when you have a huge window to spend, you still should not fill it — because a long context is not used as well as a short, focused one.
When context threatens to overflow you compress it; and when you have a huge window you still should not fill it — because a long context is not used as well as a short, focused one.
An MCP server can run code and see context on the model's behalf, which makes it powerful and dangerous in equal measure — this is how to deploy one without handing attackers the keys.
An MCP server can run code and see context on the model's behalf. Authentication, prompt-injection and tool-poisoning risks, human-in-the-loop, sandboxing, and a production checklist.
The pipe operator that lets you write `prompt | model | parser` is not syntactic sugar — it's LangChain's core composition model, and everything you pipe together shares one standard interface that gives you streaming, batching, and async for free. Understanding Runnables and LCEL is understanding how LangChain applications are actually built.
The pipe operator that lets you write prompt | model | parser is not syntactic sugar — it's LangChain's core composition model, and everything you pipe together shares one interface that gives you streaming, batching, and async for free.
DSPy's optimizer improves whatever your metric rewards, which makes the metric the single most consequential thing you write — get it right and compilation makes your program better; get it wrong and it optimizes confidently toward the wrong target.
DSPy's optimizer improves whatever your metric rewards, which makes the metric the single most consequential thing you write — get it right and compilation makes your program better; get it wrong and it optimizes toward the wrong target.
AI systems add attack surface that traditional security does not cover — the model, its prompts, its retrieved context, and its tools are all attackable — and the only way to know you're defended is to threat-model the whole surface and prove it with red-teaming.
AI adds attack surface conventional security misses — model, prompts, retrieved context, and tools are all attackable. Phase 7: threat-model the whole surface and prove it with red-teaming.
Tool definitions and structured data quietly consume a large share of the context budget, and how you select, describe, and format them shapes both what fits and how well the model uses it.
Tool definitions and structured data quietly consume a large share of the context budget, and how you select, describe, and format them shapes both what fits and how well the model uses it.
Of every AI cost lever, one dominates the rest, and all the major vendors agree on it: prompt caching. On long prompts and agentic workloads the reported savings are the largest anywhere — because caching attacks the specific way agent costs explode. If you optimize one thing, optimize this.
Of every AI cost lever, one dominates and all the major vendors agree on it: prompt caching. On agentic workloads the reported savings are the largest anywhere — because caching attacks the specific way agent costs explode. If you optimize one thing, optimize this.
Every LangChain application, no matter how elaborate, is built from three humble pieces: a model you call, a prompt you send it, and a parser that turns its reply into something usable. Master these three and the rest of LangChain is just composing them — which is exactly what the framework is designed to let you do.
Every LangChain application, no matter how elaborate, is built from three humble pieces: a model you call, a prompt you send it, and a parser that turns its reply into something usable. Master these three and the rest is just composing them.
Borrow the oldest idea in optimization — mutate a population, select the fittest, repeat — and point it at prompts and agents, and you get a search that escapes local optima a gradient never could.
Borrow the oldest idea in optimization — mutate a population, select the fittest, repeat — point it at prompts and agents, and you get a search that escapes local optima a gradient never could.
Real tasks are pipelines, not single calls, and in DSPy you build them the way you build a neural network — subclass a base module, declare sub-modules, and wire them together in a forward method.
Real tasks are pipelines, not single calls. In DSPy you build them like a neural network — subclass a base module, declare sub-modules, and wire them together in a forward method.
The question this phase answers is simple and unforgiving — can you change the system without breaking it? — and the control you cannot skip is that no ungated change reaches users.
Can you change the system without breaking it? Phase 6: automated pipelines for code, models, and prompts, with eval gates, a registry, and automated rollback — no ungated change reaches users.
A large share of what an AI system processes is repeated — the same system prompt, the same documents, the same questions — and caching is how you stop paying full price for work you have already done.
A large share of what an AI system processes is repeated — the same system prompt, the same documents, the same questions. Caching is how you stop paying full price for work you have already done.
A conversation that never forgets eventually overflows, so managing what history an agent carries forward — and how it remembers across sessions — is one of the defining problems of context engineering.
A conversation that never forgets eventually overflows, so managing what history an agent carries forward — and how it remembers across sessions — is a defining problem of context engineering.
Everything in the series so far comes together here: a small but complete Model Context Protocol server, in Python, exposing a tool, a resource, and a prompt, runnable and testable in minutes.
Build a complete MCP server in Python with the official SDK — a notes service with a tool, a resource, and a prompt — and test it end to end with the MCP Inspector.
The most ambitious form of self-evolution stops tweaking one agent and starts searching a space of many, letting a meta-process discover agent designs no human wrote.
The most ambitious self-evolution searches a population of agent designs. Automated Design of Agentic Systems, evolutionary prompt search, debate, and self-play.
A CrewAI agent is defined less by code than by three sentences — its role, goal, and backstory — and getting those right is the highest-leverage thing you do, because they are the prompt that shapes everything the agent does.
A CrewAI agent is defined less by code than by three sentences — its role, goal, and backstory — and getting those right is the highest-leverage thing you do, because they are the prompt that shapes everything the agent does.
If a signature says what a step does, a module says how to get the model to do it — and because modules are parameterized, swapping one for another changes the reasoning strategy without touching your intent.
If a signature says what a step does, a module says how to get the model to do it — Predict, ChainOfThought, ReAct — and because modules are parameterized, swapping one changes the strategy without touching your intent.
Since you pay for every input token, the fastest way to cut the cost of a call without changing the model is to send fewer tokens — and most production prompts are carrying far more than they need.
Since you pay for every input token, the fastest way to cut the cost of a call without changing the model is to send fewer tokens — and most production prompts carry far more than they need.
Retrieval is how you put external, current knowledge into a model's window, and doing it well is a context-engineering problem — the goal is not the most documents, but the right ones.
Retrieval is how you put external, current knowledge into a model's window, and doing it well is a context-engineering problem — the goal is not the most documents, but the right ones.
Tools let a model act, but resources and prompts are how a Model Context Protocol server feeds it the right context and gives users repeatable ways to invoke it.
Beyond tools, MCP servers expose resources (read-only context by URI) and prompts (reusable templates). What each is for, how they appear on the wire, and how to choose.
Running an LLM is not one computation — it's two very different ones stitched together: a compute-heavy pass over your prompt, then a long, memory-bound slog generating one token at a time. Almost every serving optimization that follows makes sense only once you see that inference has these two phases with opposite bottlenecks.
Running an LLM is two very different computations stitched together: a compute-heavy pass over your prompt, then a long, memory-bound slog generating one token at a time. Almost every serving optimization makes sense only once you see these two phases.
The first wave of self-evolving agents tuned one agent's memory and prompts; the frontier stops tuning a fixed agent and starts searching the space of agent designs itself.
The first wave of self-evolving agents tuned one agent's memory and prompts; the frontier stops tuning a fixed agent and starts searching the space of agent designs itself.
A DSPy signature is the contract that says what goes in and what comes out of a step — and by declaring the transformation instead of writing the prompt, it becomes something the optimizer can improve.
A DSPy signature declares what goes in and what comes out of a step — and by declaring the transformation instead of writing the prompt, it becomes something the optimizer can improve.
The single biggest cost lever in most AI systems is not clever prompting — it is not using an expensive model for work a cheap one would do just as well.
The single biggest cost lever in most AI systems is not clever prompting — it is not using an expensive model for work a cheap one would do just as well. Right-sizing and routing models to tasks.
The system prompt is the one piece of context present on every single call, so how you structure its role, rules, and format is the highest-leverage writing in the whole system.
The system prompt is the one piece of context present on every call, so how you structure its role, rules, and format is the highest-leverage writing in the whole system.
Hand-tuned prompt strings are brittle, model-specific, and impossible to systematically improve — DSPy replaces them with declarative modules and an optimizer that writes the prompts for you.
Hand-tuned prompt strings are brittle, model-specific, and impossible to improve systematically. DSPy replaces them with declarative modules and an optimizer that writes the prompts for you.
Every token in the window costs money, adds latency, and competes for the model's attention, so the first skill of context engineering is treating context as a scarce budget to be spent deliberately.
Every token in the window costs money, adds latency, and competes for attention. The first skill of context engineering is treating context as a scarce budget to spend deliberately.
The prompt is the agent's program, so an agent that can rewrite its own prompts is an agent that can rewrite its own behavior — and there are now principled ways to make that search work.
The prompt is the agent's program. Self-Refine, DSPy, and Promptbreeder turn prompt engineering into an automated search the system runs on itself.
Turning red-team attacks into metrics you can act on and track over time — attack success rate, coverage, severity, and trend — plus the honest limits of what any of those numbers can tell you.
Turning attacks into metrics: attack success rate and why it's subtle, scoring success (rule/classifier/LLM-judge with its biases), coverage across the taxonomy, severity weighting, tracking trends per model/prompt version, and honest reporting of residual risk.
Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.
DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.
Prompt engineering was about wording a single instruction well; context engineering is the broader discipline of deciding everything a model sees at inference time — and for agents, it is the discipline that matters most.
Prompt engineering was about wording one instruction well; context engineering is the broader discipline of deciding everything a model sees at inference — and for agents it is the skill that matters most.
Scaling red-teaming beyond manual probing — the building blocks of an automated harness (seed library, mutation, orchestrator, scorer), LLM-driven adaptive attackers, the real tools by role (PyRIT, garak, promptfoo, Giskard), and wiring it all into CI as a repeatable gate.
Scaling red-teaming: the harness building blocks (attack seeds, mutation, orchestrator, scorer), adaptive LLM-driven attackers, the real tools by role (PyRIT, garak, promptfoo, Giskard), and integrating an automated red-team gate into CI.
The last post in the series: what changes when the LLM system you built across posts 1-14 has to run for real — reliability, security, cost, observability, evaluation gates, and versioning, from a Go engineer's seat, with code where it earns its place.
The capstone: running an LLM system in production from a Go engineer's seat — reliability (timeouts, retries, fallbacks), security (injection, least-privilege tools, secrets), cost and observability, CI eval gates, and versioning models and prompts.
A defender's tour of the attacks that target the model and its data — prompt and context extraction, training-data memorization, membership inference and model inversion, model stealing, poisoning and backdoors, and evasion — with what a red-teamer tests and what actually stops each one.
Attacks on the model and its data: system-prompt and training-data extraction, membership inference and model inversion, model stealing, and poisoning/backdoors — what to test and defend, and the honest risk difference between using hosted models and training your own.
Making an LLM system faster and cheaper without touching the weights — the levers an application engineer actually controls, from streaming and caching to token trimming, model routing, and Go's real superpower: concurrency with a rate limiter.
Make LLM systems faster and cheaper without retraining: TTFT vs throughput, exact and semantic response caching, prompt caching, token reduction, model routing and cascades, and Go concurrency with a worker pool and rate limiter.
The habits that made you good at prompting standard models can actively hurt you with reasoning models. "Let's think step by step" is redundant — even counterproductive — when the model already thinks natively. Few-shot examples can constrain reasoning that's better left free. The shift from standard to reasoning models isn't just picking a different model; it's unlearning some prompting reflexes and learning where deep thinking actually earns its cost.
The habits that made you good at prompting standard models can actively hurt you with reasoning models. 'Let's think step by step' is redundant when the model already thinks natively. The shift isn't just picking a different model — it's unlearning some prompting reflexes and learning where deep thinking earns its cost.
A defender's field guide to the injection and jailbreak techniques a red-teamer probes for — the taxonomy, why each one works, and how to turn it into a re-runnable test suite that maps every passed test to a concrete fix.
A deeper, test-focused look at injection and jailbreak families — direct vs indirect (the RAG/agent threat), role-play, obfuscation, many-shot, multi-turn, cross-lingual — plus a red-team methodology: build a probe suite, mutate, test input and retrieval paths, measure, re-test.
Part three of the AI Security Engineering series: protecting the data that flows through an LLM system — how sensitive information leaks out of prompts, logs, and retrieval, and the engineering controls (redaction, data minimization, per-user retrieval authz, residency choices) that actually stop it.
Protecting data in LLM systems: sensitive-information disclosure, PII in prompts and logs (your observability can be the leak), redaction with Presidio, data residency, and per-user access control on the retrieval layer so RAG doesn't leak across tenants.
Before you attack an AI system you need a map of it: the components an adversary can influence, the trust boundaries between them, and a taxonomy that sorts attacks by goal and stage so your red-teaming is systematic instead of a grab-bag of the attacks that happen to trend that week.
Mapping the AI attack surface so red-teaming is systematic: threat-modeling the components (model, prompts, training/RAG data, tools, guardrails) and an attack taxonomy by goal (integrity/availability/privacy/abuse) and stage (training vs inference), aligned to NIST AI 100-2 and ATLAS.
The evidence layer of AI governance — how model cards, datasheets, system cards, and automated FactSheets turn "trust us" into an auditable paper trail, and why the EU AI Act makes these artifacts the actual deliverable.
The transparency artifacts that make AI governable: model cards, datasheets, and system/use-case documentation — plus a Python snippet that auto-captures lineage (model version, prompt hash, dataset version, eval scores, git SHA) into a card at build time, so docs are generated not hand-maintained.
Why the #1 risk on the OWASP LLM Top 10 has no clean fix — the model can't tell your instructions apart from the text it reads — and the defense-in-depth pattern that actually shrinks the blast radius.
The #1 LLM risk: direct vs indirect prompt injection (the latter is the real threat for RAG and agents), jailbreak families, and honestly-rated defense-in-depth — delimiting untrusted data, least-privilege tools, human-in-the-loop, and detection's limits.
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
The opening post of a hands-on series for builders: what it means to systematically stress-test an AI system — model, prompts, retrieval, tools, and guardrails — to surface its failures before adversaries or ordinary users do, how that differs from pentesting and robustness testing, and the frameworks and ethics that keep the work rigorous.
The opener to a defensive AI red-teaming series: stress-testing AI systems (models + prompts + RAG + tools + guardrails) to find failures before adversaries do — how it differs from pentesting, the frameworks (OWASP GenAI, MITRE ATLAS, NIST AI 100-2), and ethical rules of engagement.
Wire the embedding client, vector store, and chat client from the last five posts into one working RAG pipeline in Go — ingest and chunk documents, retrieve the top matches for a question, inject them as grounded context, and generate a cited answer, all from scratch.
Assemble embeddings and vector search into a working RAG pipeline in Go: chunk documents, embed and store them, retrieve the top-k for a query, augment the prompt with grounded context (and cite sources), then generate — a baseline end-to-end Answer() built from scratch.
The observation that launched reasoning models was almost embarrassingly simple: if you ask a language model to "think step by step" before answering, it gets dramatically better at hard problems — with no change to the model at all. That a few words of prompting could unlock reasoning already latent in the model was a clue about something deep: the ability to reason was there, waiting to be elicited, and giving the model room to work was the key.
The observation that launched reasoning models was almost embarrassingly simple: ask a model to 'think step by step' and it gets dramatically better at hard problems, with no change to the model. That a few words could unlock latent reasoning was a clue about something deep.
Treating the prompt as a real engineering artifact — grounded in how a next-token predictor actually works — with roles, specificity, few-shot examples, decomposition, chain-of-thought, grounding, temperature, injection defense, and versioned Go templates you can test.
Prompt engineering as a real engineering discipline: roles, specificity, few-shot, decomposition, chain-of-thought and its cost, grounding, and prompt injection — plus building prompts as versioned, testable Go text/template templates you treat like code.
Prompt injection can hijack what a model says, but not what it's allowed to do — as long as policy lives in a middleware pipeline the model never sees.
A system prompt saying never delete records is a suggestion the model can be talked out of. A gateway that returns FORBID for the delete tool cannot. Put enforcement where the model can't reach it and prompt injection stops mattering for access control.
How caching a large, stable prompt prefix cuts latency and cost — and the ADK config that decides when it pays off.
Context caching cuts latency and cost by caching large, stable context — system prompt, reference docs, tool definitions — so repeated calls don't re-send and re-process the same tokens.
Lesson 1 of Harness Engineering in Go — why the input guardrail is a hard block, not a warning, and how a plain `net/http` handler wraps the model call so it tests without a running server.
Lesson 1: why the input guardrail is a hard block rather than flag-and-pass, why it counts runes instead of bytes, and how a plain net/http handler wraps the (stubbed) model call so it tests with httptest.
Post 23 of 26 in "Google ADK, Concept by Concept" — how a planner turns one-shot answers into inspectable plan-then-act reasoning.
Structuring an agent's reasoning: planners that make the model plan-then-act (ReAct-style), the built-in thinking feature, and how a planner improves multi-step tool use over naive prompting.
Turn agent runs into OpenTelemetry spans, block prompt injection with information-flow control, and swap model providers behind one Agent API.
Turn Microsoft Agent Framework agent runs into OpenTelemetry spans, block prompt injection with information-flow control, and swap model providers behind one Agent API.
Single-turn evals check one decision. Multi-turn evals check the whole trajectory. A Python harness with three evaluators, an offline test suite, and the judge prompt that actually works.
How an agent.Session carries conversation history so a second prompt can refer back to the first.
A client-side agent.Session carries conversation history so a second prompt can refer back to the first. Create it with CreateSession, thread it with WithSession.
How one message can bundle a text prompt and an image, and why that forces RunMessage instead of the RunText shortcut.
Bundle a TextContent prompt and a base64 DataContent image into one message.Message and run it with RunMessage instead of the text-only RunText shortcut.
How an agent.Session carries conversation history across RunText calls so the model remembers earlier turns.
Thread conversation history across RunText calls with an agent.Session and agent.WithSession, so a follow-up prompt builds on the previous turn; a new session starts fresh.
Go's embed.FS bundles files into the binary at compile time. The pattern collapses what would be a multi-artefact deploy into one binary. Three places it pays back daily.