Forem: Ken W Alger

Who Audits the Auditors? Building an LLM-as-a-Judge for Agentic Reliability

Ken W Alger — Thu, 16 Apr 2026 16:12:31 +0000

We’ve built a powerful Forensic Team. They can find books, analyze metadata, and spot discrepancies using MCP.

But in the enterprise, 'it seems to work' isn't a metric. If an agent misidentifies a $50,000 first edition, the liability is real.

Today, we move from Subjective Trust to Quantitative Reliability. We are building The Judge—a high-reasoning evaluator that audits our Forensic Team against a 'Golden Dataset' of ground-truth facts.

Before you Begin

Prerequisites: You should have an existing agentic workflow (see my MCP Forensic Series) and a high-reasoning model (Claude 3.5 Opus/GPT-4o) to act as the Judge.

1. The "Golden Dataset"

Before we can grade the agents, we need an Answer Key. We’re creating tests/golden_dataset.json. This file contains the "Ground Truth"—scenarios where we know there are errors.

Example Entry:

{
"test_id": "TC-001",
"input": "The Great Gatsby, 1925",
"expected_finding": "Page count mismatch: Observed 218, Standard 210",
"severity": "high"
}

Director's Note: In an enterprise setting, "Reliability" is the precursor to "Permission". You will not get the budget to scale agents until you can prove they won't hallucinate $50k errors. This framework provides the data you need for that internal sell.

2. The Judge's Rubric

A good Judge needs a rubric. We aren't just looking for "Yes/No." We want to grade on:

Precision: Did it find only the real errors?
Recall: Did it find all the real errors?
Reasoning: Did it explain why it flagged the record?

3. Refactoring for Resilience

Before building the Judge, we had to address a common "Senior-level" trap: hardcoding agent logic. Based on architectural reviews, we moved our system prompts from the Python client into a dedicated config/prompts.yaml.

This isn't just about clean code; it’s about Observability. By decoupling the "Instructions" from the "Execution," we can now A/B test different prompt versions against the Judge to see which one yields the highest accuracy for specific models.

4. The Implementation: The Evaluation Loop

We’ve added evaluator.py to the repo. It doesn't just run the agents; it monitors their "vital signs."

Error Transparency: We replaced "swallowed" exceptions with structured logging. If a provider fails, the system logs the incident for diagnosis instead of failing silently.
The Handshake: The loop runs the Forensic Team, collects their logs, and submits the whole package to a high-reasoning Judge Agent.

The Evaluator-Optimizer Blueprint

This diagram represents our move from "Does the code run?" to Does the intelligence meet the quality bar?" This closed-loop system is required before we can start the fiscal optimization of choosing smaller models to handle simpler tasks.

The Evaluator-Optimizer Loop-Moving from manual vibe-checks to automated, quantitative reliability scoring.

Director-Level Insight: The "Accuracy vs. Cost" Curve

As a Director, I don't just care about "cost per token." I care about Defensibility. If a forensic audit is challenged, I need to show a historical accuracy rating. By implementing this Evaluator, we move from "Vibe-checking" to a Quantitative Reliability Score. This allows us to set a "Minimum Quality Bar" for deployment. If a model update or a prompt change drops our accuracy by 2%, the Judge blocks the deployment.

The Production-Grade AI Series

Post 1: The Judge Agent — You are here
Post 2: The Accountant (Cognitive Budgeting & Model Routing) — Coming Soon
Post 3: The Guardian (Human-in-the-Loop Handshakes) — Coming Soon

Looking for the foundation? Check out my previous series: The Zero-Glue AI Mesh with MCP.

5.4-Cyber and the Death of the Static CI/CD Pipeline

Ken W Alger — Wed, 15 Apr 2026 17:17:27 +0000

Today’s announcement of OpenAI 5.4-Cyber isn’t just another incremental model update. It is the sounding of the death knell for the "Static" CI/CD pipeline. If you are still relying on a sequence of YAML-defined steps and basic SAST/DAST scans, your security posture just became an open door.

The End of Security Through Obscurity

The headline feature of 5.4-Cyber is its unprecedented capability in binary reverse engineering. Historically, compiled code offered a "speed bump" for attackers. By lowering the refusal boundaries for authorized defenders, OpenAI has effectively weaponized the defense. But there’s a catch: the delta between a patch and an exploit has now shrunk to near-zero.

Why "Shift Left" is No Longer Enough

We’ve been told to "shift left" for a decade. But 5.4-Cyber proves that static analysis is a knife in a gunfight. When an AI can deconstruct your build in seconds, you need more than a linter. You need Continuous Hardening.

"The 'Senior Developer' of 2026 isn't the one who writes the most secure code; it's the one who orchestrates the most aggressive AI red-teaming agent in their deployment pipeline."

Introducing Agentic Gatekeeping

The future isn't CI/CD; it’s AI/AD (Autonomous Defense). Your pipeline should no longer be a series of "if/then" statements. It must become a battleground. Every Pull Request should be met by an adversarial agent powered by models like 5.4-Cyber that actively attempts to exploit the new code before the 'Merge' button is even enabled.

The Trusted Access Paradox

OpenAI is gating these tools behind "Trusted Access for Cyber." While well-intentioned, this creates a Red Queen’s Race. As defenders get smarter AI, attackers will use leaked or uncensored "Shadow Models." If your pipeline doesn't evolve to be as dynamic as the threats, you're building on sand.

The Takeaway

Stop refining your YAML files. Start building Agentic Workflows. If your 2026 roadmap doesn’t include an autonomous red-team agent sitting inside your pipeline, you aren't doing DevSecOps—you're just waiting for a breach you can't predict.

The Backyard Quarry, Part 5: Digital Twins for Physical Objects

Ken W Alger — Tue, 14 Apr 2026 16:38:52 +0000

At this point in the Backyard Quarry project, something subtle has happened.

We started with a pile of rocks.

We now have:

a schema
a capture process
stored images
searchable metadata
classification
lifecycle states

Each rock has a record.

Each record represents something in the physical world.

And that leads to a useful observation.

We’re no longer just cataloging rocks.

We’re building digital representations of them.

What Is a Digital Twin?

In simple terms, a digital twin is:

A structured digital representation of a physical object.

That representation can include:

identity
properties
visual data
state
history

In the context of the Quarry, a rock’s digital twin might look like:

rock_id: QRY-042
weight_lb: 12.3
dimensions_cm: 18 x 10 x 7
color: gray
rock_type: granite
status: for_sale
images: [rock_042_1.jpg, rock_042_2.jpg]
model: rock_042.obj

It’s not the rock itself.

But it’s a useful abstraction of it.

More Than Just Metadata

At first glance, a digital twin might look like a simple database record.

But there’s an important difference.

A well-designed digital twin combines multiple types of data:

structured metadata (easy to query)
unstructured assets (images, models)
derived attributes (classification, embeddings)
state over time

It’s not just describing the object.

It’s enabling interaction with it through software.

The Time Dimension

One of the most important aspects of a digital twin is that it can change over time.

Even a rock — which is about as static as objects get — has a lifecycle in the system:

collected → cataloged → listed_for_sale → sold

Each transition adds context.

Now we’re not just storing a snapshot.

We’re tracking a history.

This becomes much more important in other domains.

Where This Shows Up

The interesting part is that this pattern isn’t unique to rocks.

It appears in many different systems.

Manufacturing

digital twins of machine parts
tracking condition and usage
linking physical components to system data

Museums and Archives

artifacts with metadata, images, provenance
digitized collections
searchable historical records

Agriculture

crops tracked over time
environmental data
growth and yield metrics

Healthcare and Motion

human movement captured as data
gait analysis
rehabilitation tracking

This last one starts to look a lot like something else entirely.

From Objects to Systems

What the Backyard Quarry demonstrates, in a small way, is that once you:

represent objects as data
capture their properties
store and index them

you’ve created the foundation for a larger system.

The digital twin becomes a building block.

And systems are built from collections of these building blocks.

The Abstraction Layer

A useful way to think about digital twins is as an abstraction layer.

They sit between:

Digital twins act as a bridge between physical objects and software systems.

Applications don’t interact with rocks directly.

They interact with the representation of rocks.

That layer enables:

search
analytics
visualization
automation

Without it, everything remains manual and unstructured.

The Limits of the Model

Of course, digital twins are not perfect representations.

They are approximations.

Some properties are easy to capture.

Others are difficult or impossible.

Even in the Quarry:

weight is approximate
dimensions are imprecise
visual data depends on lighting
3D models may be incomplete

The goal isn’t perfect fidelity.

It’s usefulness.

The Real Insight

At this point, the Backyard Quarry starts to feel less like a joke and more like a small version of a much larger idea.

Many modern systems are built around digital twins.

Not because the concept is new.

But because we now have the tools to make it practical:

cheap sensors
high-resolution cameras
scalable storage
machine learning

The pattern has existed for a long time.

The difference is that we can now implement it at scale.

What Comes Next

So far, the Quarry system works at a small scale.

A handful of rocks.

A manageable dataset.

But what happens when the number of objects grows?

When the dataset becomes:

hundreds
thousands
or millions

The next post explores that question.

Because designing a system for a small dataset is one thing.

Designing a system that scales is something else entirely.

And somewhere along the way, it becomes clear that a pile of rocks is enough to illustrate ideas that show up across entire industries.

Yet another surprise in this Backyard Quarry journey.

The Rock Quarry Series

The Backyard Quarry, Part 4: Searching a Pile of Rocks

Ken W Alger — Tue, 07 Apr 2026 16:25:39 +0000

By this point, the Backyard Quarry has a schema, a capture process, and a growing collection of records.

Each rock has:

metadata
images
possibly a 3D model

In theory, everything is organized.

In practice, it quickly becomes difficult to find anything.

The First Search Problem

With a handful of rocks, you can rely on memory.

You remember roughly where things are.

You recognize shapes and colors.

But as the dataset grows, that breaks down.

You start asking questions like:

Which rocks are under 5 pounds?
Which ones are suitable for landscaping?
Where did that smooth gray stone go?

At that point, you’re no longer dealing with a pile.

You’re dealing with a dataset.

And datasets need to be searchable.

Filtering by Metadata

The most straightforward approach is to use structured queries.

If we have metadata like weight, color, and classification, we can filter directly.

Conceptually:

SELECT *
FROM rocks
WHERE weight_lb < 5
AND color = 'gray'
AND rock_class <= 'Class 2'

This works well for clearly defined attributes.

It’s predictable.

It’s efficient.

And it’s the foundation of most data systems.

The Role of Classification

This is where the Quarry Taxonomy starts to pay off.

Instead of requiring precise measurements, we can use categories:

Pebble Class
Hand Sample
Landscaping Rock
Wheelbarrow Class
Engine Block Class

This allows for simpler queries:

“Show me everything below Wheelbarrow Class”
“Exclude Engine Block Class entirely”

Classification reduces complexity.

It turns continuous values into discrete groups.

This is a common pattern in real-world systems.

When Metadata Isn’t Enough

Structured queries work well when you know exactly what you’re looking for.

But sometimes you don’t.

Sometimes the question looks more like:

Find rocks that look like this one.

Or:

Find something similar to the smooth stone I saw earlier.

At that point, metadata alone isn’t enough.

We need another way to compare objects.

Similarity and Representation

Images and 3D models contain information that isn’t captured in simple fields like color or weight.

To use that information, we need to represent it in a comparable way.

One approach is to generate embeddings — numerical representations of images or shapes.

Conceptually:

each rock image → vector representation
similar images → vectors close together
dissimilar images → vectors further apart

This allows for similarity search.

Instead of filtering by attributes, we search by resemblance.

A Different Kind of Query

With similarity search, queries look different.

Instead of:

color = 'gray'
weight < 5

We might have:

find nearest neighbors to this image

This shifts the system from exact matching to approximate matching.

It’s less precise.

But often more useful.

A Familiar Pattern

At this point, the Backyard Quarry starts to resemble systems used in:

image search engines
product recommendation systems
digital asset management platforms
AI-powered retrieval systems

The objects are different.

The pattern is the same.

Store data.

Index it.

Provide multiple ways to retrieve it.

Combining Approaches

In practice, the most useful systems combine both methods.

Structured filtering:

weight
class
location

Similarity search:

appearance
shape
texture

Together, they provide flexibility.

You can narrow down the dataset and then explore it.

The Cost of Search

Search doesn’t come for free.

It introduces:

indexing overhead
additional storage
preprocessing steps
more complex queries

And like everything else in the Quarry system, these tradeoffs become more significant as the dataset grows.

The Realization

At this point, something interesting becomes clear.

The hard part isn’t collecting rocks.

It isn’t even modeling them.

The hard part is making the data usable.

And usability, in most systems, comes down to one thing:

Search.

What Comes Next

With data captured and searchable, the next step is to zoom out.

What we’ve built so far is more than just a rock catalog.

It’s a small example of a larger idea.

In the next post, we’ll look at that idea more directly:

Digital twins.

Because once you can represent, store, and search objects, you’ve taken the first step toward building systems that mirror the physical world.

And somewhere in the process, it becomes clear that even a pile of rocks benefits from thoughtful indexing.

Which is not something I expected to say when this started.

The Rock Quarry Series

Building Your First MCP Server: TypeScript vs. Python

Ken W Alger — Mon, 06 Apr 2026 21:11:14 +0000

The 5-Minute "Hello World" Comparison

We’ve spent the last month talking about the End of Glue Code and the Enterprise AI Mesh. But if you’re a developer, you don't just want to see the blueprint—you want to hold the tools.

Whether you are a TypeScript veteran or a Python enthusiast, building an MCP server is surprisingly simple. Today, we’re going to build the same "Hello World" tool in both languages to show you exactly how the protocol abstracts away the complexity.

1. The TypeScript Approach (Node.js)

TypeScript is the "native" language of the Model Context Protocol, and the @modelcontextprotocol/sdk is exceptionally robust for high-performance enterprise tools.

Prerequisites:

npm install @modelcontextprotocol/sdk zod

The Code:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new Server({
  name: "hello-world-server",
  version: "1.0.0",
}, {
  capabilities: { tools: {} }
});

// Define a simple greeting tool
server.tool(
  "greet_user",
  { name: z.string().describe("The name of the person to greet") },
  async ({ name }) => {
    return {
      content: [{ type: "text", text: `Hello, ${name}! Welcome to the MCP Mesh.` }]
    };
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch(console.error);

2. The Python Approach

For data scientists and AI engineers, the Python SDK offers a beautifully decorative approach. It feels more "agent-native" and integrates seamlessly with existing AI libraries.

Prerequisites:

pip install mcp

The Code:

import asyncio
from mcp.server.fastmcp import FastMCP

# Initialize FastMCP - the "Quick Start" wrapper
mcp = FastMCP("HelloWorld")

@mcp.tool()
async def greet_user(name: str) -> str:
    """Greets a user by name."""
    return f"Hello, {name}! Welcome to the MCP Mesh."

if __name__ == "__main__":
    mcp.run(transport='stdio')

Side-by-Side: Which Should You Choose?

Feature	TypeScript (Standard SDK)	Python (FastMCP)
Best For	High-performance, Type-safe tools	Rapid prototyping, AI logic
Validation	Zod (Explicit & Strict)	Pydantic / Type Hints (Implicit)
Verbosity	Moderate (Structured)	Minimal (Decorator-based)
Transport	STDIO, SSE, Custom	STDIO, SSE

How to Test Your Server

Once you've saved your code, you don't need a complex frontend to test it. Use the MCP Inspector:

# For TypeScript
npx @modelcontextprotocol/inspector node build/index.js

# For Python
npx @modelcontextprotocol/inspector python your_script.py

This will launch a local web interface where you can perform the "Protocol Handshake" and trigger your tools manually. It's the best way to verify your "Zero-Glue" infrastructure before connecting it to an agent.

Conclusion

The "Zero-Glue" architecture isn't about which language you use—it's about the Protocol. As you can see, the logic for the "Hello World" tool is nearly identical in both versions. The Model Context Protocol ensures that no matter how you build your tools, your agents can discover and use them in a standardized way.

Ready to build your own?

Check out the reference repo for more complex examples, including Notion and Oracle 26ai integrations.

MCP Forensic Analyzer Repository

The "Zero-Glue" Series

Post 1: The End of Glue Code: Why MCP is the USB-C Moment for AI
Post 2: The Forensic Team: Architecting Multi-Agent Handoffs
Post 3: From Cloud to Laptop: Running MCP Agents with SLMs
Post 4: Enterprise Governance: Scaling MCP with Oracle 26ai

What's Next?

The Mesh is built.
The agents are ready.
But can you trust them?

In my next series, we explore the 'Science of Reliability'—building the evaluators that turn AI experiments into production-grade systems.

The Final Boss: Enterprise Governance & Scalability

Ken W Alger — Thu, 02 Apr 2026 17:32:10 +0000

From Cloud to Core: Taking the Forensic Team to Production with Oracle 26ai

Over the last three posts, we’ve done the hard work. We designed a "Zero-Glue" architecture, orchestrated a polyglot multi-agent team, and proved it can run offline on a laptop.

But for a global enterprise, "it works on my machine" is where the trouble begins.

How do you ensure that a thousand agents, running a million audits against critical archival data, all adhere to the same security, privacy, and auditability standards?

Today, we meet the "Final Boss" of AI systems: Governance. We are taking our specialized forensic lab and moving it from a flexible Notion sandbox to the mission-critical, AI-native world of Oracle 26ai.

In 2026, the industry has moved toward HTAP+V (Hybrid Transactional/Analytical Processing + Vector). While Oracle 26ai is a leader in this "all-in-one" approach, many developers prefer a "best-of-breed" or open-source stack.

Governance Engine

To bridge the gap between a laptop demo and a global enterprise, we must move governance out of our Python scripts and into the data layer. In this article, we'll look at Oracle 26ai as a primary example of an AI-native database, but the principles of the 'AI Mesh' apply whether you are implementing this with:

PostgreSQL + pg_vector + pgai (Open Source)
Supabase + Edge Functions (Modern Cloud)
Snowflake + Cortex (Enterprise Data Cloud)
MongoDB Atlas + Microsoft Foundry (NoSQL/Vector Hybrid)

The Enterprise Gap

In a production environment, you can't rely on prompt-based guardrails or local JSON logs. Enterprise AI requires infrastructure-level guarantees. Our "Forensic Clean-Room" concept must scale from one laptop to a global, distributed network.

To bridge this gap, we must rethink three core architectural pillars:

Shift 1: The AI-Native Database (Oracle 26ai)

In our demo, we used a simple Notion API. In production, we need a unified knowledge base that treats agents as "first-class citizens."

Oracle 26ai Select AI Agents allows the database itself to host and govern MCP servers.

Instead of your Python orchestrator managing every single database call (which creates a new MXN integration point!), the orchestrator calls a single Unified AI Agent within Oracle. The database then securely manages the data access, vector similarity search, and even execution of in-database ML models.

Shift 2: Immutable Audits & Row-Level Security

Enterprise systems require strict, verifiable compliance. We must move beyond "trust" and enforce security at the data layer.

Virtual Private Database (VPD) & Row-Level Security (RLS)
You don’t have to "prompt" the AI to ignore certain restricted records. If a junior auditor runs your Python script, the database physically hides the rows they aren't authorized to see. The agent literally cannot see or hallucinate restricted data.

Blockchain Tables for Audits
Every decision made by the Librarian or the Analyst must be defensible. In 26ai, we can write the "handshake" between agents directly into a Blockchain Table. This creates an immutable, cryptographically signed record of exactly what data the agent saw and what reasoning it produced—a perfect, verifiable audit trail.

The Ultimate Vision: The Enterprise AI Mesh
When you move to an enterprise architecture powered by Oracle 26ai, your view of the AI stack fundamentally changes. MCP is no longer just a tool—it is the universal interface of the AI Mesh.

The Enterprise AI Mesh: specialized agents (Clients) connect to standardized, secured MCP Servers. The AI-Native Database acts as the governance layer and unified 'Source of Truth,' decouples tools from logic and enabling scalable machine-to-machine autonomy.

This diagram represents the maturity of your AI system.

The Clients (Agents): Focus purely on specialized reasoning.
The Interface (MCP): Provides a standardized, semantic way to discover capabilities.
The Governance (Database): Enforces security, privacy, and persistence for the entire mesh.

The "End of Glue Code" Is Just the Beginning

We’ve come full circle. The "Zero-Glue" architecture isn’t about deleting code; it’s about architecting systems where the logic and the capabilities are separated by a robust, standard protocol.

Whether you are building a small forensic auditor on your laptop or a global archival intelligence network, the principles of the Model Context Protocol remain the same.

Stop writing the glue. Start building the mesh.

The "Zero-Glue" Series

Post 1: The End of Glue Code: Why MCP is the USB-C Moment for AI
Post 2: The Forensic Team: Architecting Multi-Agent Handoffs
Post 3: From Cloud to Laptop: Running MCP Agents with SLMs
Post 4: Enterprise Governance: Scaling MCP with Oracle 26ai — You are here

The Backyard Quarry, Part 3: Capturing the Physical World

Ken W Alger — Tue, 31 Mar 2026 16:54:49 +0000

In the previous post, we designed a schema for representing rocks as structured data.

On paper, everything looked clean.

Each rock would have:

an identifier
dimensions
weight
metadata
possibly images or even a 3D model

The structure made sense.

The problem was getting the data.

From Schema to Reality

Designing a schema is straightforward.

You can sit down with a notebook or a whiteboard and define exactly what you want the system to store.

Capturing real-world data is a different problem entirely.

The moment you step outside, a few complications become obvious.

Lighting changes.

Objects aren’t uniform.

Measurements are approximate.

And perhaps most importantly:

The dataset doesn’t behave consistently.

The Scale Problem

The Backyard Quarry dataset spans a wide range of sizes:

pea-sized
hand-sized
wheelbarrow-sized
engine-block-sized

That variability immediately affects how data can be captured.

Small rocks can be photographed on a table.

Medium rocks might need to be placed on the ground with careful framing.

Large rocks don’t move easily at all.

Each category introduces different constraints.

This is a pattern that shows up in many real-world systems.

The same pipeline rarely works for every object.

Image Capture

The simplest form of data capture is photography.

Take a few images of each rock from different angles.

Store them.

Attach them to the record.

Even this introduces decisions:

how many images per object?
what angles?
what lighting conditions?
what background?

Inconsistent capture leads to inconsistent data.

And inconsistent data leads to unreliable systems.

Introducing Photogrammetry

If we take the idea a step further, we can generate a 3D model of each rock.

Photogrammetry works by combining multiple images to reconstruct the shape of an object.

Conceptually:

take overlapping photos
feed them into a processing tool
generate a 3D mesh

This produces a much richer representation than a single image.

But it also introduces:

processing time
storage requirements
failure cases

Not every rock will produce a clean model.

The Capture Pipeline

At this point, the process starts to look like a pipeline.

A simplified pipeline for turning a physical object into structured data and associated assets.

Each step transforms the data in some way.

The output of one stage becomes the input of the next.

This is a common pattern in data engineering.

The difference here is that the input isn’t a clean dataset.

It’s the physical world.

Imperfect Data

No matter how carefully you design the pipeline, real-world data introduces imperfections.

Examples:

missing images
inconsistent lighting
partially occluded objects
measurement errors

A rock might be:

too reflective
too uniform in texture
partially buried
awkwardly shaped

All of these affect the output.

This means the system has to tolerate incomplete or imperfect data.

Which leads to an important realization:

Data systems are rarely about perfect data. They are about handling imperfect data gracefully.

Storage Considerations

Once data is captured, it needs to be stored.

Different types of data behave differently:

metadata → small, structured, easy to query
images → larger, unstructured
3D models → even larger, more complex

This reinforces a pattern introduced earlier:

Separate structured data from large assets.

Store references rather than embedding everything directly.

A Familiar Pattern

At this point, the Backyard Quarry pipeline looks surprisingly familiar.

It resembles systems used for:

scanning historical artifacts
capturing industrial parts
generating 3D models for manufacturing
building datasets for computer vision

The specifics change.

The pattern remains the same.

What Comes Next

Once data is captured and stored, the next problem emerges.

How do we find anything?

A dataset of a few rocks is manageable.

A dataset of hundreds or thousands quickly becomes difficult to navigate without structure.

In the next post, we’ll look at how to index and search the dataset — and how even a pile of rocks benefits from thoughtful retrieval systems.

And somewhere along the way, it becomes clear that the hard part isn’t designing the schema.

It’s building systems that can reliably turn messy reality into usable data.

Miss Part of the Series?

The Ink, The Iron, and the Algorithm: Why I Build for Truth

Ken W Alger — Mon, 30 Mar 2026 16:11:16 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

In the world of rare and historical artifacts, the difference between a masterpiece and a clever forgery often hides in the smallest details. It could be a specific serif on a typeface, or a tooling mark on piece of stone. This type of knowledge historically is known only by a select few. Locked away in the knowledge banks of high-end auction houses and private archives.

As I worked on a recent Archival Intelligence project for the Notion MCP Challenge, I realized that my journey in tech has been leading me toward a vital mission: Democratizing the Truth.

From Commodore PETs to Forensic AI

My journey started with early Commodore PETs and VIC-20s. Yeah, I'm that old. Back then, "diversity" in tech was barely a conversation. Further, the "archives" of our digital world were in their infancy.

History, however, is fragile. It is frequently written by those with the most resources. The records of marginalized communities, those whose stories aren't backed by high-end auction houses, are often the first to be lost to the sands of time or forged for the sake of a more 'profitable' narrative. I build to ensure those stories have a forensic advocate.

Building the "Digital Magnifying Glass"

When I built the MCP Forensic Analyzer and looked at rare books, I wasn't just thinking about $150,000 first editions. I was thinking about governance.

Much has changed and advanced in the world of tech since the Commodore PET days. We now find ourselves in a world in which AI can be a powerful ally. It can also hallucinate and manipulate digital data in seconds. We need systems that act as a "Ground Truth" for AI.

By using the Model Context Protocol to link Notion databases into a forensic audit trail, I'm trying to solve a problem that is older than computers... How do we prove what is real?

Tech as an Equalizer

The #WeCoded mission resonates with me because inclusion isn't just about who is in the room.

It's about whose history we choose to protect.

How can we use tech to accomplish this?

By automating the "Chain of Custody": We can take the power of authentication out of the hands of the auction houses and private archivists and make the knowledge accessible via an open protocol.
AI integration: By making these tools available through simple chat interfaces, any small library, local museum, or interested individual can verify records and artifacts with the same rigor as top-tier institutions.

The Echoes of Our Experience

The code we write today becomes the archive of tomorrow.

My "Echo of Experience" is this:

Don't just build tools to make things faster; build tools to make the world more verifiable.

Whether it's a rare book, historical record, or antique stone artifact, the truth deserves a forensic advocate. I'm proud to be working on that advocacy. One line of code at a time.

From Cloud to Laptop: Running MCP Agents with Small Language Models

Ken W Alger — Sat, 28 Mar 2026 11:23:39 +0000

Large Models Build Systems. Small Models Run Them.

For most developers, modern AI systems feel locked behind massive infrastructure.

We’ve been conditioned to believe that “Intelligence” is a service we rent from a data center—a luxury that requires GPU clusters, $10,000 hardware, and ever-climbing cloud inference bills.

Last week, when we built our Multi-Agent Forensic Team, you likely assumed that coordinating a Supervisor, a Librarian, and an Analyst required the reasoning horsepower of a 400B+ parameter model.

Today, we’re cutting the cord. We are moving the entire Forensic Team—the agents, the orchestration, and the data—onto a standard laptop. No cloud. No API costs. No data leaving your local network.

This is the power of Edge AI combined with the Model Context Protocol (MCP).

The Pivot: The “Forensic Clean-Room”

In the world of rare book forensics, data sovereignty isn’t a “nice-to-have.” When you are auditing high-value archival records or sensitive provenance data, the “Clean-Room” approach is the gold standard. You want the data isolated.

By moving our stack to the Edge, we transform a laptop into a portable forensic lab.

The Edge Architecture

Running MCP agents locally: small language models power the supervisor and specialist agents while the MCP server provides structured tool access to local data.

Notice that the architecture we built in Post 2 doesn’t change. Because we used MCP as our “USB-C” interface, we don’t have to rewrite our tools or our agents. We only swap the Inference Engine.

Why SLMs Love MCP

Small language models struggle when tasks are open-ended.

However, MCP dramatically reduces the search space.

Instead of inventing answers, the model interacts with structured primitives:

tools
resources
prompts

Each defined with strict schemas.

The Thesis: Large models are great for designing the system and writing the initial code. Small models are the perfect runtime engines for executing those standardized tasks.

The “How-To”: Swapping the Engine

In our updated orchestrator.py, we’ve introduced a provider flag. Instead of hitting a remote API, the Python supervisor now talks to a local inference server (like Ollama or LM Studio).

# [Post 3 - Edge AI] Swapping the Inference Provider
if args.provider == "ollama":
# Pointing to the local SLM engine
client = OllamaClient(base_url="http://localhost:11434")
model = "phi4"
else:
# Standard Cloud Provider
client = AnthropicClient()
model = "claude-3-5-sonnet"

Because our TypeScript MCP Server is running locally via stdio, the latency is nearly zero. The “Librarian” fetches metadata from the local database, and the “Analyst” runs the audit—all without a single packet hitting the open web.

Benchmarking the Forensic Team: Cloud vs. Edge

Does a 14B model perform as well as a 400B model for forensics? When constrained by MCP schemas, the results are surprising.

Criteria	Cloud (Claude/GPT-4)	Edge (Phi-4/Mistral)
Reasoning Depth	Extremely High	High (with MCP Tool Constraints)
Latency	1.5s – 3s (Network Dependent)	< 500ms (Local Inference)
Cost	Per-token billing	$0.00
Privacy	Data processed externally	100% Data Sovereignty
Scalability	Infinite	Limited by local RAM/NPU

The Reveal: Same System, New Home

If you look at the latest update to the repository, you’ll see that the orchestration logic is nearly identical. The architecture stack from earlier posts remains unchanged.

Edge AI architecture replaces cloud inference with local small language models while retaining MCP-based tool access.

Nothing about the agents changed.

Nothing about the tools changed.

Only the inference engine moved.

The “Zero-Glue” promise is realized here.

We didn’t build a cloud app; we built a protocol-driven system. The fact that it can live on a server or a laptop is simply a deployment choice.

What’s Next?

We’ve built the server. We’ve orchestrated the team. We’ve moved it to the edge.

In the final post of this series, we tackle the “Final Boss” of AI systems: Enterprise Governance. We’ll explore how to take this forensic lab and scale it across an organization using Oracle 26ai, ensuring that every audit is secure, permissioned, and defensible.

Ready to go local?

Check out the orchestrator.py update and try running the Forensic Team on your own machine.

MCP Forensic Analyzer – Edge AI Example

The “Zero-Glue” Series

Post 1: The End of Glue Code: Why MCP is the USB-C Moment for AI
Post 2: The Forensic Team: Architecting Multi-Agent Handoffs
Post 3: From Cloud to Laptop: Running MCP Agents with SLMs — You are here
Post 4: Enterprise Governance: Scaling MCP with Oracle 26ai — Coming Soon

The post From Cloud to Laptop: Running MCP Agents with Small Language Models appeared first on Blog of Ken W. Alger.

The Backyard Quarry, Part 2: Designing a Schema for Physical Objects

Ken W Alger — Thu, 26 Mar 2026 21:01:16 +0000

In the first post of this series we set the stage for the Backyard Quarry project.

Once you decide every rock in the yard should have a record, the next question appears immediately:

What exactly should we record?

It’s a deceptively simple question. And like most simple questions in engineering, it opens the door to a surprisingly large number of decisions.

The First Attempt

The most straightforward approach is to keep things minimal.

Each rock gets an identifier and a few attributes.

Something like:

rock_id
size
price

At first glance, this seems reasonable.

We can identify the rock. We can describe it in some vague way. We can assign a price.

But this model breaks down almost immediately.

“Size” is ambiguous. Is that weight? Volume? Longest dimension? All of the above?

Two rocks of the same “size” might behave very differently when you try to move them.

And more importantly, this model doesn’t capture anything about the rock beyond its most basic characteristics.

It’s enough to sell a rock.

It’s not enough to understand one.

Expanding the Model

To make the system more useful, we need to be more explicit.

A slightly richer model might look like this:

rock_id
weight_lb
length_cm
width_cm
height_cm
color
rock_type
location_found
status

Now we’re getting somewhere.

We can distinguish between rocks that look similar but behave differently.

We can track where each rock came from.

We can start to answer questions like:

How many rocks do we have in a given area?
What size distribution does the dataset have?
Which rocks are suitable for different uses?

This is the point where the rock pile starts to feel less like a random collection and more like a dataset.

The Object Data Model

At a higher level, what we’re really doing is separating a physical object into a few distinct components.

A simple model for representing a physical object as structured data and associated assets.

Each rock has:

metadata describing its properties
images representing its appearance
optionally, a 3D model capturing its shape

This separation turns out to be important.

Metadata is small, structured, and easy to query.

Images and 3D models are large, unstructured assets that need to be stored and referenced.

Keeping those concerns separate is a pattern that shows up in many real-world systems.

The Identity Problem

Once the schema starts to take shape, another question appears.

How do we uniquely identify a rock?

There are a few options:

sequential IDs (rock_001, rock_002)
UUIDs
physical tags attached to rocks
some form of image-based identification

For a small backyard dataset, almost anything works.

But the choice matters more as the system grows.

Sequential IDs are easy to read but require coordination.

UUIDs are globally unique but harder to work with manually.

Physical tags introduce a connection between the digital record and the real-world object.

Even in a simple system, identity becomes a design decision.

Classification: The Quarry Taxonomy

At some point, it becomes useful to introduce categories.

Originally this was just a convenience.

But like many things in this project, it quickly became something more formal.

A simple classification system might look like this:

Class 0 — Pebble
Class 1 — Hand Sample
Class 2 — Landscaping Rock
Class 3 — Wheelbarrow Class
Class 4 — Engine Block Class
Class 5 — Heavy Machinery Class

Each class roughly corresponds to how the rock is handled.

This turns out to be surprisingly useful.

Instead of asking for exact dimensions, we can filter by class:

“Show me all Pebble Class rocks”
“Exclude anything above Wheelbarrow Class”

In other words, we’ve introduced a derived attribute — something computed from the underlying data rather than stored arbitrarily.

This is exactly how classification systems evolve in real datasets.

Thinking About Lifecycle

Rocks don’t change much physically, but their role in the system does.

A rock might move through states like:

collected
cataloged
listed_for_sale
sold

Tracking this lifecycle introduces another dimension to the data.

Now we’re not just modeling objects.

We’re modeling *objects over *.

Even in a simple system, state and transitions begin to matter.

The Tradeoffs

At this point, the schema is already doing useful work.

But it’s also clear that there’s no perfect design.

Every decision involves tradeoffs:

more fields vs simplicity
normalized structure vs ease of use
flexibility vs consistency

The goal isn’t to design the perfect schema on the first try.

The goal is to design something that can evolve.

Because as soon as we start capturing real data, we’ll learn what we got wrong.

What Comes Next

With a basic schema in place, the next challenge becomes obvious.

We know what we want to store.

Now we need to figure out how to capture it.

In the next post, we’ll look at how to turn a physical rock into images, measurements, and potentially a 3D model — and how that process introduces its own set of constraints.

Because it turns out that collecting data from the physical world is rarely as clean as designing a schema on paper.

The post The Backyard Quarry, Part 2: Designing a Schema for Physical Objects appeared first on Blog of Ken W. Alger.

The Backyard Quarry: Turning Rocks Into Data

Ken W Alger — Thu, 19 Mar 2026 17:18:33 +0000

Another round of tech layoffs rolled through the industry recently, and I was one of the people caught in it.

If you’ve worked in tech for any length of time, you know the routine that follows. Update the résumé. Reach out to contacts. Scroll job boards. Try to figure out which technologies the market is currently excited about and which ones have quietly drifted into irrelevance.

After a few days of that cycle, I found myself spending more time outside than in front of a laptop.

One afternoon, walking around the yard, I noticed something interesting.

My backyard contains a surprisingly large dataset.

Rocks.

Sample of the rocks from the Backyard Quarry used for the dataset.

Lots of rocks.

Some are the size of peas. Others are roughly the size of a car engine. A few fall somewhere in the unsettling range between “wheelbarrow recommended” and “this probably requires heavy machinery.”

Naturally, I had the same thought many people eventually have when staring at a large pile of rocks:

I could probably sell these.

A small stand near the road. A few piles sorted by size. Maybe a sign that says “Landscaping Rock.” It’s not exactly a venture-backed startup, but stranger side businesses have existed.

Unfortunately, engineers have a well-known weakness.

We rarely do things the simple way.

If I was going to sell rocks, I wasn’t just going to pile them on a table.

I was going to build a system.

The Dataset

The moment you start thinking about the rocks as inventory, a familiar set of questions appears.

How many rocks are there?

What kinds?

Which ones are small decorative stones and which ones fall firmly into what I’ve started calling Engine Block Class?

Like many real-world datasets, this one has significant variability.

Some objects are a few grams. Others weigh enough to require careful lifting technique and a brief internal conversation about life choices.

At a glance, the dataset looks chaotic. But underneath the chaos are patterns.

Different sizes. Different shapes. Different colors. Different geological types. Some rocks are smooth river stones. Others are jagged fragments that look like they escaped from a small landslide.

If you squint a little, you start to see the outlines of something familiar to anyone who works with data systems.

A collection of physical objects that could be represented as structured records.

The Engineer’s Curse

In theory, selling rocks is simple.

Step one: collect rocks.
Step two: put them in a pile.
Step three: wait for someone to stop their car and decide they want landscaping material.

But once you start thinking about it from an engineering perspective, the questions multiply.

Should each rock have an identifier?

Should there be photographs?

Should the system track weight or dimensions?

What about classification?

It’s probably useful to distinguish between Pebble Class rocks and Wheelbarrow Class rocks.

And what about the really large ones — the ones that are clearly in the Engine Block Class, which itself appears to span everything from motorcycle engine scale to something closer to a semi-truck.

Once you start thinking about these questions, the simple rock pile begins to look like something else entirely.

A catalog.

A dataset.

A system waiting to happen.

From Rocks to Records

What if every rock had a record?

Something simple at first.

An identifier. A few attributes. Maybe a photo.

Conceptually, it might look like this:

rock_id
weight
dimensions
color
rock_type
location_found
status

Each rock in the yard becomes a digital object — a structured record representing something in the physical world.

In other words, each rock now has a digital twin.

That might sound slightly ridiculous in the context of landscaping stones, but the idea is surprisingly powerful.

Across many industries, organizations are trying to solve exactly this problem: how to connect messy physical reality with structured digital systems.

Manufacturers track machine parts.

Museums catalog artifacts.

Farmers track crops.

Logistics companies track inventory moving through warehouses.

In each case, the challenge is similar.

A physical object exists somewhere in the world.

We want to represent it in a way that software systems can understand.

The Backyard Quarry

At this point the rock pile had acquired a new name.

The Backyard Quarry.

Partly as a joke, and partly because it captured the spirit of the project. What started as a casual observation had turned into a small experiment in data modeling, object cataloging, and system design.

The dataset might be small.

The objects might be rocks.

But the underlying questions are surprisingly rich.

How do you represent physical objects in software?

How do you capture information about them?

How do you search and organize the resulting data?

And how do these systems scale when the number of objects grows from a few dozen to thousands — or millions?

What Comes Next

Over the next few posts in this series, I’m going to explore those questions by building a small system around the Backyard Quarry.

We’ll look at things like:

designing a schema for physical objects
capturing images and measurements
generating 3D models using photogrammetry
building ingestion pipelines
indexing and searching the dataset

All starting from a simple collection of rocks.

The world has no shortage of complicated engineering problems.

Sometimes the best place to explore them is somewhere simpler.

Like a pile of rocks in the backyard.

And if you happen to need a carefully documented specimen from the Backyard Quarry, inventory is currently available.

Shipping, however, may exceed the value of the rock itself.

The post The Backyard Quarry: Turning Rocks Into Data appeared first on Blog of Ken W. Alger.

The Forensic Team: Architecting Multi-Agent Handoffs with MCP

Ken W Alger — Thu, 19 Mar 2026 17:00:15 +0000

Why One LLM Isn't Enough—And How to Build a Specialized Agentic Workforce

In my last post, we explored the "Zero-Glue" architecture of the Model Context Protocol (MCP). We established that standardizing how AI "talks" to data via an MCP Server is the "USB-C moment" for AI infrastructure.

But once you have the pipes, how do you build the engine?

In 2026, the answer is no longer "one giant system prompt." Instead, it’s Functional Specialization. Today, we’re building a Multi-Agent Forensic Team: a group of specialized Python agents that use our TypeScript MCP Server to perform deep-dive archival audits.

The "Context Fatigue" Problem

Early agent architectures relied on a single LLM handling everything:

retrieve data
reason about it
run tools
write the final output

Even with large context windows, this approach quickly hits a reasoning ceiling.

A single agent juggling too many tools often suffers from:

Tool Confusion

Choosing the wrong function when multiple tools are available.
Logic Drift

Losing track of the objective during multi-step reasoning.
Latency and Cost

Sequential reasoning loops increase response time and token usage.

The solution is functional specialization.

Instead of one overloaded agent, we build a team of focused agents coordinated by a supervisor.

Before diving into the multi-agent design, it helps to understand where the agents live in the MCP stack.

Figure 1. The MCP architecture stack: agents reason about tasks while MCP standardizes access to tools, resources, and enterprise data.

The Architecture: A Polyglot Powerhouse

One of MCP’s strengths is that it decouples tools from orchestration.

This allows each layer of the system to use the language best suited for the job.

In our case:

The "Hands" (TypeScript)

Our MCP server handles data access and tool execution with strong typing.
The "Brain" (Python)

A Python orchestrator manages reasoning and agent coordination using frameworks like LangGraph or PydanticAI.

Because both layers communicate through MCP, the language boundary disappears.

Multi-Agent MCP Architecture

Figure 2. Multi-agent MCP architecture: a Python supervisor coordinates specialized agents that access tools through a shared MCP server.

Each agent communicates with tools through the MCP server, not directly with the data source.

The Forensic Team Roles:

Role	Agent Identity	Primary Responsibility	MCP Tools Used
Supervisor	The Orchestrator	Receives request, manages state, and handles handoffs.	`list_tools`, `list_resources`
Librarian	The Researcher	Gathers historical facts and archival metadata	`find_book_in_master_bibliography`
Analyst	The Forensic Tech	Compares observed data against metadata to find flaws	`audit_artifact_consistency`

How It Works: Glue-Free Agent Handoffs

The beauty of MCP is the Transport Layer. Our Python client connects to the TypeScript server via stdio. It doesn't care that the server is written in Node.js; it only cares about the protocol.

Spawning the Sub-process In our orchestrator.py, we define how to "wake up" the TypeScript server. Notice how we point Python directly at the Node.js build:

def get_server_params() -> StdioServerParameters:
    # This is the bridge: Python spawning a Node.js process
    return StdioServerParameters(
        command="node",
        args=[str(SERVER_ENTRY)], # Points to our TS /build/index.js
        cwd=str(PROJECT_ROOT),
    )

The Functional Handoff Because MCP tools expose strict schemas, the agents can pass structured results between each other without custom translation layers.

The Supervisor doesn't manually parse JSON or remap fields.

Instead it simply chains the outputs:

# 1. Librarian: pull book details
librarian_result = await librarian_agent(session, title, author)

# 2. Analyst: audit for discrepancies (using Librarian's data)
analyst_result = await analyst_agent(
    session, book_page_id, book_standard, observed
)

Why This Wins in the Enterprise:

Auditability

You can track exactly what each agent saw and what conclusions it produced.

Security

Agent permissions can be scoped by tool access.

The Librarian may only read archives, while the Analyst writes forensic reports.

Maintainability

Each agent owns a single responsibility.

If the forensic logic changes, only the Analyst agent needs to be updated.

Scaling to the "AI Mesh"

By using MCP as the backbone, you’ve built more than an app; you’ve built a System of Intelligence. Any new tool you add to your TypeScript server is instantly "discoverable" by your Python team. You are no longer writing "Glue Code"; you are orchestrating a digital workforce.

The MCP server becomes the shared capability layer for your entire AI system.

📚 The "Zero-Glue" Series

Post 1: The End of Glue Code: Why MCP is the USB-C Moment for AI
Post 2: The Forensic Team: Architecting Multi-Agent Handoffs - You are here
Post 3: From Cloud to Laptop: Running MCP Agents with SLMs - Coming Soon
Post 4: Enterprise Governance: Scaling MCP with Oracle 26ai - Coming Soon

Explore the Code:

The full multi-agent orchestrator is now live in the /examples folder of the repo:
👉 MCP Forensic Analyzer - Multi-Agent Example

Up Next in the Series:

Next week, we go small. We’re moving the "Forensic Team" out of the cloud and onto your laptop. We’ll explore Edge AI and how to run this entire stack using Small Language Models (SLMs) like Phi-4—no $10,000 GPU required.