I shipped a new page on johnclick.ai: the Harness Engineering radial.
If you've already visited the knowledge graph and understood how my Notion workspace projects career history as an interactive force-directed network, the harness radial is the companion piece. The knowledge graph shows WHAT I've done. The harness radial shows the full inventory of components I've built + used to govern AI agents across my development workflows.
252 nodes. 4 concentric rings. One central agent concept at the center.
This post explains what you're looking at.
TL;DR
- The radial visualizes the full component inventory for agentic harness engineering: every skill, script, rule, prompt, subsystem, + project I've built or shipped using these pieces
- 4 rings: Projects (what got shipped), Execution (harness subsystems + commands), Knowledge & Governance (skills + rules + prompts), Technologies (the stack)
- These components get composed into different harnesses for different workflows. A Jira ticket creation workflow pulls from different skills + rules than a deep research session or a Notion schema migration
- Harness engineering is becoming a real discipline; LangChain, Anthropic, & others are writing about it. This is what one person's component library actually looks like after 18 months of iteration
- Everything on the radial is backed by real Notion records with DUAL relations. Click a node and you trace the connections
What is an agentic harness (& what are the components)
The term is still settling, but the concept is straightforward.
LangChain's definition works well: Agent = Model + Harness. The model is the intelligence. The harness is everything else.
| Component | What It Does | Example |
|---|---|---|
| Model | Generates text, reasons, plans | Claude Opus 4.6, Gemini 2.5 Flash |
| Harness | Everything that ISN'T the model | Rules, hooks, skills, scripts, configs, state management, coordination, enforcement |
A raw LLM can't maintain state across sessions. It can't enforce governance rules. It can't coordinate with other agents working in the same codebase. It can't verify its own output against organizational standards. It can't even remember what it did 5 minutes ago if you start a new context window.
Harness components handle all of that. But here's the thing that's easy to miss: there isn't one monolithic "harness." Different workflows compose different subsets of these components.
A Cursor session where I'm doing a Notion schema migration loads the notion-mcp skill, the adr-first-deployment rule, the create-adr command, the Hook Executor, + the UEAH attribution system. A Claude Code deep research session loads totally different skills + prompts but shares the same enforcement engine + session state infrastructure. A Gemini CLI receipt-hunting workflow is its own specialized harness with its own components.
The radial shows the FULL INVENTORY. The components. The building blocks. Not one harness; the parts bin from which various harnesses get assembled.
I run up to ~15 concurrent agents across three platforms (Cursor, Claude Code, Gemini CLI) in my development environment. One orchestrator + workers. Each agent session composes its own harness from this shared component library. Three platforms, one set of building blocks, many different configurations.
The 4 rings
The radial organizes this component inventory into four concentric rings around a central node. Each ring represents a different category.
| Ring | Category | Node Count | What Lives Here |
|---|---|---|---|
| Outer | Related Projects | 45 | Deliverables shipped using these components |
| 2nd | Execution | 31 | 19 harness subsystems + 12 commands |
| 3rd | Knowledge & Governance | 78 | 45 skills + 11 rules + 22 prompts |
| Inner | Technologies | 98 | The full tech stack powering everything |
| Center | Agent | 1 | The agent itself |
Think of it as a parts catalog with context. The outer ring is what people see (shipped projects). The inner rings are the componentry that made those projects possible. Any given workflow picks from across the rings.
Ring 1: Execution (19 harness subsystems + 12 commands)
These are the runtime infrastructure components. Each subsystem handles a specific coordination or enforcement problem. Some run in every session (Hook Executor, Session State). Others activate only when relevant (File Lock fires when two agents target the same file; the Token Ledger kicks in when budget thresholds approach).
| Subsystem | What It Solves |
|---|---|
| Hook Executor + Enforcement Engine | Routes agent actions through validators before execution. The central nervous system; this one runs in nearly every harness configuration. |
| Constitutional Framework (12 Chapters) | The "soul document." Shared rules compiled per-platform from canonical chapters. |
| Session State + Integrity Verification | Tracks what each agent has done, detects drift, verifies state hasn't been corrupted. |
| File Lock System | Prevents two agents from editing the same file simultaneously. Mutex for codebases. Only fires during multi-agent sessions. |
| Handoff Protocol | Structured context transfer when Agent A finishes & Agent B picks up. Immutable. |
| Sub-Agent Routing System | Decides which agent gets which task based on capability + current load. |
| Token Ledger + Budget Gate | Tracks token consumption per agent, blocks expensive operations before they blow budgets. |
| Agent Memory System | Episodic + semantic memory so agents build on history instead of repeating mistakes. |
| Agent Registry (Fleet Configuration) | Fleet manifest. Which agents exist, their capabilities, their platform, their status. |
| Security Infrastructure | Identity verification + HMAC signing + allowlists. Zero-trust for agents. |
| Event Bus (Dual: File + MCP SQLite) | Inter-agent communication. When one agent finishes, others waiting on that output get notified. |
| Message Queue (Inter-Agent) | Async message passing between agents that aren't in the same process. |
| Sound Notification System | Audio personas for different agent events. Yes, my agents make sounds. It helps. |
| UEAH v3 | Attribution system. Every artifact gets tagged with which agent, which model, which session produced it. |
| Blue/Red Team Security Audit | Adversarial testing framework for the harness components themselves. |
| Scripts Infrastructure | The ~60 Python + shell scripts that the hooks + validators call. Shared across all harness configurations. |
| Deep Research Duo | Coordinated dual-agent deep research workflow. A specialized harness that composes its own subset of components. |
| Cursor Multi-Agent Build | Orchestration config for Cursor's parallel agent sessions. |
| Gemini Receipt Hunter | Specialized single-purpose workflow. Its own mini-harness. |
The 12 commands are action triggers: pre-commit, commit-msg, create-adr, session-save, session-load, security-scan, handoff-create, handoff-review, etc. These are the verbs that invoke the subsystems above.
Not every session uses every subsystem. A solo Claude Code coding session might only engage the Hook Executor, Session State, UEAH, + Scripts Infrastructure. A full multi-agent orchestration session activates the File Lock, Event Bus, Message Queue, Sub-Agent Routing, + Token Ledger on top of those. The radial shows the full catalog; the workflow determines the subset.
Ring 2: Knowledge & Governance (45 skills + 11 rules + 22 prompts)
This ring is the "brain." Skills are procedural knowledge modules. Rules are hard constraints. Prompts are system prompts + templates. These are the most composable layer; any given agent session cherry-picks the skills + rules relevant to its task.
Skills (~45) break down into types:
| Skill Type | Examples | Purpose |
|---|---|---|
| Workflow Template | jira-ticket-creator, confluence-page-mirror, skill-creator, Plan Executor |
Multi-step procedures agents follow |
| Agent Prompt | adr-reference-deployment, context-optimizer, anti-thrash-protocol |
Focused behavioral guidance |
| System Prompt | notion-mcp |
Full system prompt for specific tool contexts |
| CLI Command | gitlab-cli, onepassword-cli |
Wrapped CLI tool usage patterns |
| Cursor Rule | PARA Universal Linking v2, UEAH v4 Attribution Protocol |
Platform-specific behavioral rules |
The key property: skills are reusable across harness configurations. Teach an agent how to create a Jira ticket ONCE, and every agent in the fleet can load that skill whenever a Jira workflow is relevant. That's 45 "teach once, compose anywhere" modules in the library.
Some skills show up in almost every session (context-optimizer, anti-thrash-protocol). Others are specialized (confluence-page-mirror only loads when I'm doing Confluence work; terraform-workflow only when I'm touching IaC). The radial shows all 45; a typical session loads maybe 5-10.
Rules (11) are the hard constraints:
| Rule Type | Example | What It Enforces |
|---|---|---|
| Security Policy | Enterprise Security Standards, MCP Security Policy | What agents can + can't access |
| Agent Guardrail | GOV-006 (per-DB skills required), GOV-010 (mandatory parent) | Structural integrity of the workspace |
| Coding Standard | Naming conventions | Code consistency across agents |
| Style Guide | SQL Style Guide, JS/TS Standards | Output quality |
| System Constraint | Mandatory parent on create-pages |
Prevents orphaned Notion pages |
Rules are less composable than skills. Most of them apply universally; you don't cherry-pick security policies.
Prompts (22) range from full system prompts (Claude System Prompt, Cursor Prompt, Gemini Gem Creator) to focused task prompts (Log Analysis Expert, Network Diagnostics Helper, Knowledge Base Article Creator). These are the starting configurations; skills + rules shape behavior from there.
Ring 3: Technologies (98)
The full technology stack. 98 tools + platforms + frameworks, categorized by type. Same data that appears in the knowledge graph, rendered here to show what powers the harness components.
Highlights: Python (the enforcement scripts), YAML (the guard configs), Claude + Gemini (the models), Cursor + Claude Code + Gemini CLI (the IDE substrates), Notion (the knowledge graph backend), Gatsby + React + Netlify (the frontend that renders this very page).
Ring 4: Related Projects (45)
The outermost ring. These are the actual deliverables. Some are harness infrastructure projects themselves (Agentic Developer Toolkit, GWS IaC Nexus monorepo, MCP Directory). Others are projects I shipped USING various harness components (Confluence Knowledge Bases, CI/CD pipelines, the websites themselves).
The connection matters: each project node links back to the technologies, skills, + harness subsystems that supported it. A project like the Google Workspace MCP Server touched different components than the Confluence Knowledge Base portfolio, but both drew from the same shared library.
The radial shows these connections as spokes; the knowledge graph shows them as edges.
How this connects to the knowledge graph
The knowledge graph and the harness radial are two views of the SAME underlying data.
| Visualization | Focus | Data Source | Interaction |
|---|---|---|---|
| Knowledge Graph | Career history + professional network | Work History, Projects, Technologies, Proficiencies | Force-directed; drag, zoom, click, collapse |
| Harness Radial | Agent infrastructure component inventory | Agent Harnesses, Skills, Commands, Rules, Prompts, Technologies, Projects | Concentric rings; click rings + nodes to explore |
Same Notion workspace. Same DUAL relations. Same Gatsby build pipeline. Different lens.
The knowledge graph answers: who is this person & what have they done?
The harness radial answers: what did this person build to govern their AI agents, & how do the pieces connect?
What this page is NOT
I want to be clear about something.
Harness engineering is becoming a recognized discipline. LangChain published a thorough anatomy piece in March 2026. Anthropic ships hooks + middleware in Claude Code. Commercial tools like Oculi enforce policies on agent tool calls. The Everything Claude Code community project has 118K+ GitHub stars.
The concept of "wrap your agents in governance infrastructure" is consensus now, not a novel insight.
What IS specific to my setup is the component inventory and the iteration behind it. 19 discrete harness subsystems, 45 skills, 200+ ADRs, 11 rule families, 22 prompt templates, coordination across 3 IDE platforms. Built iteratively over 18+ months of daily use in an enterprise environment (Rivian/VW Tech Joint Venture) + personal projects.
The radial page doesn't claim this is unique architecture. It shows what one person's component library actually looks like at scale, with real counts, real connections, + real composition patterns.
The specifics are what matters. Not the concept.
What's next
The radial currently renders from static Notion data at build time (same as the knowledge graph). Future iterations:
- Cross-ring highlighting (per ADR-NM109): click a harness subsystem & every component it uses across ALL rings lights up while everything else dims. The data model already supports this; the Agent Harnesses DB has DUAL relations to Skills, Hooks, Commands, Rules, Scripts, Prompts, Technologies, + Projects.
- Reverse highlighting: click a skill or rule & see which harness configurations USE it
- Platform filtering: show me only the Claude Code components vs. Cursor vs. Gemini CLI
- Click-through to individual component detail pages (each one has a full Notion page behind it with technical documentation)
For now, go poke around: johnclick.ai/harness-engineering/
If you want the deeper story on any specific layer, the enforcement series covers the hooks + validators in detail: Part 1: Markdown is Agent Enforcement Theater. The ADR-First Development post explains the 200+ ADR system. And the knowledge graph post covers the Notion-to-Gatsby pipeline that makes all of this renderable.
Related reading: Markdown is Agent Enforcement Theater | ADR-First Development | Notion Knowledge Graph | Notion as Context Pipeline
John Click is a Senior IT Solutions Engineer at the Rivian/VW Tech Joint Venture. He writes at johnclick.ai & johnclick.dev.
