AI Agent Operational Governance
Defines AI agent operational governance: the layer of authority, evidence, tools, traces, costs, and human gates that makes agents usable in real work.
Long-form thinking with a practical bias.
Essays and memos about software, AI, product judgment, personal systems, and the work behind public artifacts.
Series
Start From A Route
Choose the route that matches your current problem, then read the connected pieces in order.
Obsidian + Codex Federated Knowledge Base
Explains why chat logs are not a durable knowledge base and how Obsidian, local Markdown, Codex, project directories, and publication nodes form a federated system.
SketchUp Agent Harness Technical Architecture
Explains why Codex and Claude are entry points while the durable SAH core is the MCP server, project workspace, bridge trace, and SketchUp bridge.
- 00Why the Agent CLI Is Only the Entry Point
- 01From MCP Server to SketchUp Ruby Bridge
- 02Why design_model.json Has to Come Before the SketchUp Scene
- 03Bridge Trace: Why Execution Should Be Planned Before Calling SketchUp
- 04Making Imports Repairable: From Source Evidence to Working Truth
- 05Runtime Skill Boundaries in an Agent Harness
- 06How to Verify an Agent Harness
- 07Semantic Component Registry for Agent Placement
Issue-Driven AI Engineering
Argues that an issue should be an executable contract for AI work, with scope, context, gates, evidence, and release boundaries instead of a loose todo.
- 00An Issue Is Not a Todo: It Should Be an Executable Contract for AI
- 01Why Codex Should Be a Worker, Not the Scheduler
- 02Use Labels, Branches, and Comments as an AI Engineering State Machine
- 03From Triage to Implementation: Why AI Fixes Need Gates
- 04Evidence Gate: Why AI Pull Requests Need Evidence Bundles
- 05PR Merged Is Not Done: The Release Boundary in AI Engineering
- 06Open-Sourcing an Issue-Driven Agent Workbench
Project-Specific AI Delivery Pipelines
Defines a project-specific AI delivery pipeline: AI acts as a worker while the project owns task intake, context, gates, evidence, and release boundaries.
- 00What a Project-Specific AI Delivery Pipeline Means
- 01From Chat Request to Task Contract: Route the Work Before AI Executes
- 02Give AI the Context It Should See, Not the Whole Repository
- 03Stage-Gated AI Workers Need Isolated Workspaces
- 04Evidence Contract: AI Delivery Must Come With Proof
- 05Put Humans at Risk Boundaries, Not Only at the Final Approval
- 06From AI Failure to Project Memory
AI Workbench for Designers
Explains why AI tools for designers should behave as durable workbenches, not just chatbots, image generators, or automatic drafting plugins.
Why AI Design Tools Need a Source of Truth
An open-source project connecting agent CLIs, an MCP server, a SketchUp Ruby bridge, structured design models, and runtime skills into a verifiable design workflow.
Evaluating Agent Workflows: Traces, Cost, Recovery
Connects trajectory evaluation, goal-level cost, semantic recovery, and confidence calibration into a practical evaluation frame for agent workflows.
AI Agent Operational Governance
Defines AI agent operational governance: the layer of authority, evidence, tools, traces, costs, and human gates that makes agents usable in real work.
Commitment Tracking and Agent Drift
Explains residual drift in long-running agent sessions and why serious workflows need commitment tracking, not just memory or contradiction checks.
Evidence and Source Authority
Shows how evidence-carrying actions and source authority rules prevent fluent text from overriding structured data, tool output, or source evidence.
Runtime Authority and Autonomy Gates
Explains why agent actions need runtime authority checks and autonomy gates, instead of relying only on plan-time approval or a confident task plan.
Tool Registries Are Control Surfaces
Treats MCP servers, plugins, tool descriptions, and dependencies as part of the agent control surface that needs governance and supply-chain review.
AI Won't First Take Your Job. It Will Take Your Execution Layer.
A companion essay on why AI's near-term impact may first appear as compressed execution work, narrower entry-level paths, and weaker labor leverage.
AI's Impact on Ordinary Work Is Not Eight Years Away
A personal essay on why a real issue-driven AI delivery workflow changed my timeline for AI's impact on ordinary work from eight to ten years to three to five.
Central KB, Project Directories, and Publication Nodes
Defines what the central knowledge base, project directories, and publication node each own, and why a single vault template is not enough for fact governance.
Why I Do Not Use Chat Logs as My Knowledge Base
Explains why chat logs are not a durable knowledge base and how Obsidian, local Markdown, Codex, project directories, and publication nodes form a federated system.
What Obsidian Actually Does in an AI Knowledge Base
Explains Obsidian's real role in an AI knowledge base: local Markdown, links, backlinks, and human review, not an automatic truth machine.
Boundaries: Privacy, Truth Sources, Audit, and Failure Modes
Summarizes the system boundaries and failure modes: privacy, project truth sources, premature automation, site truth drift, and AI output mistaken for evidence.
Why Project AI Should Not See the Whole Knowledge Base by Default
Explains why project AI should not read the whole central knowledge base by default and how local facts, narrow interfaces, and selective memory reduce risk.
AI Workbench for Designers: How Designers Should Work With AI
Explains why AI tools for designers should behave as durable workbenches, not just chatbots, image generators, or automatic drafting plugins.
Bridge Trace: Why Execution Should Be Planned Before Calling SketchUp
Explains why SketchUp execution should be planned as a bridge trace before calling the Ruby bridge, so agent actions remain inspectable and repairable.
How Codex Can Drive Verifiable SketchUp Modeling
Shows how an agent CLI, MCP server, SketchUp Ruby bridge, runtime skills, and a structured design model turn design intent into verifiable project state.
Why Codex Should Be a Worker, Not the Scheduler
Explains why Codex and similar AI coding tools should remain bounded workers, not long-running schedulers or release controllers.
Give AI the Context It Should See, Not the Whole Repository
Many AI task failures do not happen because the model cannot modify code. They happen because the model reads the wrong context.
Why design_model.json Has to Come Before the SketchUp Scene
Explains why the SketchUp scene is an execution view while the structured design model is better for agent reasoning, validation, repair, and replay.
A Designer's Core Value Is Judgment, Not Faster Drafting
Discusses how AI moves designer value from low-level execution toward goals, constraints, feedback, and version judgment.
Designers Should Think, Not Draft
A product and workflow essay arguing that AI should reduce low-level drafting work so designers can focus on intent, judgment, constraints, and tradeoffs.
Evidence Contract: AI Delivery Must Come With Proof
Explains why AI delivery must include verifiable proof: tests, logs, screenshots, risk notes, and a review path, not only a claim that work is done.
Evidence Gate: Why AI Pull Requests Need Evidence Bundles
Explains why AI pull requests should include reviewable evidence bundles, not just code changes and a claim that tests pass.
From AI Failure to Project Memory
Shows how repeated AI mistakes should become project memory, updated rules, and regression checks so the delivery pipeline improves after each failure.
From Chat Advice to a Durable Design Project
Explains why AI design collaboration needs project workspaces, structured truth, and resumable project state instead of chat history alone.
Use Labels, Branches, and Comments as an AI Engineering State Machine
Shows how GitHub labels, branches, and comments can become an AI engineering state machine that keeps issue repair work observable and controllable.
How to Verify an Agent Harness
Explains why an agent harness needs headless smoke, live bridge checks, release smoke, and installed package verification.
Put Humans at Risk Boundaries, Not Only at the Final Approval
Shows where humans should stand in an AI delivery pipeline: requirements, risk boundaries, release decisions, rollback choices, and final acceptance.
Stage-Gated AI Workers Need Isolated Workspaces
Explains why real projects should put AI work in isolated branches or workspaces, then move changes through explicit gates before they reach the main codebase.
An Issue Is Not a Todo: It Should Be an Executable Contract for AI
Argues that an issue should be an executable contract for AI work, with scope, context, gates, evidence, and release boundaries instead of a loose todo.
From MCP Server to SketchUp Ruby Bridge
Explains how the MCP server, execution trace, JSON-RPC, Ruby bridge, and feedback loop turn natural language into executable operations.
Open-Sourcing an Issue-Driven Agent Workbench
Explains how to safely extract public methodology, templates, and toy examples from private production AI workflow experience.
PR Merged Is Not Done: The Release Boundary in AI Engineering
Explains why a merged PR is not the end of AI engineering work; release verification, rollout checks, and post-merge evidence still define done.
What a Project-Specific AI Delivery Pipeline Means
Defines a project-specific AI delivery pipeline: AI acts as a worker while the project owns task intake, context, gates, evidence, and release boundaries.
Making Imports Repairable: From Source Evidence to Working Truth
Explains why plan import should preserve source evidence and generate repairable working truth instead of promising perfect recognition.
Runtime Skill Boundaries in an Agent Harness
Explains the product boundary between product runtime skills, project dynamic skills, and maintainer development skills.
Semantic Component Registry for Agent Placement
Explains why a SketchUp agent needs a semantic component registry that exposes placement intent, constraints, and reuse rules instead of only searching 3D model assets.
Why the Agent CLI Is Only the Entry Point
Explains why Codex and Claude are entry points while the durable SAH core is the MCP server, project workspace, bridge trace, and SketchUp bridge.
From Chat Request to Task Contract: Route the Work Before AI Executes
The most common risk in AI-assisted development is not that the model cannot write code. It is that the model starts writing code too early.
From Triage to Implementation: Why AI Fixes Need Gates
Explains why AI repair work should move through triage, analysis, implementation, evidence, and review gates instead of jumping straight to code.
How Visual Feedback Becomes Structured Design Changes
Explains how screenshots, renderings, and top views should become structured repair actions instead of another pile of untracked opinions.
Why AI Design Tools Need a Source of Truth
Uses SketchUp Agent Harness to explain why AI design tools need an editable, verifiable, repairable source of truth instead of only generating finished-looking output.
A personal site should be the source of truth
The operating rule for this site: publish the canonical version here, then adapt it outward to social platforms.
Private drafts, public artifacts
A note on separating raw material from publishable work when Codex is part of the workflow.