How I work with AI

The common picture of "working with AI" is a single chat window you ask for everything. That isn't how I work. Over the past months I've built a layer of 30 custom tools into my own working environment — each with a specific, bounded job — and wired them into the way the work already runs. The judgement on display isn't that they exist. It's how tightly they're scoped.

The operating layer, by job

This page is the map in words; for the single picture of how it all connects, see the system map. Each system below has its own write-up. The tools group into five jobs:

• Session & governance. The environment opens and closes each working session deliberately — loading the current state, surfacing unfinished threads, detecting drift at the end, capturing what was learned. A triage step screens incoming material with hard-enforced sensitivity rules. This is the layer that keeps the rest honest. → the rules are in the operating system I built for myself; the routines that run them in the routines that make the rules stick; intake in a triage gate for everything coming in.
• The diagnostic lab. A chain of specialist "advisors" — strategy, finance, technical, distribution, legal, customer-experience — that can be convened on a problem, plus a structured five-voice debate and a research step: a place to think a decision through from several angles at once. → The Diagnostic Lab.
• Quality gates. A communication-review step and a strategic-review gate that sit between thinking and building — explicit checkpoints, not afterthoughts.
• A learning system. Tools that turn podcasts, articles and courses into structured, searchable records, so exposure compounds into a durable knowledge base instead of evaporating. → making podcasts and courses compound.
• Retrieval. Question-answering grounded in my own material — workspace, decisions, notes — with citations back to source, rather than generic answers. → three kinds of memory.

Where I use agents — and where I don't

Some of this is genuinely agentic: the diagnostic lab runs as a sequence of stages with file-based handoffs between them, each stage's output visible before the next begins (progressive disclosure, not a black box). It can run autonomously end-to-end or interactively, a stage at a time.

But the design rule is consistent, and it's a rule about restraint:

• Narrow scope. Each tool does one job. There is no always-on agent with broad write access to everything — that optimises for momentum, which is the thing most worth resisting.
• A human approves anything that matters. Outputs are drafts. Nothing irreversible — sending, publishing, writing to a live database — happens without a person in the loop. In one live data pipeline, nothing reaches the database without human sign-off.
• The narrowest useful access. Where a tool connects to a real source — email, for instance — it's granted read-only. It can read and file; it physically cannot send, delete or change.
• Reversible by default. The powerful, tempting moves — full automation, broad permissions — are the ones deliberately designed out, not because they can't be built but because the failure modes aren't worth it.

AI-native, but constrained

Most of these aren't conventional tools with AI bolted on — they're designed around what AI is actually good at: retrieval over my own material, drafting in my voice, holding several specialist views on a problem at once. Knowledge Inbox OS is a product whose entire value is the retrieval and drafting. The diagnostic lab only exists because a model can argue six lenses at once. The operator system runs on AI doing the reading and synthesis. Built the old way, none of them would be worth building — that's what I mean by AI-native.

And it's the opposite of reckless. Building around AI and constraining AI are the same discipline, not opposing ones: the model is the substrate, and precisely because it's load-bearing, the guardrails below matter more, not less. AI-native, human-governed.

Why constrained beats capable

It would be easy to wire these tools together into something that does more, unsupervised. I chose the opposite on purpose. The capability is the easy part now; the judgement is in knowing where AI earns unsupervised action (almost nowhere that matters yet) and where a person stays in the loop (anywhere the cost of a mistake is real).

That's the same judgement a business needs when it puts AI near its own operations. The question is rarely "can we automate this." It's "should we, where exactly, with what guardrails, and who stays accountable." This is me answering that question for my own work — in the design of the tools, not in a slide about them.