1046 posts · Page 11 of 88. ← Blog
In an event-driven system your events are a public API that outlives every service that reads them, so how you shape them and how you evolve them without breaking consumers is not a detail — it is the contract the whole architecture rests on.
In an event-driven system your events are a public API that outlives every service that reads them, so how you shape and evolve them without breaking consumers is the contract the whole architecture rests on.
The deepest form of self-evolution is recursive: not an agent that improves its answers, but an agent that improves the process that improves agents — a system reaching up a level to modify itself.
The deepest form of self-evolution is recursive: not an agent that improves its answers, but an agent that improves the process that improves agents — a system reaching up a level to modify itself.
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.
Responsible-AI principles written in a policy do nothing; the work of this phase is turning fairness, transparency, explainability, and human oversight into features the running system actually has.
Responsible-AI principles in a policy do nothing; this phase turns fairness, transparency, explainability, and human oversight into features the running system actually has. Phase 9.
Every agentic technique in this series adds cost and complexity, so the only way to know any of it is worth it is to measure — and RAG needs measurement on two fronts at once: did it retrieve the right things, and did it answer faithfully from them?
Every agentic technique adds cost, so the only way to know it is worth it is to measure — and RAG needs measurement on two fronts: did it retrieve the right things, and did it answer faithfully from them?
You cannot manage what you cannot see, and the difference between a team that controls its AI spend and one that is surprised by it is almost always whether they measure cost per feature, per user, and per call.
You cannot manage what you cannot see. The difference between a team that controls its AI spend and one surprised by it is whether they measure cost per feature, per user, and per call.
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.
The two protocols people keep pitting against each other are actually two halves of the same architecture — MCP gives an agent its tools, A2A gives it collaborators, and real systems need both.
MCP gives an agent its tools, A2A gives it collaborators, and real systems need both. How the two protocols compose — tools within an agent, agents between — in one architecture.
A benchmark score is trustworthy only if the model hasn't seen the answers and no one has optimized directly for the test. Both assumptions fail constantly. Training data contamination inflates scores by rewarding memorization; optimizing for a benchmark turns it from a measure into a target and destroys its meaning. This post is about the ways evaluation gets corrupted — and how to defend against them.
A benchmark score is trustworthy only if the model hasn't seen the answers and no one optimized directly for the test — and both assumptions fail constantly. Training-data contamination inflates scores by rewarding memorization; optimizing for a benchmark turns it from a measure into a target. Here's how evaluation gets corrupted, and how to defend it.
The primitives in this series are unbreakable in practice — and yet crypto keeps failing in the real world. That's the paradox of applied cryptography: almost every vulnerability is a misuse of a sound primitive, not a broken one. A predictable random number, a comparison that returns early, a reused nonce, a missing authentication check — each is a one-line mistake that silently voids the guarantee. This closing post catalogs the pitfalls that matter and distills the whole series into a decision guide.
The primitives are unbreakable in practice, yet crypto keeps failing — because almost every vulnerability is a misuse of a sound primitive, not a broken one. A predictable random number, an early-exit comparison, a reused nonce: one-line mistakes that silently void the guarantee. Plus a decision guide.
Kubernetes is famously complex, and most explanations start with its parts — pods, deployments, services — which is exactly backwards. Start with the problem: you have containers, you have many machines, and you need something to run the right containers on the right machines and keep them running as things fail. Kubernetes is a control loop for that, and once you see it that way, the complexity becomes comprehensible.
Kubernetes is famously complex, and most explanations start with its parts — which is backwards. Start with the problem: you have containers, many machines, and need something to run the right containers on the right machines and keep them running as things fail.
DevOps promised to tear down the wall between development and operations — and it worked, but it accidentally built a new problem: it made every developer responsible for a sprawling stack of infrastructure, pipelines, and tooling nobody has time to master. Platform engineering is the industry's answer: give developers a paved road instead of a pile of tools. Understanding that evolution is the key to the whole discipline.
DevOps tore down the wall between dev and ops — and accidentally built a new problem: it made every developer responsible for a sprawling stack nobody has time to master. Platform engineering is the answer: give developers a paved road instead of a pile of tools.