Agentic AI · Guardrails · Evaluation

Systems that act, and the evidence they leave behind

The largest body of work on this site. Agents that plan, call tools and change things are not chatbots with extra steps — they fail differently, they cost differently, and they need evidence a human can audit after the fact. What follows is what building and breaking them actually taught.

Agentic Architecture Tool Use Guardrails Evaluations That Bite Drift Detection Memory & Retrieval Local-First Auditable by Construction

An agent is not judged by what it can do — it is judged by what it did, and whether you can prove it.

Every demo works. The interesting question starts afterwards: what happened when the tool call failed, what the agent did with a stale document, who approved the write, and what the run cost. The writing here treats an agent as a system with a ledger rather than a model with a prompt — because that is the difference between something you can ship into a regulated environment and something you can only show people.

The frame

Four things an agentic system owes you

Read the stack →

Intent

What was the agent asked to do, in words that survive being read back a month later? An instruction nobody can reconstruct is not a specification.

Action

What did it actually call, with what arguments, and what came back? The gap between intended and performed is where every interesting failure lives.

Evidence

Can somebody who was not there reconstruct the run? Logs that record success are decoration; logs that record the decision are evidence.

Reversal

What happens when it is wrong — approval gates, dry runs, and an undo that was designed rather than discovered during the incident.

Flagships

The stack, and the role that owns it

Series · Architecture · Reference

The 9-Layer Agentic AI Stack

How production agentic systems are actually assembled, layer by layer, with what each layer is responsible for and what breaks when it is skipped. The opening part of the Playbook, written for people building rather than evaluating.

ArchitecturePlaybookSER-AGT-001
Study · Org Design · Reference

The Case for an AI Resident

A role that did not exist until the work demanded it: someone who lives inside the system, keeps its memory, and is accountable for what it does. An argument about org design first and tooling second.

Org designOperating modelWPR-MAX-012

Why it fits

Why this is the biggest grouping here

Built, not surveyed

MAX3, REEF and FeedHacker are running systems, and most of this writing is a post-mortem of something that happened in one of them rather than a reading of somebody else's paper.

The failures are the content

A guardrail that never fired proves nothing. The pieces that matter here are the ones where something got through — and what was changed so it could not happen twice.

Evaluation over demonstration

An agent that passes a demo and fails an evaluation is the normal case. The writing keeps returning to evaluations that can actually fail, because those are the only ones worth running.

Regulated by default

These systems were built where PHI and PII are present, so local-first, approval-gated and auditable are not features added late — they are the starting constraints.

Field notes

Agentic AI writing

See all →

Engage

Building one, or trying to trust one somebody else built?

Architecture review, an evaluation that actually bites, a second opinion on an agentic design, or help getting one through a compliance conversation.

This site: HTTPS only · no third-party trackers · no analytics cookies · security.txt

Follow the collective

New research, projects and field notes as they publish. Following happens on LinkedIn — we never see an address, and there is nothing to unsubscribe from.

Or get it by email

An occasional summary of new research, each with a link to the full piece.