Agentic Harness Engineering on 67AI Lab

What Comes After MCP: The Next Layer of Agent Infrastructure

Wed, 13 May 2026 10:05:33 +0000

The live demo repo for this series is 67ailab/harness-engineering. For this final post, I did not change the repo before publishing; the codebase discussed here is the current public state at commit 7d01dae, the same commit introduced in the previous post when the repo gained a real blueprint export. That matters because this article is not about an imaginary next step. It is about what the current repo already makes obvious once you stop looking at MCP as the finish line.

A Reference Blueprint for a Production Agent Harness

Tue, 12 May 2026 10:07:04 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new repo commit is 7d01dae, which adds a real blueprint export to the demo so the architecture in this article is not just a hand-drawn diagram in prose. You can now run:

PYTHONPATH=src python3 -m harness_engineering.cli blueprint --pretty
PYTHONPATH=src python3 -m harness_engineering.cli blueprint --format markdown
PYTHONPATH=src python3 -m harness_engineering.cli blueprint --format mermaid

That feature lives mainly in:

Cost, Latency, and Throughput Engineering for Agents

Mon, 11 May 2026 10:07:23 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new repo commit is b9a60e8, which adds per-step timing metadata, lightweight workload and token estimates, and performance/cost rollups to the harness traces and summaries.

That change lives mainly in:

src/harness_engineering/models.py
src/harness_engineering/runner.py
src/harness_engineering/tracing.py
src/harness_engineering/store.py
tests/test_harness.py
README.md

The core additions are:

new timing and metrics fields on StepResult in models.py
wall-clock measurement inside RetryPolicy.call() in runner.py
step-level workload estimation in HarnessRunner._estimate_step_metrics()
aggregated performance and cost rollups in build_trace_summary() in tracing.py
operator-facing rollups in RunStore.build_summary() in store.py

This is the right place for Post 12 to land, because cost and latency problems in agent systems almost never come from one bad prompt. They come from system shape:

Security, Auth, and Policy in Agent Harnesses

Sun, 10 May 2026 10:05:23 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new repo commit is 3f2ec5d, which adds a checked-in baseline policy file at policy/default.json and tightens PolicyEngine so relative policy paths resolve from the policy file location rather than from the caller’s current working directory.

That sounds like a small change. It is small in lines of code. It is not small in meaning.

Multi-Agent Systems Without the Theater

Sat, 09 May 2026 10:13:19 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit dadf203, which adds a small but real multi-agent mode to the demo: the harness can now run with explicit planner, executor, and reviewer roles, persist role activity, record handoffs, and expose those artifacts through the CLI and saved run files.

The core changes are in:

Sandboxing, Isolation, and Safe Execution

Fri, 08 May 2026 10:15:48 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit 98c6302, which adds an explicit policy layer to the harness: tools now carry action categories, risky writes are checked against allowed output roots before execution, and policy decisions are persisted in traces and summaries.

The key code changes are in:

src/harness_engineering/policy.py
src/harness_engineering/tools.py
src/harness_engineering/runner.py
src/harness_engineering/cli.py
src/harness_engineering/mcp.py
src/harness_engineering/tracing.py
src/harness_engineering/store.py
src/harness_engineering/workflow.py
sample_data/policy/restrictive.json

That matters because “sandboxing” gets used too loosely in agent conversations. Sometimes people mean a real OS sandbox. Sometimes they mean a container. Sometimes they mean “the model only has a few tools.” Those are not the same thing.

Tracing, Observability, and Evals for Agent Systems

Thu, 07 May 2026 10:11:02 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit 85c762c, which adds two concrete things the repo was missing:

a persisted trace-summary surface for every run
a lightweight eval runner with trace-aware fixtures

The key changes are in src/harness_engineering/tracing.py, src/harness_engineering/store.py, src/harness_engineering/cli.py, and the new src/harness_engineering/evals.py module, plus starter fixtures in sample_data/evals/basic.json.

That matters because a lot of agent writing still treats observability as an afterthought and evals as a benchmark spreadsheet. In practice, most production pain shows up somewhere else:

Human-in-the-Loop Done Properly

Wed, 06 May 2026 10:06:52 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit 352fba2, which adds a first-class pending-approval inspection surface to the existing approval-gated harness. The key changes are in src/harness_engineering/runner.py, src/harness_engineering/cli.py, and src/harness_engineering/store.py.

That matters because most writing about “human in the loop” in agent systems is still weirdly sloppy. A model says “should I proceed?”, a human types “yes”, and the demo declares the governance problem solved. It is not solved. In production, approval is not a vibe, not a chat convention, and not a magical hidden boolean inside the runtime. It is a workflow boundary with state, context, inspection, and recovery semantics.

Memory Architecture for Agents: Context, Sessions, and State

Tue, 05 May 2026 10:07:53 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit d20e352, which adds an explicit memory-layer model to the demo instead of treating every stored value as one blurry thing called “memory.”

The core addition is src/harness_engineering/memory.py, plus wiring in src/harness_engineering/store.py and src/harness_engineering/cli.py so every run now emits a memory.json snapshot and the CLI exposes a memory command.

Durable Execution Is the Difference Between a Demo and a System

Mon, 04 May 2026 10:25:00 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did change the repo before publishing. The new capability shipped in commit 9612b58, which adds persisted run summaries plus replay-oriented history inspection to the existing approval-gated harness. The key changes are in src/harness_engineering/store.py and src/harness_engineering/cli.py.

That addition matters because durable execution is where most agent demos quietly stop being honest. It is easy to show a model calling tools in one uninterrupted run. It is much harder to explain what happens when execution pauses for approval, the process dies, the machine reboots, the reviewer returns malformed output, or an operator needs to understand what state the run is actually in.

Orchestration Patterns: Loops, Graphs, Managers, and Handoffs

Sun, 03 May 2026 10:20:00 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did add a real repo capability before publishing. The repo now includes a workflow export layer in src/harness_engineering/workflow.py, plus a workflow CLI command in src/harness_engineering/cli.py that renders the current harness orchestration as structured JSON or Mermaid. That change shipped in commit a007c08.

That may sound like a documentation flourish. It is not. The point of an orchestration post is not to wave vaguely at boxes and arrows. It is to make the runtime’s control structure explicit enough that you can inspect it, reason about it, and argue about whether it is the right one.

Tool Calling, Schemas, and the Rise of MCP

Sat, 02 May 2026 10:15:00 +0000

The live demo repo for this series is 67ailab/harness-engineering, and for this post I did add a real new capability before publishing. The repo now includes a small MCP-style adapter layer in src/harness_engineering/mcp.py, plus CLI entry points to inspect tool descriptors and call tools through that boundary. The exact repo change shipped in commit e21f361.

That addition matters because this is the first point in the series where the demo has to answer a question the broader ecosystem now forces on every agent builder: what exactly is the boundary between your harness and the tool protocol?

Agentic Harness Engineering White Paper

Fri, 01 May 2026 12:55:00 +0000

Artificial intelligence is entering a new engineering phase. For the last two years, the dominant conversation centered on prompt engineering: how to ask better questions, structure better instructions, and squeeze more reliable output from large language models. That work mattered, and still matters. But as models have become capable of planning, tool use, coding, browsing, testing, and acting over many steps, the practical bottleneck has shifted.

The central production problem is no longer simply how to prompt the model. It is how to build the runtime around the model so that the model can act effectively, safely, durably, and measurably.

Anatomy of an Agent Harness

Fri, 01 May 2026 10:20:00 +0000

The live demo repo for this series is 67ailab/harness-engineering, and this post stays anchored to the code that exists there today. I did not add a new repo capability for this article. The point of this installment is to dissect the current harness as it actually stands: what lives in src/harness_engineering/, how the pieces fit together, and which parts are carrying the reliability burden.

That matters because “agent” is now a dangerously overloaded word. Many teams still mean either a model that can call functions or a prompt loop with some memory and tool wrappers. Those are ingredients, not a runtime anatomy.

Why Agentic Harness Engineering Matters More Than Prompt Engineering

Thu, 30 Apr 2026 23:05:00 +0000

The live demo repo for this series is 67ailab/harness-engineering. This first post is grounded in the current public repo state rather than a made-up architecture diagram. For this article, I did not add a new repo feature before publishing; the existing baseline already supports the core claim. At the time of writing, that baseline includes typed tools, checkpointed run state, resumable execution, an approval gate before writing artifacts, per-step traces, a planner/reviewer split, and optional local OpenAI-compatible model support.