Latest
The complete chronological feed across writing, projects, talks, and judging. Most recent first.
104 entries
Why agent reliability lives in the scaffolding, not the model.
When an agent works in production, we credit the model. When it fails, the cause is almost always in the harness around it: the loop, the tools, the context, the guardrails, the checks. The harness is the part you actually own.
AI Engineer World's Fair 2026 talk: your coding agent is creating review debt, the accumulating gap between the code an agent produces and the code humans have actually reviewed, trusted, and understood. Five signal families and ten deterministic checks turn that gap into a single defensible score, validated across 524 real pull requests.
Four spec revisions, an official registry, the Linux Foundation, and the ecosystem that adopted it.
The closing piece of the MCP series: the four revisions that shaped the protocol through its first year and a half, the official registry and MCP Apps, the move to the Linux Foundation and open governance, how it went from one release to an industry standard, and where the 2026 roadmap points.
The model writes the code; the harness makes it correct by running it.
A coding agent that only writes code is a fancy autocomplete. The thing that turns a plausible diff into a change you can merge is the code harness: the sandbox, the tools, and the loop that runs the code and reads the real errors.
Agents are in production and doing privileged things, but the guardrails did not arrive with them. This PlatformCon talk lays out a Java and Spring Boot pattern that makes an agent quote a versioned tool contract before any tool runs, with a gateway that validates, governs, and audits every call.
A three-layer evaluation framework in Java + LangChain4j for AI-agent trust testing: policy compliance, judge-based answer safety, and tool-trajectory validation, wired into CI as a build-time gate.
Judged Day-Zero: Agents in the Wild, an adversarial agent field test presented by Efficient Frontier Labs (Oakland, CA).
OAuth 2.1, the resource-server model, RFC 8707, and the threats the protocol cannot solve for you.
The security axis of MCP: how authorization works on the HTTP transport with OAuth 2.1, the server-as-resource-server model and RFC 8707 resource indicators, the later OIDC discovery and incremental-consent refinements, and the three threat classes, token passthrough, confused deputy, and prompt injection via tool output, with the guard for each.
The control loop is where you design termination, budgets, and recovery.
When an agent misbehaves, the loop is usually the culprit, not the model. Loop engineering is the deliberate design of when to keep going, when to stop, and what to do when a step fails.
Once messages can be retried, a new problem appears: a payment could be charged twice, or lost entirely. This piece is about the three promises a messaging system can make (at-most-once, at-least-once, exactly-once), why exactly-once is really achieved by making the work idempotent, and why order matters. It closes the messaging arc.
A from-the-ground-up look at delivery guarantees, the last piece of the messaging arc. The three promises a system can make: at-most-once (a message may be lost but never duplicated), at-least-once (never lost but may arrive more than once), and exactly-once (once and only once). Why real systems run at-least-once and reach exactly-once in practice by making each operation idempotent, so a retried request has no extra effect, the way a Stripe idempotency key prevents a double charge. Why ordering matters, and what Amazon SQS standard and FIFO queues, Apache Kafka, and application-level idempotency keys actually guarantee. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
