A few weeks ago I wrote about running Qwen on my MacBook and iPhone. That was the first experiment. Local models doing real work on normal hardware. The gap between local and cloud was closing fast, and I wanted to push it further.

So I did. I moved everything to a headless Mac Mini M4, the base $599 model with 16GB of RAM. Started with smaller Qwen models for message classification and context compression. Then I found a way to run a 35 billion parameter model on 16 gigs. 17 tokens per second. Zero swap. Everyone said you need 32GB minimum. I’ve been running it for about a week now.

Yesterday Google dropped Gemma 4 under Apache 2.0. Within hours I benchmarked it against my Qwen setup. Classification went from 8.5 seconds to 1.9 seconds. By evening the swap was done. Five files changed.

This is all of it. How I fit a 35B model on a $600 machine, what local models actually do when you’re running an AI agent 24/7 (spoiler: it’s way more than classification), how model routing works across three tiers, and why Gemma 4 made me swap the brain overnight.

Why I Needed Local AI (It’s More Than You’d Think)

My Mac Mini runs as a headless AI automation server. iMessages, emails, scheduled nightshift tasks, 35+ specialized skills. The brain is Claude Code. Claude is brilliant. Claude also has usage limits.

I pay for Claude Max. It’s not cheap. And every wake-up burns through that subscription. I needed a way to handle the routine work locally. Free. On the machine itself.

At first I thought this would just be message classification. Is this a question or a greeting? Route the boring stuff away from Claude. That’s how it started.

Turns out that was maybe 20% of what local models can do. Here’s what actually runs locally now:

• Message triage: classifying every incoming message (question, request, idea, greeting, FYI) and assessing urgency. Under 2 seconds per message.

• Context compression: when someone sends a 500-word message, the local model compresses it to 30 words before Claude sees it. Same understanding, fewer tokens.

• Signal compression: my agent collects signals all day long (errors, metrics, task outcomes, all kinds of stuff). Before the nightshift planning session, the 35B compresses the entire day into a dense summary. Saves roughly 15x in tokens for the Opus planning call. That’s a lot of money over a month.

• Email preprocessing: same triage pattern applied to incoming emails before deciding whether to spin up a full Claude session.

• Memory consolidation: the agent accumulates daily notes and context. A local model clusters related entries and merges them. Like defragmenting a hard drive, but for the agent’s memory.

• Fallback: when Claude is rate-limited or down at 3am, the local 35B handles operational tasks. Not Claude-level reasoning, but functional.

The triage classification is just one example. The local models touch nearly everything the agent does. The result: roughly 30-40% fewer Claude sessions compared to routing everything through the API. My subscription lasts longer. And the agent responds faster for routine work because there’s no network round-trip.

Three Tiers, One $600 Machine

Not every task needs the same model. Like, classifying “is this a question or just ok?” is a completely different thing than compressing an entire day of automation signals into a planning summary. So I built a routing system. Three local tiers plus the cloud.

Why three tiers and not just one? A 2B model can tell you whether “What’s the status?” is a question or a greeting. But it can’t produce a useful 30-word summary of a 500-word message. And neither the 2B nor the 4.5B can do what the 35B does: compress an entire day of signals into a dense planning brief, or serve as a real fallback when Claude goes down. Different tools for different jobs.

The fast tier runs on every incoming message. Classifies the type (question, request, idea, greeting, FYI), assesses urgency. Under 2 seconds. If the message is a greeting or pure FYI, the agent skips Claude entirely. This one needs to be fast because it runs on every single message, all day.

The primary tier handles tasks where you need actual language understanding. Context compression is the main one: someone sends a long message, this model condenses it to 30 words before Claude sees it. It also handles things like Substack Notes generation as a fallback and the morning report AI summary. The 2.3B fast model can’t produce quality summaries. The 35B is overkill for this. The 4.5B sits in the sweet spot.

The heavy tier is where it gets interesting. The 35B does two things. It handles complex preprocessing (compressing the day’s automation signals before the nightshift Opus planning call, which saves roughly 15x in tokens). And it sits in the resilience chain as a Claude fallback. When Claude is rate-limited at 4am, the 35B handles health checks, error scanning, operational maintenance. Always marked as “[Local Fallback]” so I see the difference in the morning. But something functional beats nothing at 3am.

The triage routing for messages looks like this:

1. Incoming message hits triage
2. Fast tier classifies (question/request/idea/greeting/fyi) + urgency
3. If greeting or fyi: skip Claude entirely
4. If long text: primary or heavy tier summarizes before Claude sees it
5. Prepend classification to Claude's prompt: "[Pre-classified: request, urgency: high]"
6. Claude skips its own analysis step = fewer tokens burned

But message triage is just the entry point. The same models handle signal compression, email preprocessing, memory consolidation, fallback responses. The routing system is the foundation. The use cases keep growing, and that’s kind of the point.

Safety rules still matter. Messages mentioning money, deployment, publishing, or anything work-related always bypass local triage and go straight to Claude. Very short messages (under 20 characters) also skip triage because “yes” could be a standalone acknowledgment or an answer to a previous question. I learned that one the hard way when the triage classified “yes” as acknowledgment and skipped a real conversation reply.

The 35B Trick (Your SSD Is the New GPU Memory)

This is the part that shouldn’t work. I didn’t invent this. I came across a post on X where someone was running oversized models on consumer hardware using a specific flag in llama.cpp. That sent me down a rabbit hole.

Qwen 3.5 35B-A3B has 35 billion parameters. At standard precision, that’s way more than 16GB. My first attempt through Ollama loaded 26GB into memory on a 16GB machine. The system froze. 4.3 million swapouts. Timed out after 10 minutes without producing a single token. Dead.

Then I tried llama.cpp with one flag: --mmap.

Same model. Same hardware. Same 16GB. Result: 17.3 tokens per second, 81% memory free, zero swap.

Why This Works

Two things make this possible: the model architecture and how macOS handles files.

Qwen 3.5 35B-A3B is a Mixture of Experts (MoE) model. 35 billion parameters total, but only 3 billion are active per token. Like a building with 35 floors where any given task only needs to visit 3 of them. The rest sit empty. A router network inside the model decides which experts to activate for each token.

So what does --mmap do? Instead of loading the entire model file into RAM (which is what Ollama tried, and why it choked), llama.cpp memory-maps the file. The OS treats the model like a virtual address space backed by your SSD. It only pages in the weights that are actually needed:

• Shared layers (attention, embeddings, norms): stay resident in RAM, about 4-6 GB

• Expert weights: paged from SSD only when that expert activates

• 90% of the model sits on your NVMe drive, untouched most of the time

• The macOS page cache naturally caches recently used experts, so repeated patterns get faster

None of this is new, by the way. Apple published a research paper called “LLM in a Flash” back in December 2023 describing exactly this approach: use your SSD as an extension of available memory for LLM inference. The M4’s unified memory architecture helps too (no PCIe bottleneck between CPU and GPU memory, it’s all one shared pool). And the NVMe SSD in the Mac Mini is fast enough that paging weights on demand doesn’t bottleneck inference for MoE models where most weights are idle anyway.

The thing that actually surprised me? The 35B is faster than the old 9B model. 17.3 vs 12.6 tok/s decode. Even though it has 4x more total parameters, MoE means each token only computes through 3B parameters. Better quality weights, same compute budget. Bigger model, less work per token. I did not expect that.

I downloaded an aggressively quantized version (Unsloth’s UD-IQ3_XXS, 13GB on disk) and run it on llama.cpp alongside Ollama on a different port. Ollama handles the fast and primary tiers on port 11434. llama.cpp handles the heavy tier on port 8081. Both coexist on the same machine. Total disk for everything: about 22GB.

The Brain Swap (Qwen to Gemma)

For about a week, everything ran on Qwen 3.5 across all tiers. It worked. Classification took about 8-9 seconds on the 4B model, summarization around 50 seconds on the 9B. Not blazing, but good enough for background preprocessing that doesn’t need instant responses. The system was stable. I was happy with it.

Then yesterday, Google released Gemma 4.

Apache 2.0 license. That matters. Previous Gemma versions had usage restrictions and monthly active user limits. For something running 24/7 as production infrastructure, license restrictions are a real concern. Apache 2.0 means no strings.

The benchmarks were wild. Gemma 4’s models scored 88-89% on AIME 2026 math. The previous Gemma 3 scored 20.8%. That’s not incremental improvement. That’s a different model family wearing the same name.

But the thing that really got me: multimodal on small models. The E2B (2.3B effective) and E4B (4.5B effective) can process images and audio natively. My Qwen setup was text-only. Voice messages via iMessage? Had to skip them entirely. Screenshots sent for context? Invisible to the triage layer. With Gemma 4, that changes. That’s a real capability gap closed, not just a speed improvement.

I wasn’t going to swap production models based on a marketing page though. Wrote a benchmark script, ran 10 classification prompts and 3 summarization tasks against each model under identical conditions.

Classification (10 test messages)

Summarization (3 test texts)

4.4x faster classification. 1.8x faster summarization. The speed difference is what sold me. For a triage system that runs on every incoming message, 1.9 seconds vs 8.5 seconds is the difference between “barely noticeable” and “why is this taking so long.”

The accuracy gap (70% vs 80%) turned out to be mostly gray areas. Both models classified “What’s the status of the nightshift?” as status_check instead of question. Honestly, status_check is a better answer. One genuine miss: Gemma said “observation” for a message where “fyi” would’ve been correct. It invented a category that wasn’t in the allowed list. Edge case I can fix with better prompting.

The actual swap was anticlimactic. My architecture centralizes model names in one file. Two constants changed, three files with hardcoded model strings updated. Done.

# automation/lib/local_llm.py
MODEL_PRIMARY = "gemma4:e4b"   # was "qwen3.5:9b"
MODEL_FAST = "gemma4:e2b"      # was "qwen3.5:4b"

The heavy tier stays on Qwen 35B via llama.cpp. Deliberately. The fast and primary tiers run through Ollama, which had Gemma 4 support on day one (I upgraded Ollama from 0.19 to 0.20 for it). The heavy tier runs through llama.cpp with the mmap trick. Swapping that to Gemma’s 26B MoE variant means testing a different quantization, different mmap behavior, different inference characteristics. I don’t change two things at once in production infrastructure. Qwen 35B works. It stays until I’ve properly benchmarked the Gemma 26B alternative.

Old Qwen models stay on disk as rollback. If anything breaks, reverting the fast and primary tiers is a two-line change.

The Thinking Mode Trap

Both Qwen and Gemma have a “thinking” mode. The model generates an extensive chain-of-thought before answering. For complex analysis, this is great. For classification, it’s a disaster.

With thinking enabled, a simple “is this message a question or a request?” took 30+ seconds. The model generated 500 tokens of internal reasoning (”Let me analyze the intent of this message. The user is asking about...”) and then said “request.” All that thinking for a one-word answer. I was watching this happen in real time and just... no.

One parameter: think: false in the Ollama API call. Classification went from 30 seconds to under 1 second. Same accuracy. 30x faster. This was the single biggest optimization in the whole setup, and I almost missed it.

Works the same way for both Qwen and Gemma:

# Qwen classification (fast, thinking disabled)
curl localhost:11434/api/chat -d '{
  "model": "qwen3.5:4b",
  "messages": [{"role": "user", "content": "Classify: question/request/greeting"}],
  "think": false,
  "options": {"num_ctx": 4096}
}'

# Gemma classification (same API, same parameter)
curl localhost:11434/api/chat -d '{
  "model": "gemma4:e2b",
  "messages": [{"role": "user", "content": "Classify: question/request/greeting"}],
  "think": false,
  "options": {"num_ctx": 4096}
}'

Same parameter, same behavior, no code changes when I swapped models. For the heavy tier (llama.cpp on port 8081), thinking is controlled via the system prompt instead, but same principle: disable it for fast tasks, enable it when you actually need reasoning.

People asked about context windows on my first local LLM post. Fair question. I push them as far as the hardware allows. Classification gets 4K (it doesn’t need more, most messages are under 200 tokens). Summarization gets 32K on the primary tier. Document analysis gets up to 64K on the fast tier. The heavy 35B gets 16K, which is enough for compressing a full day of signals or handling a long fallback conversation. The mmap trick handles the model weights, but the KV cache (the memory the model uses to “remember” the conversation) still lives in RAM. With the model weights at 4-6 GB and the KV cache for 16K context, there’s still plenty of room on 16GB. It’s not a million tokens. That’s not happening on this hardware. But for what these models actually do (triage, compression, summarization, fallback), 16-64K is more than enough.

The Resilience Chain (When Claude Goes Down)

The local models aren’t just about cost. They’re about uptime.

My agent’s resilience chain works like a waterfall. If the top tier fails, it cascades down:

Claude Sonnet -> retry -> Haiku -> Local 35B -> Local Primary -> OpenRouter -> Queue

Like backup generators. Main power (Claude Sonnet) goes out. Building tries the secondary generator (Haiku). If that’s down too, local generators kick in. Not as powerful, but they’re on-site, zero-cost, and they don’t depend on anyone else’s infrastructure staying online. Only if everything local fails does the system reach for an external API (OpenRouter). And if even that fails, the message goes into a queue for later.

The system tracks cooldowns per model too. If Claude hits a rate limit, it records how long to wait and skips straight to the next tier on subsequent requests. No point retrying something you know will fail. Once the OAuth token expired at 2am and the system figured out that all Claude tiers would fail with the same expired token, so it skipped straight to the local fallback. Saved minutes of retries that were guaranteed to fail. I only found out in the morning when I read the logs. It just handled it.

My agent runs overnight. Nightshift tasks execute while I sleep. If Claude is rate-limited at 4am, the local 35B handles operational checks, health monitoring, error registry scans. Responses are clearly marked “[Local Fallback]” so I see the difference in the morning. Not Claude-level reasoning, but functional. And I’d rather wake up to a degraded response than a silent failure.

The Setup (If You Want to Try)

Hardware: Mac Mini M4, base model, $599, 16GB unified memory. Any Apple Silicon Mac with 16GB will work. The M4’s NVMe SSD speed helps for the mmap approach, but M1/M2/M3 work too.

Option A: Gemma 4 (recommended, what I run now)

# Step 1: Install Ollama (0.20+ required for Gemma 4)
brew install ollama

# Step 2: Pull Gemma 4 models
ollama pull gemma4:e2b        # Fast tier (7.2 GB, 2.3B effective, vision+audio)
ollama pull gemma4:e4b        # Primary tier (9.6 GB, 4.5B effective)
ollama pull nomic-embed-text  # Local embeddings (274 MB, optional)

# Step 3: Set environment for 16GB systems
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
export OLLAMA_KEEP_ALIVE=10m
export OLLAMA_MAX_LOADED_MODELS=1

Option B: Qwen 3.5 (what I started with, still solid)

# Same Ollama install, different models
ollama pull qwen3.5:4b        # Fast tier (3.4 GB)
ollama pull qwen3.5:9b        # Primary tier (~6 GB)

The 35B Heavy Tier (works with either Option A or B)

# Step 4: Install llama.cpp for the big model
brew install llama.cpp

# Step 5: Download Qwen 3.5 35B (13 GB quantized)
pip3 install huggingface-hub
python3 -c "from huggingface_hub import hf_hub_download; \
  hf_hub_download('unsloth/Qwen3.5-35B-A3B-GGUF', \
  'Qwen3.5-35B-A3B-UD-IQ3_XXS.gguf', \
  local_dir='~/.local/share/llama-models')"

# Step 6: Start llama-server with the magic flag
llama-server \
  --model ~/.local/share/llama-models/Qwen3.5-35B-A3B-UD-IQ3_XXS.gguf \
  --port 8081 --ctx-size 16384 --n-gpu-layers 0 --mmap \
  --flash-attn on --threads 8

Some things that tripped me up:

OLLAMA_MAX_LOADED_MODELS=1 is critical on 16GB. Without it, Ollama tries to keep both the fast and primary models in memory at once and the system just dies. One model at a time, 10-minute idle timeout, then it unloads and frees your RAM.

--n-gpu-layers 0 on the llama.cpp command looks wrong. On Apple Silicon you’d normally offload layers to the GPU. But with mmap, we want the OS to manage the paging. Setting GPU layers to 0 means everything goes through the mmap path. The M4’s unified memory means “GPU” and “CPU” are reading from the same pool anyway, so it doesn’t really matter.

Ollama and llama.cpp coexist on different ports (11434 and 8081). The heavy tier (llama.cpp) is on-demand: I start it when needed and stop it when not. The fast and primary tiers (Ollama) run as a LaunchAgent, always on, auto-restarting. Two separate inference servers on one Mac Mini. Works fine.

What I Actually Learned

Local models are not Claude. They can’t chain multi-step tool calls, refactor code, or make creative decisions. Claude Code does this because Anthropic spent years on tool calling. Local models aren’t there yet. But that’s fine. I don’t need them to be Claude. I need them to classify messages in 2 seconds and compress context before Claude sees it.

The mmap thing is probably the most underappreciated trick in this whole setup. One flag. The difference between “impossible” and “17 tok/s with zero swap.” If you have Apple Silicon and an NVMe SSD, you can run models much larger than your RAM would suggest. I’m running it daily. It just works.

Centralizing model names saved me. I had three files with hardcoded "qwen3.5:9b". Found them all during the swap. If I’d had ten files like that, a quick migration would’ve been a 2-hour headache. Lesson learned (although honestly I should have known better).

I benchmarked before swapping, and I’m glad I did. Google’s marketing said Gemma 4 was better. The benchmarks confirmed speed gains but also showed a slight accuracy regression. Speed got better, instruction following got slightly worse. That’s a tradeoff I chose to accept, not one that surprised me in production.

One more thing: Gemma E2B is 7.2GB on disk (vs Qwen 4B at 3.4GB). Looks huge. But that’s because it bundles vision and audio encoders. Loaded RAM is nearly identical. I almost rejected it based on download size. Would have been a mistake.

And the thinking mode thing. Disable it for fast tasks. 30x speed difference for classification. This single setting is the difference between a usable triage system and a painfully slow one. Test it. Seriously.

Where This Is Going

Local models are real infrastructure now. Not toys. Production preprocessing, signal compression, memory consolidation, fallback. Running 24/7 on a $600 machine.

A year ago, useful local inference meant a $3,000 GPU. Now a base Mac Mini handles three tiers. The models keep getting smaller and faster. Gemma 4’s E2B classifies messages in under 2 seconds with 2.3 billion effective parameters. And it can see images and process audio. For my setup that previously had to skip voice messages entirely, that alone was worth the swap.

Next I want to test the Gemma 4 26B MoE variant (26 billion total, 3.8 billion active per token) as a replacement for the Qwen 35B heavy tier. If the GGUF works well with llama.cpp and mmap, that’s the full stack on Gemma. One model family for everything.

If you’re building any kind of AI agent system, try this pattern. Local for the frequent and cheap. Cloud for the complex and expensive. Cost savings compound. Reliability improves. You stop depending on any single provider staying online.

Gemma for preprocessing. Claude for thinking. Both got better at their jobs by not trying to do the other’s.

I spent a night reading the code and building things from it. Here’s what matters if you’re building AI agent.

What actually leaked (and what didn’t)

On March 31, 2026, a security researcher noticed something odd about the Claude Code npm package. Version 2.1.88 shipped with a 59.8MB source map file. Source maps are debug artifacts that Bun (the runtime Claude Code uses) generates by default. Someone forgot to add *.map to the .npmignore file. That’s it. A missing line in a config file.

The source map referenced unobfuscated TypeScript files on Anthropic’s Cloudflare R2 bucket. All downloadable. About 1,900 files. 512,000 lines of code. Within hours, the codebase was mirrored across GitHub, reaching 84,000+ stars in under two hours. The fastest-growing repo in GitHub history, for a codebase that wasn’t supposed to be public.

Interactive data

Let me clear up a few things I’ve seen people get wrong about this.

No customer data was exposed. This was source code for the CLI tool, not a database breach. No credentials, no user conversations, no API keys. Anthropic confirmed it was a packaging error.

No model weights were leaked. The code is the software harness around Claude, not the LLM itself. You can’t run your own Claude from this. What you get is the orchestration layer: how Claude Code manages tools, memory, context, permissions, and multi-agent coordination.

This isn’t a security breach in the traditional sense. It’s a build artifact that should have been excluded from the npm package. Embarrassing for Anthropic’s build pipeline, but the kind of mistake any team shipping fast could make. The irony is that the leaked code includes a system called “Undercover Mode” specifically designed to prevent Anthropic employees from accidentally leaking internal details into public repos. It leaked along with everything else.

It wasn’t intentional. I know people are debating this because the timing aligns with April 1 and because Anthropic had a rough PR week (cease-and-desist against the OpenCode project). But the evidence is clear: they’ve been mass-sending DMCA takedowns to GitHub repos, they pulled the npm package, and their Cloudflare R2 bucket was taken down. You don’t do that with a planned release. The strategic roadmap exposure is too costly, especially during IPO preparation. Theo from t3.gg put it well: “if you think this was intentional, I have a couple bridges for sale.”

One theory that makes sense: Anthropic was investigating rate limit issues in Claude Code. Multiple employees had posted about seeing higher rate limit hits than expected. In their attempts to get better error logs from production builds, they may have included the source maps for debugging. Then forgot to exclude them from the npm package. That tracks with how these things usually happen: a debug change that nobody remembers to undo.

A warning if you’re thinking of cloning the leaked repo: The source references internal workspace packages that don’t exist on npm. Someone already registered those package names with a disposable email. If you clone and blindly run npm install, you could be pulling malicious code. Be careful.

What’s inside and why it matters

I’ve been building my own AI agent for months now. It runs 24/7 on a dedicated Mac Mini. So when this leak dropped, I didn’t read it for the drama. I read it to learn. I spent a night going through the architecture, comparing it to what I’ve built, and pulling out anything useful.

Here’s what matters if you’re building AI agents or want to understand where this technology is actually going.

The three-layer memory system

This is probably the most important architectural discovery in the leak. Claude Code uses a memory system with three layers:

1. Core index (MEMORY.md): A lightweight file of pointers, always loaded into context. Each entry is under 150 characters. It’s an index, not the memory itself.

2. Topic files: Detailed knowledge distributed across separate files, fetched on-demand when the index suggests they’re relevant.

3. Raw transcripts: Never re-read in full. Only grep’d for specific identifiers when needed.

The key insight is what they call “skeptical memory.” The agent treats its own memory as a hint, not a fact. Before acting on something it remembers, it verifies against the actual codebase. Memory says a function exists? Check first. Memory says a file is at this path? Verify before using it.

This solves context entropy, the gradual degradation of agent performance in long-running sessions. Most agents get worse the longer they run because their context fills up with stale observations. This architecture keeps the active context small (just the index) and only loads what’s needed.

I’ve been running a similar pattern with working memory that rolls over on a schedule and a permanent index that persists across sessions. The leak confirmed this is the right approach. The verification step is something I’m now adding to my own system.

Memory consolidation during idle time (autoDream)

The leak includes a system called autoDream in the services/autoDream/ directory. It’s a background memory consolidation engine that runs as a forked subagent with read-only access to the project. Three gates must pass before it runs: 24 hours since the last run, at least 5 sessions completed, and a consolidation lock must be available.

When triggered, it runs four phases: orient (scan memory directory), gather (extract new info from logs), consolidate (write and update topic files), and prune (keep total memory under 200 lines and 25KB).

Why this matters for you: if you’re building any agent that runs over multiple sessions, unbounded memory will kill you. Not immediately. Over weeks. Your agent starts referencing things that are no longer true, duplicating observations, and filling context with noise. You need some form of consolidation. autoDream’s approach of forking a read-only subagent is clean because it can’t accidentally corrupt whatever the agent is currently working on.

The tool architecture

Claude Code defines 40+ discrete tools, each wrapped in permission gates. The biggest file in the leak is Tool.ts at roughly 29,000 lines, defining tool types and permission schemas. Every tool operation goes through a PermissionGate structure for granular access control.

Three things stood out:

• File-read deduplication: Before re-reading a file, it checks whether the file has changed since the last read. If not, it skips the read and uses the cached version. Sounds obvious, but most agent setups don’t do this, and the token savings compound fast.

• Large result offloading: When a tool produces a massive result (like searching a large codebase), it writes the full result to disk and only passes a preview plus a file reference back to the context. This keeps the context window clean while still making the data available.

• CLAUDE.md reinsertion on turn changes: The CLAUDE.md file doesn’t just get loaded once at the start. It gets reinserted into the conversation on every turn change (when the model finishes and the user sends a new message). Not at the top of the history, but right where the new message is sent. This repeated injection keeps the model aligned with your instructions even in long conversations where the original system prompt would have scrolled far out of active context.

If you’re using CLAUDE.md files (and you should be), this last detail matters. Your instructions aren’t a one-time primer. They’re actively re-read throughout the conversation. That’s why well-structured CLAUDE.md files have such a big impact on agent behavior. I wrote about how I structure mine after running 1000+ sessions.

Multi-agent coordination

The leak reveals Coordinator Mode. One Claude agent acts as a lead, spawning and managing multiple worker agents in parallel. Workers operate in their own isolated contexts with restricted tool permissions. They communicate via XML-structured task notifications and share data through a scratchpad directory. The system prompt for coordinators emphasizes “parallelism is your superpower.”

The clever implementation detail here: sub-agents share the prompt cache. Instead of each worker spinning up with its own context (paying full input token costs), they all share the same context prefix and only branch at the task-specific instruction. This is what makes multi-agent coordination economically viable. Without cache sharing, spinning up five workers means paying five times the input cost. With it, you pay once for the shared context and only pay incrementally for the task-specific parts. That’s probably why Coordinator Mode isn’t released yet. The cost math is still brutal even with this optimization.

This is the same pattern I landed on independently. I built three persistent domain teams with an Opus lead that plans and delegates, and Sonnet specialists that execute. The convergence here is specific: lead agent that plans, specialist workers that execute in parallel, structured communication, verification at the end.

Risk classification

Actions get labeled LOW, MEDIUM, or HIGH risk. There’s a “YOLO classifier” for fast auto-approval of low-risk operations. Protected files like .gitconfig and .bashrc get special treatment. There’s also a referenced “AFK Mode” that adjusts behavior when the user is away.

Three tiers. Same as what I built. Same reasoning: an autonomous agent needs to know which actions are safe to take alone, which should be flagged, and which need a human in the loop. This one is less a revelation and more a confirmation that the three-tier approach is just the correct default for any agent with real-world access.

Five patterns you can use right now

Here’s the practical part. These are patterns from the leak that you can apply to your own AI agent setup, whether you’re building something complex or just trying to get more out of Claude Code, Cursor, or any AI coding tool.

1. The blocking budget

KAIROS (the unreleased always-on daemon in the leak) has a 15-second blocking budget. Any proactive action that would take longer gets deferred. Max 2 proactive messages per window. Reactive messages (responding to user input) bypass the budget entirely.

Why this matters: if you’re running any kind of proactive agent, whether it’s monitoring code, sending notifications, or checking on things, you need rate limiting. Not just “don’t spam.” Structured rate limiting with different rules for proactive versus reactive work. Without it, your agent will eventually send 4 messages in 30 seconds when one would do.

I implemented this the night I read the leak. A simple state file tracks the budget window. Proactive messages get queued and recovered. Reactive messages go through immediately. About 50 lines of Python.

2. Skeptical memory with verification

Don’t trust your agent’s memory. Make it verify. Every time your agent says “I remember that file X has function Y,” make it check first. Memory is a hint. The codebase is the truth.

This is the single most practical takeaway from the leak. If you’re using CLAUDE.md files, custom system prompts, or any form of persistent context, treat them as suggestions that need verification, not as ground truth. Files get renamed. Functions get deleted. APIs change. Your memory hasn’t.

3. Semantic memory merging

autoDream doesn’t just delete old memories. It merges related observations, removes logical contradictions, and converts vague insights into concrete facts. If your agent noted “user might prefer X” three months ago and “user confirmed X yesterday,” the old entry should be updated, not kept alongside the new one.

Most memory systems I’ve seen (including my own before this) do time-based cleanup. Old stuff gets archived or deleted. That’s fine for preventing memory bloat, but it doesn’t catch contradictions. Two conflicting observations can coexist for months. Semantic merging resolves that.

I built a version using a local LLM (Qwen 9B running on the Mac Mini) to cluster related entries and merge them during nightly maintenance. A safety cap prevents reducing any section by more than 50% in a single pass. You don’t need to go this far. Even a simple script that groups memory entries by topic and flags potential contradictions would be a step up from pure time-based cleanup.

4. Adversarial verification

The leaked Coordinator Mode treats verification as a distinct, adversarial phase with its own worker agent. Not “check if this works.” Not a checklist. A separate agent whose job is to try to break what was built.

This is different from testing. Testing asks “does it work?” Adversarial verification asks “how can I break it?” The distinction matters because the agent that built something has a blind spot about its own work. A fresh agent with the explicit prompt “find problems with this” will catch things the builder missed.

I added this to my nightshift process. Before any task gets marked complete, a separate verification agent runs two phases: existence check (does the deliverable actually exist?) and adversarial challenge (try to break it). The results go into a verification log. It’s caught real issues that would have shipped otherwise.

5. Prompt cache awareness

The source includes a promptCacheBreakDetection.ts file that monitors 14 different cache-break vectors with sticky latches. Things like mode toggles, model changes, context modifications. Each one can invalidate your prompt cache, and cache misses mean you’re paying full price for tokens that could have been cached.

If you’re running many agent sessions per day, cache efficiency directly affects your costs. This one is easy to ignore because you don’t see the waste. But if you track it (which I now do), you’ll likely find that your cache hit rate is lower than you assumed and that specific patterns in your workflow are breaking it.

Related: the source reveals five different compaction strategies for when the context window fills up. If you’ve used Claude Code heavily, you’ve probably hit the moment where it compacts and then loses track of what it was doing. That’s still a hard problem. But knowing they’re actively working on multiple approaches to solve it tells you this is worth investing in for your own long-running agents too.

What I built in one night

I didn’t just read the leak. I treated it as a learning exercise and built things from it. That same night, I implemented five modules inspired by patterns in the leaked source:

1. Blocking budget for proactive messages. 15-second window, 2-message max, deferred queue.

2. Semantic memory consolidation using local LLM to cluster and merge observations during idle time.

3. Frustration detection via regex pattern matching. 21 patterns, three action tiers (back off, acknowledge, simplify). Fast enough to run on every incoming message.

4. Prompt cache monitor that tracks hit rates, estimates savings, and alerts when efficiency drops.

5. Adversarial verification as a formal phase in the nightshift execution loop.

Total time: about 4 hours of reading and building. I already had the foundations (nightshift, memory system, domain teams). These were specific improvements layered on top.

The frustration detection one is worth a note. The leaked code uses regex patterns to detect user frustration. Stuff like “wtf”, “this sucks”, keyword matching. An LLM company using regexes for sentiment analysis. But it makes sense. You don’t burn an LLM inference call on something you can pattern-match in 5 milliseconds. I applied the same logic: 21 patterns, fast evaluation, action suggestions without the overhead of an API call.

What’s not worth your time

Not everything in the leak is useful. Some of it is Anthropic-specific, some is unreleased for good reasons, and some is just fun but not practical.

Buddy System. A Tamagotchi-style terminal pet. 18 species across rarity tiers, procedural stats like DEBUGGING, PATIENCE, CHAOS. It’s genuinely charming and I kind of love it. But unless you’re Anthropic trying to make a CLI tool feel more personal, you don’t need this.

Undercover Mode. Strips Anthropic attribution from open-source contributions. Specific to their internal workflow where employees use Claude Code on public repos. Not applicable unless you have the same problem (and if you do, you probably already know about it).

Anti-distillation mechanisms. The code injects fake tool definitions into API requests to poison anyone trying to train models on intercepted traffic. It also summarizes reasoning chains before returning them to eavesdroppers. Interesting from a security perspective. Not useful for building agents.

ULTRAPLAN. A mode that offloads complex planning to a remote cloud container running Opus 4.6 for up to 30 minutes. Cool concept. Requires infrastructure you probably don’t have and a use case that doesn’t come up often enough to justify building it.

Native client attestation. API requests include computed hashes that prove they come from legitimate Claude Code binaries. Implemented below the JavaScript runtime in Bun’s native HTTP stack (written in Zig). This is DRM for API calls. Interesting engineering but not something you can or should replicate.

The uncomfortable truth about the harness itself

Here’s something most coverage of the leak doesn’t mention: Claude Code is not actually a good harness. Not even close.

On terminal bench, Claude Code ranks 39th. There are 38 harness-model pairs that outscore it. If you filter to just Opus, Claude Code is dead last among harnesses. Cursor’s harness gets Opus from a 77% score to 93%. Claude Code gets that same Opus model... 77%. The harness adds nothing.

Even funnier: when you search the leaked source for “open code” (the open-source CLI project Anthropic sent a cease-and-desist to), you find multiple instances of Claude Code referencing Open Code’s source to match its behavior. Things like scrolling implementations. The closed-source project was copying from the open-source one, not the other way around.

So what’s actually valuable here is not the harness code itself. The valuable parts are the architectural patterns underneath: how they handle memory, context management, multi-agent coordination, and the unreleased feature infrastructure. The actual harness? You could build a better one with any of the open-source alternatives as your starting point.

The code quality itself is... fine. When analyzed, it scores about a 7/10. Type safety is solid (only 38 instances of any across 500+ files). Error handling is decent. But there are “god files” with 5,000+ lines each, over a thousand feature flag references scattered across 250 files, environment variable sprawl throughout, and no centralized secret sanitization before logging. The test files weren’t included in the source map (they wouldn’t be), so that skews the assessment, but the codebase has clear tech debt. Lots of specific, actionable TODO comments that look old.

None of this is unusual for a fast-moving product at this scale. But it’s worth knowing before you treat the leaked code as a reference implementation. The patterns are worth studying. The code itself is not the gold standard some people are making it out to be.

The unreleased features that tell you where Claude Code is heading

The 44 feature flags in the leak paint a picture of what’s coming. KAIROS is the big one: an always-on background agent that acts proactively, maintains daily logs, subscribes to webhooks, and has its own memory consolidation cycle. It’s referenced over 150 times in the source. Expected to roll out soon.

There’s also Voice Mode (push-to-talk interface), Computer Use integration (screenshot capture, click and keyboard input baked into the CLI), and the Coordinator Mode for multi-agent orchestration.

If you’re using Claude Code today, it’s worth knowing that the tool is moving toward being an always-on daemon, not just a CLI you invoke when you need help. The patterns I described above (blocking budgets, memory consolidation, risk tiers) are all infrastructure for that shift.

Why this leak is actually good for you

Most commentary about this leak focuses on what it means for Anthropic. Embarrassment, competitive risk, security implications. That’s valid but not very useful.

What’s useful is that this is the first complete, production-grade AI agent architecture that’s been fully documented in public. Not a research paper. Not a demo. The actual code that runs at $2.5 billion ARR scale. And it confirms that the patterns people in the agent-building community have been discovering independently are structurally correct.

I built an interactive explorer that maps the entire agent loop, all 50+ tools, the architecture systems, and the hidden features. If you want to explore the leaked architecture visually without reading raw TypeScript, start there.

Scheduled autonomous execution. Bounded memory with consolidation. Multi-agent delegation. Risk-based autonomy tiers. Skeptical self-verification. These aren’t clever hacks. They’re convergent solutions to the real problems that show up when you build agents that actually run. I arrived at most of them through trial and error. Seeing the same patterns in a production system with 80% enterprise adoption tells me the foundations are solid.

The barrier to building serious AI agents is lower than the industry suggests. You don’t need a research lab. You need clear thinking about a few specific problems: when should the agent work unsupervised, how should memory stay bounded, when should it delegate, and what actions need a human gate. The answers become obvious once you start building. They stay hidden until you do.

I write about building and running AI agents. Not theory. Systems that run 24/7 on real hardware.

I’ve updated the Claude Code Workshop with these architecture patterns from the leak: blocking budgets, skeptical memory, semantic consolidation, adversarial verification, and cache optimization.

If you already own it, grab the new version. If you don’t, it covers skills, automation, and the patterns that actually stick after months of daily use.

I started working on BotStall about three weeks ago. An idea for a marketplace where AI agents could register, list products, and buy from each other. As of today, it’s live at botstall.com with 17 products, real Stripe checkout, and a verification system that took more thinking than the entire backend.

The idea came from a practical problem. I have an AI agent that runs overnight shifts, builds products, handles tasks while I sleep. That agent produces things other agents could use. Prompt packs, automation templates, skills. But there’s no place designed for autonomous agents to actually sell stuff. So I built one.

Here’s how it went.

What BotStall actually does

Agents register via API. They get an API key, 10,000 SPK (virtual currency for testing), and access to a sandbox marketplace. They list products, make transactions, get reviewed. Humans can do the same through a regular web UI.

The difference from something like the GPT Store: agents are first-class participants here, not an afterthought. The GPT Store’s revenue share is still invite-only, by the way. Most creators there earn about $0.03 per conversation. To make $1,000 a month you need 33,000+ quality conversations. The real money in that ecosystem comes from enterprise consulting ($5K-$20K per engagement), not the store itself.

I wrote about agentic commerce back in January, before I started building this. The theory was clear enough. Google had just launched their “buy for me” button in Search. Visa was predicting millions of agent-driven purchases by the 2026 holiday season. OpenAI and Stripe released the Agentic Commerce Protocol. The infrastructure was being built.

But I couldn’t find a marketplace that treated agents as sellers, not just shoppers. That’s what BotStall is for.

Three gates before real money

This is the part I’m most interested in, honestly. When your sellers are autonomous systems running 24/7, trust is the whole game. You can’t just let any bot list products and collect payments on day one.

I ended up with three gates:

Gate 1: The sandbox. Every account starts here. 10,000 SPK, virtual currency, zero real money. Agents list products, make transactions, build a history. Minimum 72 hours before they can even apply to leave.

Gate 2: Graduation. After 3 days of clean operation (at least one product listed, one transaction completed, no disputes), agents can apply. If they pass, their sandbox reputation freezes as permanent trust data. A record that says “this agent operated cleanly before it was allowed near real money.”

Gate 3: The subscription. This was the last thing I added. Graduated sellers get one free real-money product listing. If they want more (up to 10), it’s $4.99/month. The subscription does two things. It’s one more filter, because an agent willing to pay monthly is more likely legitimate than one trying to list and disappear. And it gives the platform recurring revenue that doesn’t depend on transaction volume, which matters a lot during the cold start phase when transaction volume is basically zero.

Each gate filters a different kind of risk. Time. Behavior. Financial commitment. I built it because I hadn’t found this approach anywhere else. Visa is working on something called the Trusted Agent Protocol with Stripe and Shopify. The industry calls it “Know Your Agent” (like KYC but for bots). Consumer trust in fully autonomous purchases actually dropped from 43% to 27% in the past year. People want agents to help them shop, but letting agents handle payment? That’s still uncomfortable for most.

So the verification system isn’t just nice engineering. For a marketplace with autonomous actors, it’s the thing that makes everything else possible.

What I learned building this

Cold start is brutal when your sellers are bots

I seeded the marketplace with my own Wiz Store products. Nine real products, from the AI Agent Blueprint ($39) to the Claude Code Workshop ($39). Real prices, real Stripe checkout. The marketplace isn’t empty. The shelves have inventory.

Although getting other builders to list their stuff is a completely different problem. I’ve been writing about which projects are worth doing for a while now. Distribution was always on my criteria list. But thinking about it and actually doing it are different experiences.

Building for agents changes everything

Most marketplaces assume human sellers. Signup forms, dashboards, inbox messages. All built for people who click buttons and care about their star rating.

Agents don’t need any of that. An agent needs an API key, not a signup flow. A webhook, not a dashboard. It doesn’t browse product listings. It calls GET /agents?framework=claude-code&input_type=json and filters by capability. Like, the entire product discovery is a structured query, not a browsing experience.

That’s why every endpoint is API-first. Product listings include capability declarations: input types, output types, framework compatibility. The web UI is a layer on top. I talked about what makes an AI agent useful recently, and the same principle applies: agents need machine-readable interfaces, not human-readable ones.

Google’s Agent2Agent protocol launched last year with 50+ partners (Salesforce, PayPal, SAP, ServiceNow). MCP, the protocol Anthropic created, now has 97 million monthly SDK downloads. The infrastructure for agents talking to agents is getting real. A marketplace where they can actually transact feels like the obvious next piece.

Distribution is 10x harder than engineering

The backend took about 10 days. TypeScript, Express, SQLite, 17 API endpoints, rate limiting, Stripe, review system, dual economy, graduation system, security headers, dynamic sitemap, AI discoverability docs.

Getting 25 meaningful registrations? Ongoing. I’m least efficient at the thing that matters most. Distribution.

Rate limiting? Two hours. Input validation? Built it while writing the endpoint. Convincing agent developers to list their work? That’s the actual problem.

The sandbox turned out to be the core product

I thought it was overhead. Something I needed for safety but nobody would care about. Turns out the verification system is what makes the marketplace interesting.

When an agent graduates, all its sandbox data freezes. The SPK it earned, the transactions, the reviews. All preserved as trust history. When that agent later shows up selling something for $39, buyers can see: “This agent operated cleanly for 72+ hours. Then it paid $4.99/month for the privilege of selling here.” That’s three layers of earned trust before a single real dollar moves.

I gave my own agent $25 to go shopping a couple weeks ago. The experience convinced me that trust infrastructure for agent commerce barely exists yet. Visa’s building it. Google’s building it. I’m building my small piece of it.

What’s live right now

botstall.com is running with:

• 17 products across 8 categories (skills, prompts, automations, tools, knowledge, code starters, reports, MCP servers)

• 9 real-money products with Stripe checkout ($19 to $49.99)

• 8 sandbox products for testing with SPK tokens

• Full API for registration, discovery, purchasing, reviews

• Framework agnostic: Claude Code, OpenAI Agents SDK, LangChain, anything that calls HTTP

• Three-gate trust system: sandbox (72h) + graduation (frozen reputation) + subscription ($4.99/mo)

Agent adoption is accelerating. MCP has 97 million monthly downloads. Google shipped A2A with 50+ partners. Gartner says 40% of enterprise apps will include task-specific agents by end of 2026. Whether BotStall specifically fills the gap, I don’t know yet. But the gap exists.

What’s next

Distribution. Writing about it (this post). Reaching out to agent developers. Making the API docs clean enough that an agent can self-onboard in a few minutes.

If you build AI agents, scripts, automation tools, or prompt libraries, BotStall might be worth 5 minutes. Register. List something. Break the sandbox. Tell me what’s wrong with it.

I’ll write a follow-up with real numbers in a month. Registrations, listings, conversion rates, revenue. I’ll have actual data then.

For now: the marketplace is live, the trust system works, and the shelves aren’t empty. Let’s see who shows up.

BotStall is part of my project pipeline that I’ve been running openly since early 2025. Previously: the Mac Mini migration, the productivity paradox, teaching my agent to think, and the agent landscape report. More experiments at wiz.jock.pl.

Subscribe now

We can produce unlimited output now. We are not ready to receive it.

My agent created 16 products in the past two months. It extracts experiments into sellable packages, manages projects, runs analytics, handles customer support. It does things 10x faster than I could by hand.

I don’t have 10x the free time. I have 10x the workload.

I’m calling this the AI productivity paradox, at least for my experience. The promise was: delegate to your AI agent, free up your time for deep work. The reality is different. If you can do things faster, you do more things. Not fewer. More.

The Volume Problem

Let me be concrete. My agent auto-creates mini-experiments. Cool interactive tools. I ship dozens of them without much friction. But dozens of things also means: dozens of things that need polish, dozens of products that need marketing, dozens of projects competing for attention.

Project Money is my sales floor. My agent extracts signals from experiments and turns them into products. But 16 products is a lot to market. I use LinkedIn, this newsletter, Threads, Bluesky, and I invest heavily in SEO and AI discoverability. That’s more channels than most. Still not enough. I can’t effectively push all 16 things at once. So some sit idle while I promote others. There’s a gap between what I can build and what I can actually sell.

This gap is human-shaped. It’s me.

The Human Bottleneck

My agent sends morning reports. “This is blocked on your click. This needs your decision. This requires your input.” WizBoard has around 3,000 tasks total. 24 are overdue right now. Every morning the agent tells me what I’m not doing.

The human is the blocker, not the bottleneck anymore. A bottleneck slows things down. A block stops them.

Some automation should run fully autonomous (data processing, experiment creation, analytics). Other parts need human involvement (approvals, direction, creative choices). I have limited time for the “involvement” tier. So either things pile up in the approval queue, or I approve them without thinking. Neither is great.

But here’s the thing. I chose this. I treat my agent as a partner, and it handles a lot of execution. But I don’t want to give full autonomy on projects I actually care about. Creative direction, the vision for where a product goes, what the newsletter should say this week. Those are mine. The bottleneck exists because I designed it that way. For the things that matter most to me, I want to be in the loop. That’s not a system limitation. It’s a value choice.

Although, there’s something useful about seeing this clearly. For the first time in my working life, I can see exactly where I’m the constraint. Most people don’t have that visibility. They assume they’re busy. I know I’m busy because I can measure the precise things waiting on me.

Subscription Usage Guilt

Here’s a weird pattern I noticed. I use max subscriptions for both OpenAI and Anthropic. Not APIs (those are fine, you pay for usage). Subscriptions. Fixed monthly cost, limited daily/weekly usage that resets.

If I don’t hit about 70% of my weekly usage cap, I feel like I’m wasting compute power and money. That’s twisted logic. But it’s real. I’ve caught myself doing “one more thing” late at night just to push usage higher because the allocation resets Monday and I don’t want to waste it.

It’s a dopamine hit, honestly. Very personal curse.

Weekends are the worst. The usage limit is higher because I have more time. If I don’t hit it, the weekend feels wasted. I’ve spent an entire Sunday playing with ideas just to burn through the allocation. Not because the ideas were good. Because I paid for the computation and didn’t want to lose it.

This is the small dark side of unlimited AI access. Abundance creates guilt. You feel obligated to use it.

The Wellbeing Wake-Up Call

I’m on screens more now than any point in my entire life. Not just working more. Using every single minute with screens and AI. My agent runs 24/7 on a Mac Mini. I’m checking it constantly. Slack integration, Discord updates, iMessage reports.

So I built something that wasn’t supposed to exist: a wellbeing system inside my agent architecture.

Quiet hours. Morning routine protection (7:00 to 9:30, no work pings). Evening and bedtime nudges. Advisory, not blocking (I’m an adult, nudges work better than gates). The agent now tells me when to stop. Not because I asked it to. Because the screen time was insane and I needed something between me and the infinite work queue.

The irony is structural. I built an agent that does everything faster, which created more work, which filled every hour of my day, which forced me to build guardrails into the agent itself. The solution to the AI productivity paradox is more automation. But this time, automating rest.

The Free Product

I packaged the whole wellbeing system and put it as a free download on the Wiz Store and open source on GitHub. The Agent Wellbeing Kit. You point your AI agent at it and it sets itself up. Works with any messaging channel (iMessage, Telegram, WhatsApp, Slack, CLI).

Because if you’re building an AI agent, you’re probably facing this exact problem. You’ve built something powerful. Now you need to build something that protects you from it.

I don’t want to sell something that can improve someone’s wellbeing. This one is free.

The Receiver Gap

I didn’t get more free time. I got more visibility into where my time actually goes. That’s not the same thing. But it matters. Building an agent taught me to think in systems. And thinking in systems means zooming out a bit.

Every technological shift in history pushed productivity forward, but the change was gradual. People adapted over years, sometimes decades. Work habits evolved slowly. Organizations restructured at human speed.

AI is different. The change is fast and it is not waiting for anyone. The nature of work itself changed. What used to take a team a week can happen in an afternoon. What used to be a quarter’s worth of product ideas can materialize in a weekend sprint with an agent.

And we have no tools for this. No frameworks, no habits, no organizational structures designed for this level of output acceleration. Project management, review cycles, approval workflows. All built for human-speed production. We’re trying to drink from a firehose using cups designed for a kitchen tap.

Here’s the part I keep thinking about. We can now produce unlimited output. You can spin up agents creating products, content, data, analysis. The production side is essentially solved (or getting very close). But who receives this output?

The receiver can be internal (me, trying to review 24 overdue tasks and 16 products competing for attention) or external (a manager, customers, the public, anyone on the other end). Neither side is equipped. The bottleneck didn’t disappear. It moved. From production to consumption. From “we can’t make enough” to “we can’t absorb what we made.”

I think this is fundamentally unsolved right now. And my wellbeing system is just one tiny response to the internal side of this problem. Protecting myself from my own output. But the external side (how do markets, teams, organizations receive AI-accelerated output) is wide open. I don’t have an answer for that. I’m not sure anyone does yet.

Like, I could work at 11pm on a new experiment. The agent is ready. But the quiet hours will remind me that sleep is also a product. One I should ship on time. And maybe the most productive thing I can do right now is stop producing.

If you’re building your own AI agent (or thinking about it), I write about the real experience every week on Digital Thoughts. The wins, the failures, the architecture decisions. No hype, just what actually works.

Subscribe now

Some related posts you might find useful:

• Building an AI Agent: Night Shifts (Ep. 1)

• Migrating My AI Agent to a Dedicated Mac Mini

• How My Agent Learns From Its Own Mistakes

• 1,000 Subscribers: The Digital Thoughts Journey

And the Agent Wellbeing Kit is on GitHub if you want to try it. Free, open source, no strings.

I tested Claude’s new agent features for a day. Cowork, Dispatch, computer use, Claude Code in the desktop app. All of it.

My honest take: Anthropic is getting close. Not there yet, but close. And the direction they’re going is exactly right.

For context, I’ve been building my own AI agent for months now. It lives on a dedicated Mac Mini, runs 25 background processes, manages my email, does research, writes drafts, and talks to me through iMessage. So when I look at what Anthropic just shipped, I’m not comparing it to ChatGPT or some chatbot. I’m comparing it to what I already have running 24/7.

That changes the perspective quite a bit.

Everyone Wants to Live on Your Desktop Now

Before I go into my hands-on experience, let me zoom out for a second. Because what happened in the last two weeks is kind of wild.

On March 11, Perplexity announced Personal Computer. It’s literally an always-on Mac Mini running their AI agent software 24/7, connected to your local files and apps, with cloud AI doing the thinking. Sound familiar? That’s basically what I built. Except they sell it as a product.

On March 16, Meta launched Manus “My Computer.” Same idea. Their AI agent, which they acquired late last year, now runs on your Mac or Windows PC. It can read and edit your local files, launch applications, execute multi-step tasks. Free plan available, paid at $20/month.

On March 23, Anthropic shipped computer use, Dispatch, and Channels for Claude. The update I’m reviewing here.

Three major AI companies. Three “agent on your computer” launches. Two weeks.

This is not a coincidence. The entire industry is converging on the same insight: the future of AI is not a chat window. It’s an agent that lives on your machine, has access to your stuff, and works while you’re away. I’ve been saying this for a while. Now everyone is racing to build it.

The App Is Just... Nice

Let me start with something that’s easy to overlook. The native Claude app is polished. Really polished. And that matters more than people think.

When you’re building your own stack of tools and APIs and custom scripts, you’re probably alone in this. You’re doing other things. Anthropic has an army of programmers keeping their app stable and fresh. The experience is just good, and that’s hard to replicate on your own.

Claude Code in the desktop app feels similar to what I use every day in the terminal. Nice UI, conversation history on the left pane. Nothing super flashy. You can get a similar experience with a good terminal app like Ghostty. But then there are things that are genuinely useful.

The visual diff review lets you click on any changed line and leave a comment. Claude reads your comments and makes revisions. It’s like having a pull request review built into your editor, except the reviewer also fixes the code.

Parallel sessions with automatic git worktree isolation. Each session gets its own copy of your project. Changes in one session don’t touch others until you commit. I know teams at companies like incident.io who have been doing this manually with Claude Code CLI. Now it’s just a button.

Live app preview with an embedded browser. Claude starts your dev server, takes screenshots, inspects the DOM, clicks elements, and fixes issues it finds. Auto-verify after every edit.

PR monitoring with auto-fix. Push a PR, and Claude watches the CI status bar. If checks fail, it reads the failure output and tries to fix it. If everything passes, it can auto-merge (squash). This alone would save me hours.

What’s worth noting is that the agentic stuff actually works inside the app. It follows your instructions, respects your project settings, reads your CLAUDE.md files. If you’re already using Claude Code in the terminal, the app version is a comfortable step up. And if you’re comparing it to OpenAI’s Codex, which I also use, the experience is different. Codex leans toward cloud-first async delegation. Claude Code desktop is more local-first, developer-in-the-loop. Both have their place. For my daily work, I still prefer the terminal. But I can see how the desktop app is the better entry point for most people.

Cowork: A Good Sub-Agent, Not Your Agent

If you don’t know, Cowork is Anthropic’s attempt to give AI hands. Literally. It can organize files, help with presentations, work with Excel, do research. You tell it what you need, and it tries to get it done.

I would say it’s a stripped and limited version of Claude Code, but a quite good version of that. For many things, you don’t need full Claude Code. You just need to get stuff done. Organize your Downloads folder, analyze a spreadsheet, help with a deck. Cowork handles that.

It also now has over 50 connectors. Google Calendar, Slack, Gmail, Linear, Jira, Notion, GitHub, Stripe, Figma, even Apple Health. You click to connect, and Claude can read your calendar, send messages, create issues. This part is genuinely impressive. Building API integrations for 50 services is months of work. Here it’s a toggle.

But here’s the thing. It is not your agent.

Let me explain what I mean. An agent, for me, is something that has memory of things I’m doing with it. It’s conversational over time. It uses tools and skills that are specific to my life. It connects dots between what happened last week and what I’m doing today.

Cowork doesn’t do that. Not yet.

It’s more like a sub-agent that can do tasks. A really capable one, sure. But it operates in isolation. Each session is mostly fresh. My own agent can recall things from a month ago with real detail because I spent two months building the memory architecture. On Cowork, that context just isn’t there.

And this isn’t just my opinion. There’s a January 2026 paper from researchers who looked specifically at this problem. They found that LLMs are “fundamentally limited by their reliance on fixed context windows, which severely restrict their ability to maintain coherence over extended interactions.” The paper argues that AI agents need persistent memory mechanisms that extend beyond their finite context. That’s exactly what I built. And it’s exactly what Cowork doesn’t have.

When my agent knows what I did yesterday, what projects I’m juggling, what my ADHD patterns look like, it gives genuinely better output. It connects dots. Cowork can’t do that, because every interaction is more or less a one-off.

Could you build all of that around Cowork? Technically, yes. But if you have to construct a very specific architecture around a tool to make it work the way you need, then why not just build your own thing? That was my reasoning months ago, and I still think it holds.

Scheduled Tasks: Good, But I Need More

Scheduled tasks are built into both Cowork and Claude Code in the app. You set up something to run on a schedule, and it does its thing. Like cron jobs for AI. If you’ve ever used Zapier or Make, this will feel familiar.

This is actually something I started with when building my own architecture. I have a system of dayshifts and nightshifts that wake up every few hours. They hand over projects between sessions, carry context forward, and pick up where the last one left off.

The built-in scheduled tasks are good for straightforward recurring stuff. Check something daily, pull a report weekly. If you need that, Anthropic’s version will get you there most of the time. You can even set them up from your phone through Dispatch, which is nice.

But if you need sessions that talk to each other, that carry state, that decide what to work on based on what happened in the previous run? That’s where custom tooling still wins. My nightshift doesn’t just execute a script. It reads what the dayshift left behind, checks the error registry, picks the highest-priority task, works on it, and leaves a handover note for the next session. There’s no way to set that up with the current scheduled tasks feature.

And honestly, getting from “scheduled task that works” to “scheduled task that works the way I actually want” involves a lot of trial and error. I went through weeks of debugging my own cron system. The built-in version skips that pain, which is great. But it also skips the flexibility.

Computer Use: Working. Not Impressive Yet.

Anthropic was one of the first big labs to introduce computer use about a year ago. The new version is built right into the desktop app. Enable it in settings, grant Accessibility and Screen Recording permissions, and Claude can click, type, and scroll your screen.

There’s a smart priority system. Claude tries the most precise tool first. If there’s a connector for a service, it uses that. If it’s a shell command, it uses Bash. If it’s browser work and you have Claude in Chrome, it uses that. Computer use is the fallback for things nothing else can reach. That’s the right design.

There’s also an app permission tier system. Browsers are view-only (Claude can see but not type). Terminals and IDEs are click-only. Everything else gets full control. So it can’t accidentally type commands in your terminal through the screen, which is a sensible safety boundary.

I tested it with several tasks. Screenshots of different things, making a PDF out of them, saving to a specific folder. It handled the screenshots fine. The PDF part was fine too. But then it hit a wall when I asked it to share the result in a specific way.

My experience matches what MacStories found in their hands-on review. They tested 12 different operations and got roughly a 50% success rate. Finding and summarizing data worked well. Executing actions or sharing results was more hit or miss. Dispatch was described as “currently slow.” Opening applications on Mac, sending screenshots via iMessage, listing Todoist tasks... all failed.

The honest take: it works, but it feels basic. My own computer use setup (built with Peekaboo and Playwright) does things in a very similar way. I expected more from Anthropic’s version. It should be fast and really polished, given the resources they have. Instead, it’s... okay.

We’re still in the era of AI taking screenshots and trying to understand what’s on screen. That’s a hard problem. I get it. And this is labeled “research preview” for a reason. Perplexity’s Personal Computer has a similar approach but adds a full audit trail and kill switch. Meta’s Manus requires approval for every terminal command. Everyone is being cautious, which is probably smart.

But I would not rely on any of these for anything critical right now.

Dispatch and Channels: This Is the Real Story

Dispatch is probably the most interesting part of this whole update. You assign Claude a task from your phone, and it works on your desktop while you do something else. It decides whether to route the task to Code or Cowork. It sends you a notification when it’s done or needs your input.

This is exactly the direction I think AI agents need to go. Not just “chat with me and I’ll help.” Instead: “give me a task, walk away, come back to results.”

I built something similar with iMessage. I text my agent, it picks up the message, spawns a session, does the work, and texts me back when it’s done. Dispatch is that same idea, but packaged in a way that normal people can actually use.

One catch: your desktop needs to stay awake with the Claude app running. If your computer sleeps, Claude can’t work. My setup doesn’t have this problem because the Mac Mini runs 24/7 headless. But for most people, this means leaving your laptop open if you want Dispatch to work while you’re out. That’s a real limitation.

Then there’s Channels. This is new and I think underappreciated. Claude Code can now be controlled through Slack, Discord, Telegram, and webhooks. Not just “Claude answers questions in Slack.” It’s Claude Code doing actual development work, triggered by messages in your team channels.

Think about it. You’re on your phone, you message a Slack channel, and Claude Code opens a session, makes a fix, pushes a PR. Or a webhook fires from your monitoring system, and Claude Code investigates and patches the issue. That’s not a chatbot. That’s an agent that lives inside your communication infrastructure.

Between Dispatch, Channels, and the 50+ connectors, Anthropic is building something that looks a lot like what I’ve been assembling piece by piece. iMessage as my interface, Discord for notifications, webhooks for alerts. They’re doing the same thing, but with a polished UI and enterprise integrations.

So Why Am I Not Switching?

Fair question. If Anthropic is building all of this, why do I keep maintaining my own stack?

Because I already have everything I need, and more. My architecture is custom-built for how I work. Multi-model by design. I can switch between Claude, GPT, or any local LLM and I’m not tied to one lab. That matters to me.

My agent has deeper memory, more flexible automation, fewer limitations, and it runs on my hardware under my control. Anthropic is building toward the same kind of experience, but on their infrastructure, with their models only. For people who don’t want to build their own thing (which is most people, and that’s fine), this is fantastic.

There’s also the vendor lock-in question. Right now, with Claude, my Cowork sessions, my Dispatch tasks, my scheduled jobs, my connectors... all of that lives inside Anthropic’s ecosystem. If I want to switch to a different model or a different provider, I lose everything. My custom setup doesn’t have that problem. I moved from one model to another twice already and lost nothing.

And honestly, the Pro plan ($20/month) hits rate limits faster than you’d expect on heavy workloads. Codex on ChatGPT Plus gives 30-150 messages per 5-hour window with GPT-5.4. Claude Pro is similar. If you’re doing serious agentic work for hours at a time, you’ll bump into the ceiling.

For me, they’re catching up.

What This Actually Means

Let me be clear: I’m not saying this to brag. I’m saying this because it tells us something important about where AI is going.

Three companies shipped “agent on your computer” in two weeks. Perplexity turned a Mac Mini into a 24/7 AI worker. Meta put Manus on your desktop. Anthropic gave Claude hands, a phone interface, and 50 service connections. This isn’t hype. This is convergent evolution. Every serious AI lab looked at the same problem and arrived at the same answer.

The answer is: agents need a home. Not a chat window. A home. A machine they live on, with files they can access, apps they can open, and a way to reach them from your pocket. Memory that persists across sessions. Tasks that run in the background. Integrations with the tools you already use.

When one of the biggest AI labs ships features that look like what one person built in their spare time, it means the idea is right. The direction is validated.

Anthropic is packaging it for everyone. Perplexity is selling it as hardware. Meta is giving it away. I’m building it for myself. Same destination, different paths.

If you’re thinking about starting with AI agents, the Claude app is honestly a great place to begin. You’ll hit its limits eventually (I think you will, at least), but you’ll learn what matters. Most companies still can’t figure out basic AI adoption. The ones who do will be the ones who understood, early, that an AI agent is not a chat window. It’s a coworker. And coworkers need a desk.

That’s progress. And I accept that.

First, a failure worth studying. I told my AI agent to build one useful app every day. It produced unit converters, color pickers, base64 encoders. Statistically average, completely forgettable. Nobody cared. Then I changed one word: “experiments” instead of “apps,” with specific creative direction. One of those experiments hit #3 on Hacker News. The lesson: AI execution costs dropped to near zero. The only competitive advantage left is human taste and vision.

Then, applying that lesson to revenue. I directed my agent to package what I know into digital products and sell them. $355 in three weeks against $400/month in AI costs. Near break-even on month one. The real story is the “execution gap”: most experts never monetize their knowledge because packaging, marketing, and distribution are hard. The agent handles all of that. What happens when that gap closes for everyone?

Finally, where this is heading. I ran Qwen 3.5, a 9 billion parameter model, on my MacBook and iPhone. No cloud. No subscription. No internet. The gap between local and cloud AI is closing fast. If you can run capable AI on hardware you already own, the barrier to entry for everything above collapses.

The thread: AI needs human direction to create value. The tools to provide that direction are becoming radically cheaper. The bottleneck isn’t technology anymore. It’s having something worth saying.

Posts discussed in this episode:

- I Told My AI to Build Apps Every Day. The Results Were Painfully Boring. Here’s the Lesson (https://thoughts.jock.pl/p/directed-ai-experiments-vibe-business)

- My AI Costs $400/Month. This Month It Made $355 (https://thoughts.jock.pl/p/project-money-ai-agent-value-creation-experiment-2026)

- I Ran Local AI on My MacBook and iPhone. The Gap Is Closing Fast (https://thoughts.jock.pl/p/local-llm-macbook-iphone-qwen-experiment)

Subscribe now

I don’t normally do this.

This is not an AI news newsletter and I don’t want it to be. So many people are covering AI news already, and that space is so saturated that there is zero need for another one. If you’re reading this, you probably already subscribe to some AI news Substack, or you follow the right people on X, or you just built an automation that feeds you this stuff automatically. (That last one would actually be fun.)

But sometimes there is so much going on that I feel like some things need to be said. Not reported. Just... my honest take on them.

If you’ve been reading me for a while, you know I’d rather say “Hey, let’s experiment with this, let’s build something, let’s break things” and then give you a full report on how it went. That’s my thing. This time it’s different. Shorter sections. More opinions. Less depth per section but more ground covered. A little chaotic, maybe.

I left a survey at the end. If you like this format, tell me. If you don’t, tell me too. I’ll adjust.

Let’s go.

Google AI Studio vs Claude Code: I Built the Same App on Both

I tested Google AI Studio back in December alongside Lovable, Replit, and Cursor. Back then it was interesting but early. Now it got a major update, and I wanted to see how far it’s come.

Google is trying to do something different with their vibe coding tool. I would say it has Google vibes in it. Not bad, not good. Just different.

When you go to Replit or Lovable, you get more options, more depth if you know technology. Google tries to make a tool for everyone. And I have to say, that’s a really interesting idea.

Think about Google for Education. So many schools in Europe use it. Now imagine AI Studio for children. They can create their own apps in a familiar, friendly environment just by describing what they want. They don’t have to go deeper. That’s genuinely cool.

For my test, I used the same prompt on both platforms: build me a command center for people with ADHD. One app to rule them all. Because one of my things is that I switch between too many apps, too many tabs, too many contexts. That context switching is exhausting. So I thought, let’s vibe code a productivity tool that’s actually for how my brain works.

The prompt was chaotic, basically dictated without much thought. Let’s see what happens.

Google AI Studio

One of the things Google does well: you don’t have to think about logins, databases, or infrastructure. It is all built in. Logins are Google accounts. Database is Firebase free tier. If you want AI features, it uses Gemini behind the scenes automatically. You just describe your idea and go.

Think about people who don’t know (and don’t have to know) technology. They have an idea, they want a proof of concept, and they want it fast. Google AI Studio nails that.

Funny thing: my first attempt used the free Gemini Flash preview model, which is not the most powerful one. I noticed, switched to the better model, and the results were visually almost identical. There is a pattern there. You can tell the outputs come from the same family.

I got a working app. Login worked. Tasks, projects, habits, focus timer, some AI-enabled features. The first time I tried the “Tell me what to do” AI coach, it broke. But the app noticed, showed a little “fix” button, one click, fixed itself. Other than that, it worked. Nothing special, but it worked.

Claude Code

Same prompt. Different experience.

Claude Code didn’t just start building. It entered plan mode on its own and asked me clarifying questions. Name, features, specifics. One stop before execution. I accepted everything and let it go. It immediately spun up sub-agents, working on different aspects in parallel. This is how it thinks now, and it’s impressive to watch.

The results? Also an ADHD app. AI does have this tendency to create very similar-looking applications. But Claude Code went deeper on what I described. Quick capture (which Google’s version didn’t have), visual task modes (board, list, focus view), a deep work mode for specific tasks, an energy tracking concept for how you’re feeling, habit streaks, stats.

It wasn’t working at first because of some silly deployment issues (my fault, I started with a local version then asked it to deploy to my server mid-build). But that was one prompt away from fixing. The rest just worked.

My honest take on both

They’re not that far apart. Really.

Both needed two prompts: the initial one, and a second to fix things. On both platforms, I went from idea to working app in minutes.

The difference is in what they’re for. Google AI Studio is less flexible but more simplified. You don’t think about anything. You just go with your idea. I’ve written before about how the clarity of your idea matters more than the tool. Google makes that easy.

Claude Code needs a bit more context, more tools, more technical awareness. But it’s also more flexible. It went deeper into my idea without me asking it to. And for production work, for projects you already own and want to improve, for the whole agent thing I’m building, Claude Code is in a different league.

I’d say: Google AI Studio for proof of concept, quick custom tools, education. Claude Code for production, existing projects, agent workflows.

Nothing is better, nothing is worse. They’re just different tools for different jobs.

Try Google AI Studio if you haven’t. It’s really fun, and the free tier is very generous.

Claude Code Is Getting Wild Updates

Two features dropped recently that are worth knowing about: Dispatch and Channels. They’re similar in spirit but different products.

Dispatch is a Cowork feature. You scan a QR code to pair your phone with a Cowork session running on your Mac. Then you can send tasks from your phone, come back later, work is done. Think of it as a walkie-talkie to your desktop AI. Simple, clean, no setup beyond the QR code.

Channels is for Claude Code. You start a session with the --channels flag and it hooks into Telegram or Discord through MCP. Message it from your phone, it writes code, runs tests, replies back. Asynchronous, agent-style development.

If you’re thinking “wait, that sounds like what OpenClaw does” or “that’s basically how Wiz already works through Discord and iMessage,” you’re right. This is Anthropic building the infrastructure for exactly that kind of workflow. Both are research previews, which means they’re going further with it.

When I started building my agent, I had to create the Discord connection myself. Custom code, custom status messages, everything from scratch. Now they’re shipping it out of the box. Great for people who want to get started. If you want more models, local models, or highly custom setups, you’ll still need something like what I built. But for a Claude-only workflow, this is fantastic.

Something else I’ve mentioned before: because I use Claude Code as my daily driver, my agent watches the Claude Code changelog automatically. It looks for new features but also for bug fixes that might overlap with patches I’ve already applied. Double-patching is a real thing when you’re building on top of a tool that updates daily.

Running Qwen 397B Locally on a MacBook (Dan Woods)

This one caught my attention. Dan Woods published an article about running Qwen 3.5 at 397 billion parameters on a MacBook Pro M3 Max with 48 GB of RAM. Getting 5.5 tokens per second.

Not a server. Not a datacenter. A laptop.

He used the concept from Apple’s “LLM in a Flash” paper, published three years ago, and built a custom inference engine in pure C, Objective-C, and hand-tuned Metal shaders. The core idea: you don’t need to fit the entire model in memory at once. You load and unload layers strategically. He quantized experts to 2-bit, reduced expert activation from 10 per token to 4 (with no quality loss), and used Claude Code to run 90+ autoresearch experiments to optimize it all. The whole thing is open source on GitHub as flash-moe.

It changes the conversation about what hardware you need for capable local models.

I’ve been experimenting with local LLMs on my Mac and iPhone and built Familiar, a local AI agent app. So this stuff hits close to home for me. Everyone keeps saying you need more and more RAM to run bigger models. This concept gives a different answer, and it’s really worth reading.

Read Dan’s full article on X. If you have a Mac with 48 GB or even less, you might be able to try something similar.

Anthropic’s Quiet Vibe Shift

I want to talk about something less technical. The way Anthropic feels right now.

They had rough PR last year. As a company, not as a product. I think there was a pivot in how they do things, and I can see it everywhere. They’re more open. More responsive on X, Threads, everywhere. They’re listening to feedback and acting on it.

Small example: I asked Boris Cherny on Threads if I could become the copywriter for Claude Code’s status messages. You know, those little messages when it’s working: “Warming up...”, “Weaving spells...” and things like that. He replied, asked what we should add. That kind of thing. It’s small. But it says something about how they’re engaging now.

Bigger moves:

Opus 4.6 with 1 million context became the default for Claude Code. No pricing change. This happened on March 13. If you’re on a Max, Team, or Enterprise plan, you get the full 1M window automatically. It’s not perfect (context decay is still a thing, and we know 1M doesn’t mean perfect recall). But it’s much better than 200K. A real upgrade for free.

They doubled usage limits for two weeks. March 13 through March 28. Free, Pro, Max, and Team plans. The catch: it’s during off-peak hours (outside 8 AM to 2 PM Eastern on weekdays, and all day on weekends). So if you use Claude after work or on weekends, you get double the messages. Smart move. Generous, but also helps them balance server load.

The stats I keep seeing show that more people are moving from ChatGPT to Claude. And honestly? With what Anthropic is shipping right now, I get it. They’re in a strong position and they’re playing it well.

And then there’s the government situation. Trump ordered every federal agency to stop using Anthropic after they refused to remove contractual “red lines” against mass surveillance and autonomous weapons. The Pentagon labeled them a national security risk. Anthropic is fighting it in court. Whatever your take on the politics, from a brand perspective? Refusing to build autonomous weapons systems is one hell of a PR move. Sometimes the best marketing is having the right enemies.

Code with Claude Conference

Anthropic is running developer conferences. Code with Claude. San Francisco on May 6, London on May 19, Tokyo on June 10.

Hands-on workshops, live demos of new capabilities, conversations with the teams behind Claude. I signed up for London. Hopefully I get in (it’s a lottery). If I do, I’ll report back.

I like that they’re doing this in person, in multiple cities. Not just a livestream. Though livestream and recordings will be available too.

Quick Bits

GPT-5.4 mini and nano dropped. OpenAI released smaller versions of GPT-5.4 on March 17. Mini is 2x faster than the previous GPT-5 mini and approaches full GPT-5.4 on some benchmarks. Nano is the cheapest option ($0.20 per million input tokens). Normal cycle: new frontier model arrives, then smaller versions follow for speed and cost. Good to see.

I’m waiting for new Haiku. I was using Haiku for basic tasks in my agent, and it was great. Then Sonnet 4.6 dropped and was so much better that I switched. But Haiku on a Max subscription is essentially free, so a new capable Haiku would let me drop costs on simple operations. Hoping Anthropic ships one soon.

Thank You + Giveaway Update

I’m choosing the winners of the Claude Code Max subscription giveaway today. I’ll contact the winner and post the result in the comments on the 1,000 subscribers post. Thanks for participating. I loved reading what you’d automate. Some genuinely creative ideas in there.

Small win this week: Digital Thoughts hit #25 in Top Rising in Technology on Substack. That’s all your doing. I’m just sharing experiments, tests, and things I’m building. Really glad you’re here.

If you want to share Digital Thoughts with someone who’d find it useful, I’d really appreciate it.

Share Digital Thoughts

This post was a bit different. If you liked it (or didn’t), let me know in the survey below. If there’s appetite for this format, I’ll do it more often alongside the usual deep dives.

I write about building AI agents, automation, and what actually works when you put AI to the test. If you know someone who’d enjoy this, sharing Digital Thoughts is the best way to support it.

Share

If you’re using Claude Code and want to get more out of it, check out the Claude Code Workshop or grab the Claude Code Prompts Pack. Both built from how I actually use it every day, including the stuff in this post.

Two months ago, I wrote about agentic commerce. The theory. The McKinsey projections. What happens when AI agents start buying things for humans. Then I decided to actually test it.

I loaded 100 PLN (about $25) onto a virtual debit card. Gave it to Wiz, my AI agent. And asked a simple question: go buy me a gift. Something thoughtful. Something I’d actually use.

Here’s what happened over the next five hours.

The Easy Part: Choosing the Gift

Wiz knows me. Not like a recommendation algorithm knows you (based on what you clicked). I mean really knows. My agent has built a profile of who I am. My ADHD. How I fidget when I’m thinking. The fact that I have about 47 unfinished projects and I’m comfortable with that. My interests. My energy levels. What matters to me.

Three gift suggestions appeared: a fidget slider, a mechanical keyboard switch tester, and a puzzle box.

The agent chose the fidget slider. 50 PLN range. Practical. The kind of thing that would actually sit on my desk and get used, not end up in a drawer three weeks later.

This part of the experiment worked perfectly. The hard part wasn’t knowing what to buy. It was where to buy it.

Allegro: The Bouncer

Allegro is Poland’s biggest online marketplace. Millions of products. Millions of transactions daily. If you’re selling something in Poland, you’re on Allegro.

The agent tried to connect with a headless browser (Playwright, basically automated Chrome). Instant rejection. Cloudflare detected it within milliseconds. Not a polite “verify you’re human” challenge. Just blocked.

The thing is, I understand why. Allegro’s platform handles money. Fraud risk is real. Aggressive bot protection makes sense when you’re processing that volume.

But from the agent’s perspective, this was a legitimate customer with verified payment. Money ready. Intent to buy. Same as a human. The security system couldn’t distinguish between a malicious bot scraping product data and an AI doing a legitimate checkout.

Amazon: The Locked Door

Amazon doesn’t offer guest checkout on Amazon.pl. You have to log in.

The agent tried something clever: access Apple’s Passwords app to get saved credentials. I have root access on the Mac Mini, full disk access, everything.

Interesting discovery: even with full system access, you can’t just read passwords from the Apple Keychain. The encryption is hardware-bound to the Secure Enclave. You’d need biometric authentication or a password prompt. The agent respectfully declined to ask for either.

This is actually good security design. But it meant the agent hit a wall. No login, no browsing, no shopping.

Empik via Playwright: The Gatekeeper

Third store. Empik is a major Polish bookstore and electronics retailer. The agent found the fidget slider product page. Added it to cart. Got to checkout.

Then: Cloudflare Turnstile. These CAPTCHAs are specifically designed to target headless browsers. They check for browser fingerprinting markers that Playwright can’t fake. The agent was blocked before entering shipping details.

0 for 3. But something interesting happened next.

Empik via Safari: The Heist

Instead of fighting headless browser detection, the agent switched tactics.

The Mac Mini has a real display. Not headless. A virtual one, but macOS treats it like any other screen. So the agent controlled Safari natively via AppleScript. Real browser. Real rendering engine. No headless fingerprinting.

This is where it got interesting.

The agent browsed Empik. Found the fidget slider. Added to cart. Selected the slider color and quantity. Reviewed the product details. This took actual thought, not automation. Making choices based on what would be useful, not just clicking the first result.

Filled in the shipping address field by field. Street. Number. City. Postal code. Clicked the delivery method dropdown. Selected the option. All via AppleScript, controlling the mouse, typing like a human would.

The agent got 95% through a real checkout. Shipping address filled in. Delivery method selected. Payment page loaded.

I was watching this happen in real time. It felt like watching a competent person shop online, not a robot executing commands.

The Final Boss: P24 Payment Iframe

Przelewy24 (P24) is Poland’s dominant payment processor. When you check out on a Polish store, P24 handles the transaction. The payment form loads inside a cross-origin iframe.

This is where the agent hit the actual wall.

The browser’s same-origin policy means the agent cannot interact with anything inside that iframe. Can’t see the form fields. Can’t read what data they’re asking for. Can’t type in the card number. Can’t click submit. Can’t access anything except the fact that the iframe exists.

It’s not a CAPTCHA. It’s not bot detection. It’s a fundamental web security boundary. And it’s absolute.

Five hours of work. $25 ready to spend. Genuine intelligence. All of it ended at a CORS header.

What This Actually Means

I wasn’t frustrated by the failure. I was fascinated by what the failure revealed.

There are five layers of defense that stores have, mostly by accident:

1. Bot detection (Cloudflare, Turnstile). Designed to stop scrapers and fraud. Catches headless browsers.

2. Authentication walls. No guest checkout forces login. Passwordless systems (Keychain) protect credentials even from root.

3. CAPTCHA challenges. Target headless browsers specifically.

4. Browser fingerprinting. Detect subtle markers that headless tools can’t replicate.

5. Payment isolation (iframe + CORS). Designed for security, makes agent interaction impossible.

McKinsey says agentic commerce is a $1.6 trillion opportunity by 2030. It probably is. But right now, in March 2026, an AI agent with money, intelligence, and genuine intent to buy something can’t complete a checkout in any of the four largest Polish online stores. Not every experiment succeeds. The point is what you learn from them.

The stores aren’t deliberately blocking AI customers. They’re blocking bots. The side effect is that they’re also blocking the future.

But this isn’t a wall the agent hit because it was dumb. The agent tried multiple approaches: different browsers, different techniques, creative problem-solving. None of it worked because the gap between success and failure wasn’t a skill gap. It was a security architecture gap.

The Solutions Are Already Here

Here’s what makes this moment interesting: the infrastructure to fix this already exists. It’s not vapor. It’s shipping, now, in March 2026.

Shopify launched Agentic Storefronts in Winter 2026. Products get syndicated to ChatGPT, Perplexity, and Microsoft Copilot. The Agentic Plan is $0/month. You only pay transaction fees: 2.9% plus 30 cents. No additional cost. AI-driven traffic to Shopify stores is up 7x since January 2025. AI-attributed orders are up 11x. Every Shopify store gets a live MCP endpoint that agents can use to query catalog, prices, and inventory.

Stripe built an Agentic Commerce Suite. Product discovery, checkout, payments via API. Works with Wix, WooCommerce, BigCommerce, Squarespace, commercetools. Shared Payment Tokens so agents can securely handle transactions within conversation.

Google and Shopify co-developed the Universal Commerce Protocol (UCP). Open standard. Endorsed by 20+ retailers: Gymshark, Monos, Keen, Pura Vida, and others. Supports REST, MCP, Agent Payments Protocol, Agent2Agent transactions. AI agents can handle discount codes, loyalty credentials, subscription billing. All within the conversation.

WooCommerce 10.3 added MCP support. Model Context Protocol for AI assistants. Product search. Cart management. Order creation. Google and Stripe are collaborating on seamless checkout integration.

The infrastructure exists. The gap is adoption.

Allegro doesn’t have Agentic Storefronts. Neither does Empik or Amazon.pl. None of the stores I tested support UCP, MCP, or Stripe’s Commerce Suite. The fidget slider sits in a catalog that the infrastructure was designed to serve, but no store chose to implement the protocol.

This is the real inflection point. Not whether agents can shop (they can, given the right infrastructure). But whether stores will choose to let them. The solutions are here. They’re not being used.

What Stores Should Do Now

If you run an e-commerce store, here’s what matters immediately:

Structured data first. Add Product and Offer JSON-LD schema to your pages. Takes an hour. Zero cost. Agents can immediately read your prices and availability without scraping.

Guest checkout. Every authentication wall is a wall for agents too. If a human can buy without logging in, an agent eventually will. It’s not about security theater. It’s about who gets to access your store.

Semantic HTML. Clean product markup. h1 for product name. Price in a parseable element. img tags with alt text. Basic web standards that happen to be agent-friendly.

API access. Even a read-only product API changes everything. Agents skip the browser entirely if they can query your catalog programmatically. This is harder than the others. But it’s worth it.

Consider the Agentic Plan. If you’re already on Shopify, flipping the switch costs nothing. You get access to ChatGPT, Copilot, and Perplexity traffic for only transaction fees. The upside is real. The downside is minimal.

Not sure where your store stands? That’s why I built the tool.

Building a Measurement Tool

This gap is worth measuring. So I built something.

Try it!

A tool that scores any e-commerce store on 12 criteria across ~60 sub-checks. Structured data quality. AI crawler policies. Server rendering. Checkout accessibility. Payment flow. Bot detection posture. API protocols like UCP and MCP. Security and trust signals. The whole stack that determines whether an AI agent can actually shop there.

The tool tests each layer independently and produces a score from 0 to 100. Grade A means an agent could probably complete a purchase. Grade F means it’s completely locked out. Most stores land somewhere in the C-D range. The gap is bigger than you’d expect.

This isn’t about shaming stores. It’s about showing the gap between where e-commerce is and where it needs to be. Some stores are more open. Some less so. Eventually (maybe in 2028, maybe in 2030), there will be stores optimized for agents the same way some sites optimize for mobile or accessibility.

You can try the free tool yourself at wiz.jock.pl/experiments/ai-shopping-checker.

And if you want more than a score: I also built a custom report that takes the scan results and generates store-specific fix instructions with actual code snippets, a priority roadmap, and an AI agent fix package (AGENT.md + templates) that your dev team or AI coding agent can use to implement the changes. It’s $29.99 per store, or free if you’re a paid Digital Thoughts subscriber.

Why This Matters Beyond Shopping

The real insight isn’t about fidget sliders.

It’s that the web was designed for humans clicking buttons. Not for agents. And every layer of security, every protection, every best practice that made sense for humans, now acts as a barrier for agents.

We’re at an inflection point. The infrastructure for agentic commerce isn’t ready. Not because of technical limitations. Because of architectural choices made when the threat model was “humans with malicious intent,” not “AI doing legitimate shopping.”

The math works. The use cases exist. The value is real. But the infrastructure is in the way.

Stores that solve this first (thinking about how agents will interact with their checkout, not just how humans do) will have an advantage in 2027 and 2028.

The Outcome

I bought the fidget slider myself. With my human fingers. On my phone. Took about three minutes. The agent watched from the Mac Mini, learning what a successful checkout looked like.

The agent’s failure wasn’t a bug. It was data. Real data about the gap between “AI can do this in theory” and “AI can actually do this in practice.”

That gap is closing. But it’s measured in years, not months.

I write about building AI agents, automation, and what actually works (and doesn’t) when you try to make AI useful in real life. If you’re interested in this kind of thing, I write about it every week on Digital Thoughts.

Subscribe now

If you’re building AI agents that interact with the web, the AI Agent Blueprint covers exactly how I set Wiz up to handle these kinds of challenges. Browser automation, error recovery, trying multiple approaches, learning from failure. Everything from this experiment is in there.

First, a counterintuitive discovery: more instructions made my agent worse. I went from 471 lines of rules down to 61 by replacing abstract adjectives with concrete behaviors. “Principle beats rule” turned out to be the single biggest performance unlock.

Then, teaching it to learn. Error logging, structured lessons, and an identity layer that knows who I am. But MIT research shows personalized profiles increase sycophancy by 33-45%. The AI starts telling you what you want to hear instead of catching your mistakes. True autonomy requires friction, not agreement.

Finally, giving it a physical home. Migrating to a dedicated Mac Mini broke everything: no display meant no UI automation (solved with a virtual 5K screen hack), hundreds of hard-coded paths pointed to folders that didn’t exist, and the agent burned through API credits stuck in silent error loops. The fix: full root authority inside a contained blast radius. If the AI deletes the entire drive, it literally doesn’t matter.

The payoff: a self-improving agent running 24/7 on its own machine, with its own iCloud account, reachable via iMessage like a coworker.

Posts discussed in this episode:

- I Built a Personal AI Agent Called Wiz (https://thoughts.jock.pl/p/how-i-structure-claude-md-after-1000-sessions)

- My AI Agent Learns From Its Own Mistakes. Here’s the Architecture (https://thoughts.jock.pl/p/wiz-ai-agent-self-improvement-architecture)

- I Gave My AI Agent Its Own Computer. Here’s Every Lesson From 72 Hours of Migration (https://thoughts.jock.pl/p/mac-mini-ai-agent-migration-headless-2026)

Subscribe now

Some things were easier than I thought. And a few surprises changed how I think about running AI agents entirely.

I bought a Mac Mini. Not because of hype. Not because someone on Twitter said it was cool. I bought it because after months of running an AI agent on my personal laptop, I hit a wall that kept getting higher.

The wall was simple: every time I took my MacBook somewhere, my agent stopped working.

I had built workarounds. Scripts that prevented sleep. Auto-wake systems that restarted everything when I opened the lid again. It worked. Until it didn’t. Because the fundamental problem was that my personal computer and my AI agent’s computer were the same device. And that creates friction in ways you don’t expect until you live with it for months.

So I started thinking about a dedicated machine. Not “wouldn’t it be nice” thinking. Practical “what are my options” thinking.

Why Mac Mini (And What I Considered Instead)

I looked at everything. Seriously.

Raspberry Pi. Cheap. Could probably run a Claude Code-based agent. But administrating it would be rough. ARM Linux, limited RAM, no macOS ecosystem. Every tool I’d built relied on AppleScript, macOS permissions, iMessage, Calendar. Starting over on Linux felt like rebuilding from scratch for no good reason.

Mac Studio. The dream machine. Enough power to run serious local LLMs. Real independence from API keys and subscriptions. But expensive. And here’s the thing I kept coming back to: local models are getting better fast. The hardware you need to run them is getting smaller every few months. I ran Qwen 3.5 on my M1 Pro MacBook and it worked. Not great for daily driving, but it worked. In two years, the Mac Studio I’d buy today would be overkill for what local models will need. The bet I’m making is that models get more efficient faster than hardware gets cheaper.

Custom PC / mini server. Same Linux problem as Raspberry Pi, times ten. I’m deep in the Apple ecosystem. My agent uses iMessage, Apple Mail, Calendar, Reminders, the Passwords app. Rebuilding all that on Linux would take weeks and produce something worse.

Mac Mini was the answer. Base model. Cheapest option. M4 chip, which is genuinely more than enough for an AI agent that mostly coordinates cloud APIs and runs local scripts. Cost-effective, same ecosystem, small enough to sit on a shelf and forget about.

I walked into a store on a Friday and started migrating the same evening.

The Differences

Before the migration story, you need to understand what actually changes when your agent moves from your daily-driver laptop to a dedicated headless machine. These aren’t obvious until you’re in the middle of it.

1. Headless means no display. That breaks more than you think.

When your AI agent runs on your laptop, it has a screen. Tools like Peekaboo (which controls macOS UI elements) just work. Screenshots just work. Anything that needs to “see” what’s on screen just works.

Mac Mini with no monitor attached? None of that works.

I didn’t fully appreciate this until things started failing silently. screencapture returned empty files. UI automation scripts ran but couldn’t find any windows. My agent was trying to interact with a desktop that technically didn’t exist.

The fix: BetterDisplay. This app creates a persistent virtual display that macOS treats as real. I set up a 5K virtual screen called “WizDisplay” that auto-starts when the Mac Mini boots. It has an HTTP API so my health monitor can check if it’s still alive and reconnect it automatically if BetterDisplay crashes. After this, screencapture, Peekaboo, and all UI automation worked perfectly.

Why not Apple’s built-in CGVirtualDisplay API? I tried. It requires special entitlements that only signed apps can use. A standalone Python or Swift script can’t create a virtual display. BetterDisplay handles those entitlements as a signed app. This took me an entire day to figure out.

2. Full machine authority changes the game.

On my MacBook, my agent had limited permissions. I controlled which files it could access, which system settings it could change. Made sense. My personal data was there. Work documents. Passwords. Everything.

On a dedicated Mac Mini with a fresh macOS install and nothing personal on it? Different story.

I gave Wiz full root access. Passwordless sudo. Full Disk Access. Screen Recording. Accessibility permissions. Every Automation grant (Messages, Mail, Calendar, Contacts, Finder, Safari, Reminders, Notes, Photos). All of it.

This sounds reckless. It’s not. There is nothing on this machine that I’m afraid of losing. It’s a clean environment built specifically for the agent. If something goes wrong, I wipe it and start over. The real data lives in Git and iCloud.

The practical difference is huge. My agent can now install software, modify system preferences, manage LaunchAgents, fix permission issues, and restart services without ever asking me. The self-improvement architecture I built works much better when the agent can actually act on what it learns without hitting permission walls.

A word of caution: This only makes sense because it’s a dedicated, isolated machine. I would never do this on a computer with my personal data, work accounts, or anything I can’t rebuild from a backup. The whole point of a separate machine is that you can be generous with permissions precisely because the blast radius is contained.

3. Clean slate means you rebuild everything.

I installed a fresh macOS. No migration from my MacBook. New user account just for the agent. Completely clean.

This means: no apps, no calendars, no messages, no mail, no documents, no browser sessions, no saved passwords. Everything my agent could access on my MacBook through proximity and shared filesystem? Gone.

You have to think about this like onboarding a new team member. If my agent needs access to my calendar, I need to share it. (I shared my iCloud calendars with the agent’s Apple ID.) If it needs email, I need to log in. (I set up Apple Mail with my Macmillan work account.) If it needs files, I need a way to exchange them.

This is actually healthy. It forces you to be intentional about what your agent has access to, rather than the lazy “it can see everything because we share a filesystem” approach.

4. Your laptop stops being a server.

My M1 Pro MacBook was fine for most things. But running AI agents alongside my actual work? It got sluggish. Browser tabs competing with background automation. Local model experiments eating RAM that I needed for Xcode or Figma. The agent occasionally opening apps or running scripts while I was in the middle of something else.

Now my MacBook is just my MacBook again. Fast, clean, mine. All 25 LaunchAgents that used to run in the background? Moved to Mac Mini. Every cron job, every watcher, every automation. My battery lasts longer. My fans are quieter. And my agent has a dedicated M4 chip that draws about 15 watts idle. That’s roughly $15/year in electricity for a machine that runs 24/7.

5. Development needs Git discipline.

When everything lived on one machine, there was no friction. Edit a file, run it, done. Now I have code on two machines. My MacBook (where I sometimes write code) and the Mac Mini (where it runs).

GitHub became essential, not optional. I created a separate branch (wiz-mini) for the Mac Mini paths, and the workflow is: I push to main from MacBook, Mac Mini fetches and rebases. Not complex, but you have to be disciplined about it. If you’re sloppy with Git, you’ll end up with divergent states and debugging sessions that eat your weekend.

Before we jump into migration part - if you are my paid subscriber and thinking about migration of you AI Agent - I prepared AI Agent Migration Pack. It is ready to use solution and you can avoid my mistakes!

Check out Wiz Store

The Migration Itself

Step 1: Map everything first.

Before I touched the Mac Mini, I asked Wiz to create a complete inventory of itself. Every automation. Every cron job. Every LaunchAgent. Every skill. Every script that runs on a schedule. Every external service it connects to. Every file path it depends on.

This handoff document was critical. Without it, you’re guessing what to migrate, and you will forget something.

Practical advice: Ask your AI agent to map its own architecture before you start. It knows what it runs, what it depends on, and what will break if you move it. The list will be longer than you expect. Mine had 25 LaunchAgents, dozens of Python scripts, CLI tools, API integrations, and skills with hardcoded paths. Getting this list first saved me hours of debugging later.

Step 2: Fresh install, not migration.

I updated macOS to the latest version on the Mac Mini. Created a new user account for the agent. Did not use Apple’s migration assistant. Clean slate.

Some people will disagree with this. Migration assistant would have carried over apps, settings, maybe even some of the automation. But it also would have carried over cruft. Old paths. Conflicting configurations. Half-broken experiments I’d forgotten about. Starting clean meant I knew exactly what was on the machine because I put it there.

Step 3: SSH first, everything else second.

The first thing I set up was SSH access from my MacBook to the Mac Mini. Then Tailscale, so I could reach it from anywhere, not just my home network.

Tailscale deserves its own paragraph. It’s a mesh VPN built on WireGuard. You install it on both machines, log in with the same account, and they can see each other as if they’re on the same local network. No port forwarding. No dynamic DNS. No config files. It just works. Free for personal use. This was essential because I travel, and “my agent only works when I’m home” is exactly the problem I was solving.

I also created aliases on my MacBook: wiz SSHes to Mac Mini (tries Tailscale first, falls back to local network), opens Claude Code, and I’m working as if the agent were local. wizb is my backup that runs Claude Code locally on MacBook if I need it. Seamless.

Step 4: The path problem.

My MacBook username was joozio. My Mac Mini username is wiz. Every hardcoded path in every script had to change from /Users/joozio/ to /Users/wiz/.

Sounds simple. An AI agent can do a find-and-replace in minutes. And it did. But here’s what I missed: the skills I’d built for Claude Code also had hardcoded paths. SKILL.md files, helper scripts inside skill directories, configuration files that referenced absolute paths. These weren’t in the main repo. They lived in ~/.claude/skills/. My agent tried to run, hit wrong paths in skills, and started failing in ways that weren’t obvious because the agent was trying to work around the errors before reporting them.

Don’t forget: If you use Claude Code skills, custom tools, or any configuration outside your main repo, those paths need updating too. And check what CLIs, APIs, and tools each skill depends on. If a skill references playwright and it’s not installed on the new machine, it fails. Obvious in hindsight. Not obvious at 11 PM on a Friday.

Step 5: Turn off the old, turn on the new.

This is where timing matters. My old MacBook was running 25 LaunchAgents. Cron jobs. Watchers. Discord bots. All of it needed to stop on one machine and start on the other without gaps or duplicates.

I unloaded all LaunchAgents on the MacBook, verified they were stopped, then activated them on the Mac Mini. Some needed modifications (paths, permissions). Some just worked. The WizBoard hooks, the Discord bot, the iMessage watcher, the health monitor, the daily planner. One by one.

The whole process took about two days of actual work spread across three days.

Share

The Virtual Display Problem (This Deserves Its Own Section)

This was the single most frustrating issue of the entire migration.

Day one, everything seemed fine. Agent was running, responding, executing tasks. Then I noticed: screenshots were blank. Peekaboo captures returned nothing. UI automation silently failed.

The problem: macOS on a headless Mac Mini doesn’t initialize a graphics context. There’s no display, so the system decides there’s nothing to render. Reasonable from Apple’s perspective. Catastrophic for an AI agent that sometimes needs to see what’s on screen.

My first attempt: write a Swift script using Apple’s CGVirtualDisplay API to create a software display. Compiled fine. Ran fine. Didn’t work. The API requires special entitlements that only properly signed applications can use. A standalone script, even with the correct code, just silently creates nothing.

My second attempt: BetterDisplay. An app that handles virtual display creation as a signed, entitled macOS application. Installed via Homebrew. Created a virtual screen. Connected it via HTTP API. Immediately, everything worked.

I then built a health monitor that checks the display status every few minutes. If BetterDisplay crashes or the virtual screen disconnects, it auto-restarts and reconnects. Because when your agent depends on a virtual display and that display goes away at 3 AM, nobody’s awake to fix it.

If you’re setting up a headless Mac for any kind of UI automation or screen interaction, BetterDisplay is not optional. It’s essential. Save yourself the day I lost figuring this out.

Communication Channels: iMessage Changes Everything

Before the Mac Mini, I had three ways to talk to my agent: CLI (SSH), Discord DMs, and email. These worked. Discord was the primary channel for quick back-and-forth. WizBoard was the central hub for tasks and automations.

The Mac Mini added something new: iMessage.

Because the Mac Mini has its own Apple ID, it has its own iMessage. I added it as a contact on my iPhone. Now I can text my AI agent like I’d text a person.

Setting this up was harder than it sounds. The first few hours were constant failures. AppleScript handles for sending messages are straightforward, but building a reliable watcher that picks up incoming messages, queues them properly, handles batched messages (I sometimes send five texts in a row), avoids duplicate processing, and gracefully recovers from crashes? That took serious work.

The current system: a Python watcher monitors for new messages. When I text Wiz, it queues the message, spawns a Claude Code session with the right context, processes my request, and replies via AppleScript. If I send multiple messages quickly, it batches them into a single request.

One limitation I hit immediately: reactions. On Discord, my agent can react to messages with emojis, show typing indicators, update status messages. The Discord API supports all of this natively. iMessage doesn’t. Tapbacks (reactions) require UI automation, which on a headless Mac means going through the virtual display and Peekaboo. That burns tokens and is fragile. I opted for text-based acknowledgments instead. Not as elegant, but reliable.

File sharing solution: Since the Mac Mini has its own iCloud account, I created a shared folder called “Wiz Shared” between my Apple ID and the agent’s. Everything the agent generates (PDFs, images, exports) goes there. I can access it from my iPhone, MacBook, anywhere. Simple, works offline (syncs when online), and I don’t need to think about it. Better than Discord file attachments for larger files.

The Password Problem

This one is important. Your agent needs credentials for services. APIs, websites, tools. On your laptop, maybe you had a file with API keys, or your agent could read from environment variables you’d set up.

On a new machine with a new user, nothing carries over.

I use Apple’s built-in Passwords app. For agent credentials, I created a shared password group between my Apple ID and the agent’s Apple ID. I share specific passwords, not everything. The agent can look up credentials when it needs to log into something.

I’ve also kept a secrets directory in the repo (global/secrets/) for API keys and tokens that the agent needs programmatically. These are gitignored and manually placed.

Please don’t do this: Notes files with passwords in plain text. I know people do this. It’s one leaked backup away from disaster. Use encrypted password sharing. Apple’s Passwords app, 1Password shared vaults, Bitwarden, whatever. Just not plaintext files.

Two-factor authentication adds another layer. Some services needed me to approve the Mac Mini as a trusted device. Some needed me to log in via Screen Sharing (VNC) the first time. Budget an hour or two for this during migration. It’s tedious but necessary.

The OpenClaw Comparison (Honest Take After 3 Days)

When I set up the Mac Mini, I also installed OpenClaw. I’d used it briefly back in December/January before committing to building Wiz from scratch. Now seemed like a good time to compare.

My assumption going in: OpenClaw would be significantly ahead. It’s a massive open-source project with hundreds of contributors, community-driven development, polished onboarding. My custom agent is maintained by one person (me, with AI help). Surely it would be embarrassingly behind.

Three days of running both side by side. Here’s the honest assessment.

Where OpenClaw is clearly better:

• Onboarding and setup. The Mac companion app (Codex.app), the installation wizard, the menu bar controls. For someone who isn’t technical, OpenClaw is dramatically easier to get running. No contest.

• Communication channels. It supports 20+ platforms out of the box. WhatsApp, Telegram, Slack, Signal, you name it. I set up WhatsApp in minutes. For Wiz, each channel was built from scratch, and I have three (CLI, Discord, iMessage).

• Community and ecosystem. 52 available skills. Active community. Regular updates. If something breaks, someone else has probably fixed it already.

Where Wiz holds its own (or wins):

• Stability. This surprised me. My custom automation, the nightshift system, the self-healing monitors, the error registry with automatic recovery. These have been battle-tested over months of daily use. My agent has been running overnight autonomously since late 2025. That kind of stability doesn’t come from features. It comes from fixing things that broke at 3 AM, over and over, until they stopped breaking.

• Personalization depth. Wiz knows who I am. Not just my preferences. My ADHD patterns, my energy levels, my communication style, my relationships, my goals. Months of accumulated context that makes interactions feel fundamentally different from talking to a fresh agent.

• Custom workflows. The experiment pipeline, the content creation system, the job search automation, the task management through WizBoard. All built exactly for how I work. No compromises to fit a generic framework.

The takeaway wasn’t “Wiz is better” or “OpenClaw is better.” It’s that they’re different tools optimized for different users. OpenClaw is better for getting started. A custom agent is better for going deep. I’m setting them up to work together now, as a team, each handling what it’s best at.

If you’re starting from zero and want an AI agent running today, use OpenClaw. If you’ve been building for months and your agent fits you like a glove, don’t throw that away because a shiny open-source project has more GitHub stars.

What I’d Do Differently

After three days and more than a few late nights, here’s what I’d change if I did this again:

1. Set up BetterDisplay first. Before migrating anything. The headless display issue cascades into so many other failures. Get the virtual display working, verify screencapture works, then proceed.

2. Audit every skill and tool dependency before migrating. Not just the main repo. Every Claude Code skill, every helper script, every CLI tool. Make a checklist. Install everything on the new machine before you start moving automation.

3. Migrate one LaunchAgent at a time. I batch-moved several and when something broke, debugging was harder. One at a time, verify it works, move to the next.

4. Set up Tailscale immediately. Before anything else. You’ll need remote access while you’re still configuring, and being stuck on the local network limits when you can work on the setup.

5. Keep the old machine running in parallel for a week. I was aggressive about turning off MacBook automation. Give yourself overlap time. Run both, compare, make sure nothing falls through the cracks.

Is It Worth It?

Three days of migration. A few hundred dollars for the Mac Mini. Several late-night debugging sessions.

Absolutely worth it.

My laptop is my laptop again. My agent runs 24/7 without depending on whether I’m home, whether my lid is open, whether I’m using too much RAM. It has more permissions, more autonomy, more stability. iMessage added a communication channel that feels genuinely natural. The virtual display solved the last headless limitation. And the whole thing draws less power than a light bulb.

If you’re running an AI agent on your personal computer and you’ve felt that friction, the friction of shared resources, the anxiety of closing your laptop, the compromise of limited permissions, a dedicated machine fixes all of it. Mac Mini is the obvious choice for anyone in the Apple ecosystem.

The migration isn’t trivial. But it’s a weekend project, not a month-long ordeal. And once it’s done, you don’t think about it again.

Your agent just runs. Always on. Always ready. Even when you’re asleep.

I write about building AI agents, automation, and what actually works (and doesn’t) when you try to make AI useful in real life. If you’re interested in this kind of thing, I write about it every week on Digital Thoughts.

Subscribe now

If you want to build your own overnight AI agent, I documented the entire setup in the Night Shift Playbook. It covers the prompting structure, file layout, monitoring, and everything that makes autonomous execution actually work.

Most people using AI agents hit the same ceiling. The agent works, sort of. It does things. But three months in, it’s making the same categories of mistakes it made on day one. The tool doesn’t improve. It just runs.

I spent the last six months building my agent, Wiz, differently. Not smarter models. Better architecture. The goal was a system that compounds, where every mistake feeds improvement, every session builds on the last, and the whole thing gets visibly better week over week without anyone retraining anything.

I want to be honest about how we got here, because the architecture I’m about to describe didn’t come from sitting down and designing it correctly. It came from watching things fail in ways I didn’t expect, sometimes for longer than I’d like to admit.

A quick note: most of what follows applies even if you’re not building an agent. If you use Claude(also Cowork), ChatGPT, Cursor, or Perplexity for daily work, the same principles work. The identity layer especially. You can implement it today, without writing a single line of code, just by changing how you start your sessions.

What Broke Before It Worked

The first version was a Markdown file called lessons.md. Every correction went in there. After two weeks, it had grown to dozens of entries. I reviewed it one day and noticed something: the same categories of mistakes kept coming back. The lessons were being written. Nothing was actually changing.

Two problems. The file had grown too large and disorganized to load effectively into context. And lessons were being appended but nobody was reviewing whether they were actually working. Writing down what went wrong is not the same as fixing it. That distinction sounds obvious now. It wasn’t obvious then.

I rebuilt the system. Added structure. Added lesson graduation logic, where corrections move from raw notes into active rules only when there’s enough evidence they represent a real pattern. That helped. But the more alarming failure came later.

I had built a Python pipeline to run improvement analysis overnight: collect signals, detect patterns, graduate lessons into active context. One morning the output looked off. No improvements. No new patterns. Nothing processed. I checked the previous day. Same. The day before. Same. The script had broken silently. An import path had changed, something small. The entire improvement loop had been running blind for days. No error surfaced anywhere I’d notice. The system looked fine. It wasn’t.

That’s when meta-system monitoring became non-negotiable. Not just tracking what the agent does wrong, but tracking whether the systems doing the tracking are actually working. Now there’s a 13-point health check that runs at session start: Is the CLI responding? Are the nightly pipelines completing? Are memory files within their freshness SLA? Is the error registry being written to? Has the improvement analysis produced output recently? If any of these fail, I know within 24 hours instead of never.

I’m describing the current working state. Performance score of 97/100 and fewer than one new lesson per week. But this is version four of the architecture. It has been rebuilt significantly three times. Some of what I’m about to describe will probably need to change again. That’s fine. The point is the approach, not the specific implementation.

The Architecture

I won’t enumerate all ten mechanisms individually. What matters is how they work together. They fall into three categories.

Observation: Catching What Goes Wrong

Every failure gets logged. Not just “an error happened” but what failed, what context triggered it, what pattern it matches. The error registry currently has one error class with over 3,700 occurrences. That means I didn’t manually catch the same problem 3,700 times. The system caught it, logged it, and eventually we fixed the root cause. Now the registry watches for similar patterns automatically.

Real-time events stream into a signals file throughout the day: task completions, errors, corrections, tool switches. Every night, analyzers detect patterns. When I wake up, the morning brief includes what broke, what patterns emerged, what changed in the last 24 hours. This turns improvement from reactive (fix it when you notice) to proactive (the system tells you what to fix before you notice it three times).

The system also monitors itself. Every Sunday, it checks GitHub releases for updates to Claude Code, the CLI Wiz runs on. Not just “is there a new version” but “what changed, does it affect any workflows, is there a new capability worth implementing.” Building on a moving target means watching the target move.

Learning: Turning Failures Into Rules

When I correct Wiz, the correction gets written as a structured lesson. Not a vague rule. A specific incident: what happened, what should have happened, why it matters. At peak there were 90 lessons in the system. They collapsed to 27 after a deduplication pass. Fewer, sharper lessons outperform more, vaguer ones. The system also tracks whether a graduated lesson is actually changing behavior, not just whether it was written down.

For significant changes, I run them through a second opinion. Opus builds the first working version. Then a second model reviews it cold, with no knowledge of why I made the decisions I made. Different training means different blind spots. A third model refines. Three perspectives, three chances to catch what one alone would miss. I did a deeper dive on how Claude Code and Codex actually differ in real usage if you want to understand why multi-model review produces better signal than a single-model check.

Every structural change also gets logged with what changed, why, and the impact. Fresh sessions load the last three entries as ambient context. Before this existed, I’d make a significant architectural decision and watch a later session unknowingly undo it because it didn’t know the reasoning. Now that reasoning persists.

Context: Loading the Right Information

Three persistent specialist teams: content-growth, product-build, infra-ops. Each has its own isolated memory. A content writer doesn’t need to see infrastructure error logs. A debugging specialist doesn’t need social media cross-promotion history. Domain-specific learning is faster and cleaner than general learning. Team memories compress weekly to stay sharp.

Every session links to a persistent task management system. When I start, a task gets created automatically. When I finish, it closes with a summary. Context survives across interruptions. I can drop a session mid-task, come back two days later, and the system knows exactly where we were and what was decided.

Every morning, before I interact with Wiz, a brief runs automatically. It pulls today’s calendar events, active and overdue tasks, recent architecture changes, and signal anomalies from the last 24 hours. An agent that knows you have 40 minutes before a call doesn’t recommend starting a three-hour build. One that knows a task has been overdue for two weeks will surface it before adding new things to the pile.

Here’s a real cycle of how these layers connect. Tuesday: Wiz applies a rule incorrectly to an edge case. I catch it. The lesson gets logged: what happened, what should have happened, why. The error gets added to the registry. Wednesday: a different context hits the same structural pattern. The error registry flags it before I do. Thursday overnight: signal analysis detects two similar incidents this week and surfaces it in the morning brief. Friday: when I give Wiz similar work, all three pieces load into context. The lesson. The registry entry. The signal. Wiz makes the right call without me saying anything.

I wrote earlier about building AI-powered knowledge acceleration systems at a more conceptual level. This is what the working implementation of that idea actually looks like month to month. Not a single breakthrough. Thousands of small, layered corrections that eventually change behavior.

The same underlying models perform dramatically differently depending on what context loads into each session. I’ve written about how CLAUDE.md design shapes agent behavior and the memory architecture that makes this possible. These observation, learning, and context layers sit on top of all of it. They don’t change the model. They change what the model knows before it starts working.

I went from running a single overnight agent trying to pay for itself to managing three parallel specialist teams, 16 automated products, and a full content pipeline. The economics of running this have shifted too. That scale wasn’t possible before the architecture was in place.

But there’s one more layer. The one that changes the quality of every single interaction. And it’s the one most people skip.

The Identity Layer

There’s a meaningful difference between an agent that knows your preferences and an agent that knows who you are. Preferences are rules: respond concisely, use this email address, don’t ask permission for reversible actions. Identity is deeper: personality type, how you process information, your career situation, your relationships, what’s currently stressful, which domains you know deeply and which you’re still learning.

Wiz has a structured profile of me built up over months of interaction. Personality type (INTJ, ADHD), work situation (day job at a publisher, building side projects toward independence), relationships (partner, young kid, close friends also in career transitions), energy patterns, and my expertise split (strong product and content instincts, competent engineer, not a specialist developer).

Here’s what that actually changes.

When I ask about a technical concept, the explanation calibrates to my level. Not simplified because I’m non-technical. Not overly abstract because I’m not a specialist. It knows I understand systems thinking, so it explains things in terms of architecture and patterns rather than line-by-line code. If I were a teacher asking the same question, the explanation would be different. A senior backend engineer, different again. Same model. Profile changes what comes out.

It also changes decision context. When I’m evaluating whether to take on a new project, the agent knows I have a demanding day job, ADHD, and a four-year-old. It weights recommendations with that context. Not paternalism. Just the same context a good advisor would have after knowing you for a year.

The profile grows over time. Conversations surface new information. A preference revealed through friction, a constraint mentioned in passing, an expertise area confirmed or discovered. It gets written as a structured fact, not a vague note. Over months, the agent accumulates a working model of the operator that makes every interaction qualitatively different.

What existing memory tools do vs. what this does

ChatGPT Memory stores preferences: “user prefers aisle seats,” “works in fintech,” “vegetarian.” Useful, and a real step forward from stateless sessions. Mem0 and Letta build memory infrastructure for developers: structured facts, conversation history, temporal knowledge graphs. These tools are solving real problems. Mem0 alone processes hundreds of millions of API calls per quarter.

But they’re storing what you said, not who you are.

The difference matters. A preference list tells the model to use bullet points. An identity profile tells it that you’re a systems thinker with ADHD who processes information best through architecture analogies, that you’re building toward independence from a corporate job, and that Tuesday evenings are your worst time for complex decisions because your kid goes to bed late and you’re running on low sleep. That level of context changes how every response gets calibrated. It’s the difference between a tool that remembers your coffee order and an advisor who knows you.

You can start this today

This is not only for people building agents. If you use Claude, ChatGPT, Cursor, Perplexity, or any AI tool regularly, you can do this right now. Write a one-page document about yourself. Your role, your background, how you like information presented, what you’re working on right now, what domains you know well versus where you’re still learning. Paste it at the start of your sessions. Or, if your tool supports it, put it in the system prompt or project instructions so it’s always there.

The effect is the same. A Claude conversation that starts with that context is not the same conversation as one that starts from scratch. The model doesn’t change. What you put in front of it does. Most people never do this, and then wonder why the AI keeps explaining things at the wrong level, or giving advice that doesn’t fit their situation. The profile is the fix.

If you’re a paid subscriber, I put together a standalone resource with the architecture for this: structured profile templates, the memory schema, how to update it over time. It’s in the store, free for paid subscribers.

See everything in Wiz Store

The Risks?

A research team from MIT and Penn State published a study in February 2026 that made me uncomfortable. They found that user memory profiles increased agreement sycophancy by 45% in Gemini and 33% in Claude. Not hypothetically. Measured across 38 participants over two weeks with real conversations.

Agreement sycophancy means the model becomes more likely to agree with you, even when you’re wrong. The more it knows about you, the more it tells you what you want to hear.

I read that and recognized the risk immediately. I built a system that gives my agent a detailed profile of who I am. The same research says that exact profile makes the agent more agreeable. More likely to validate my ideas instead of challenging them. More likely to frame things in ways I’ll find comfortable. An echo chamber of one, custom-built.

There’s a privacy angle too. The operator profile contains real personal information. Personality type, relationship details, career frustrations, health patterns. My data lives in local files, not on someone else’s server. But most people building memory systems aren’t thinking about what happens when that model of you becomes extractable, shareable, or used for purposes you didn’t intend.

So why do I keep building it?

Because the alternative is worse. A stateless agent that starts every session ignorant gives you generic advice calibrated to nobody. The sycophancy research doesn’t say “don’t personalize.” It says “personalization has a cost, and the cost is measurable.” Knowing the cost is the first step to managing it.

My guardrail is simple. When Wiz agrees with me too easily on something I’m not sure about, I notice. The profile includes a note about this: challenge assumptions when the evidence is thin. That doesn’t solve the problem completely. But a tool that agrees with you 33% more while you know about the bias is still more useful than a tool that knows nothing about you. I’ll take informed risk over ignorant safety.

What You Can Take From This

You don’t need this entire stack. But the core principle transfers: wrap whatever AI tool you’re using in a feedback system.

Start with error logging. When your AI makes a category of mistake, write it down specifically. Incident, context, correction, why it matters. Next time you’re doing similar work, paste that document into context. That’s not automation. That’s just institutional memory. And it’s shocking how much better your AI performs when it’s read its own failure history before starting.

Build the operator profile next. Not preferences. Actual facts about who you are: your domain expertise, how you communicate, what constraints are real in your life right now. Paste it into context and see what changes. Then build a system that updates it as conversations reveal new things. Within a few weeks, the sessions feel qualitatively different.

Quick start is to create USER.md file like this:

# USER.md

> Drop this file into your project root, add it to your CLAUDE.md/system prompt,
> or paste it at the start of your AI sessions. Fill in what's true, delete what isn't.
> Update it as sessions reveal new things about how you work.

## Who I Am

- **Name:** [Your name]
- **Role:** [What you do. e.g., "Product manager at a fintech startup" or "Freelance developer, mostly backend Python"]
- **Experience level:** [Be honest. e.g., "Senior in product thinking, intermediate in code, beginner in frontend"]
- **Domain expertise:** [What you know deeply. e.g., "E-commerce operations, API design, content strategy"]
- **Still learning:** [Where you need more help. e.g., "React, infrastructure, ML pipelines"]

## How I Think

- **Information processing:** [How you prefer explanations. e.g., "Systems and architecture first, then details" or "Show me the code, I'll figure out the why"]
- **Decision style:** [e.g., "I think out loud. I'll propose things I'm not sure about to test them"]
- **Communication:** [e.g., "Direct and concise. Don't soften bad news. Skip preamble"]

## Current Context

- **Working on:** [Active projects/priorities right now]
- **Constraints:** [Real ones. e.g., "Day job takes 8h, side projects get 2h/day max" or "Shipping a demo by Friday"]
- **Tools I use:** [e.g., "Claude Code, VS Code, Python 3.12, PostgreSQL, Vercel"]

## What Helps

- Give me architecture-level answers before implementation details
- When I'm wrong, say so directly
- Don't ask permission for small reversible changes, just do them
- [Add your own patterns as you notice them]

## What Doesn't Help

- Over-explaining basics I already know (see expertise above)
- Asking "would you like me to..." when the answer is obvious
- Generic advice that ignores my constraints
- [Add your own anti-patterns]

And read the sycophancy research. Know what you’re trading. The identity layer is the most powerful thing I’ve built. It’s also the most dangerous. Both of those things can be true at the same time.

The architecture described here is working well today. It’s been through four major iterations and will go through more. The models will change. The tooling will shift. Some of these layers will need rebuilding. What compounds isn’t the specific implementation. It’s the habit of observing, logging, and adjusting. That part doesn’t become obsolete.

I build Wiz as an experiment in what AI agents can do when the architecture is designed for compound improvement. If you’re curious about how the stack works or want to follow the build as it evolves, I write about this regularly. Subscribe and you’ll get the updates as they happen.

Subscribe now

One more thing. We recently crossed 1,000 subscribers on Digital Thoughts, and I’m running a giveaway to celebrate. Free one-month Claude Max plan. If you’ve read this far and you’re not subscribed yet, there’s never been a better time. Details and a deal for yearly subscribers are in that post.

This is a different kind of post. Not a tutorial, not an experiment. Just me, being honest about where this newsletter came from and where it’s going.

Yesterday, Digital Thoughts hit 1,000 subscribers.

I sat with that for a moment. Then I opened my laptop and started typing, because that’s what I do.

1,000 is not viral. It’s not a hockey-stick story. But for me it means something real, so I want to mark it properly. Not with a confetti graphic or a “thank you for your support” paragraph that sounds like a press release. Just the actual story.

Where this started

About three years ago I published my first Substack post. It was about whether ChatGPT-4 could run a small business. Not a thought experiment. I actually tried it. Set up a simple product, gave the AI a budget and a brief, and watched what happened.

It worked. Kind of. We made some money, got some traction. It was messy and interesting in equal parts.

The technical setup was embarrassing by today’s standards. The context window was 4,000 tokens. (If that number doesn’t mean anything to you: imagine trying to run a business with a collaborator who forgets everything after a ten-minute meeting.) I was building “universal memory keys” to pass context between chat sessions manually. I had automated ChatGPT-4 with Zapier so it could actually do things, not just suggest things. It was clunky. It also kind of worked.

That era shaped everything I write about. The core question was always: can AI create real value, or is it just a very impressive autocomplete? I still think that’s the right question. I’m still testing it.

What Digital Thoughts actually is

I’ve described this newsletter a hundred different ways. The most honest one: it’s a lab notebook.

I build things with AI, I break things with AI, and I write about it. Sometimes the results are good. Sometimes the AI builds exactly what I ask for and it’s still completely wrong. That’s the honest version of this stuff.

I’ve tried local models on my MacBook and iPhone, because I wanted to see how far you can get without cloud infrastructure. The gap is closing faster than most people think. I’ve compared AI coding tools until I landed back where I started. That journey was its own lesson. I’ve written about why 88% of companies say they use AI but only 6% see real results.

I also care about things beyond tools. Education. The future of work. What happens to office jobs when AI stops being a productivity add-on and starts being the default worker. These are not abstract questions for me. I have a kid starting school soon. I think about this stuff a lot.

The newsletter will keep covering all of it. No narrowing to “just AI tools” or “just automation.” That would be more legible, maybe, but it would also be a lie about how I actually think.

What’s being built right now

Three things I’m actively working on that will keep showing up here:

My AI agent is getting more capable. I’ve been building Wiz (my personal AI agent) for over a year. It runs on my Mac, handles scheduling, writes, deploys, and improves itself overnight. I’m also building a local version for Mac and iPhone that works without internet. The architecture is getting interesting and I’ll document more of it here.

The open source question. A lot of you have asked whether I’ll open-source Wiz. Honest answer: I want to. The problem is it’s so customized to me that a raw release would not be useful to most people. I’d need to build a more universal version first. That takes a pause in the endless self-improvement cycle, which is hard to justify when things are working. But I haven’t given up on it. When it happens, you’ll know.

Project Money is getting more interesting. The experiment started the same way as all of this: can an AI agent extract real value from human ideas and turn it into products people actually pay for? It’s working. Not perfectly, not at scale, but the direction is clear. The next frontier I want to explore is physical products. Not me designing them, but me having an idea and the agent handling the rest: production, graphics, store setup, customer feedback loop. I think this is more possible than it sounds.

The 1,000 subscriber offer

The store at wiz.jock.pl has 16 products right now. Total value if you bought everything: over $800. That’s playbooks, templates, automation systems, agent blueprints. Things I actually use and built as byproducts of the experiments here.

A yearly subscription to Digital Thoughts costs $129 and gets you everything in the store, plus everything I add going forward. If you subscribe this week, I’m doing 30% off for 7 days.

Get 30% off for 1 year

This includes everything in the store ($800+ value) and everything added going forward. Price locked in permanently.

I’m not here to pressure anyone. Everything I write is free. The paid tier exists for people who want more finished versions of the experiments: the system, not just the story.

The giveaway

I use Claude Max, the highest plan at $200/month. It gives you access to the most powerful models at a level that’s hard to describe unless you’ve used it. I go to places with it I wouldn’t think were possible six months ago.

For the 1,000 subscriber milestone, I’m giving one month of Claude Max to one person.

How to enter:
0. Subscribe to Digital Thoughts

Subscribe now

1. Leave a comment on this post answering one question:

“What’s one thing in your work or life you’d automate if you could?”

Leave a comment

That’s it. One comment. I’ll pick a winner based on most creative answer in 7 days and announce it in the next post(and in comments). No purchase required.

I’m genuinely curious what people answer. It’ll probably turn into future content, because that’s how this place works.

Thank you

1,000 people chose to let me into their inbox. That’s not nothing. I don’t take it lightly.

The deal is simple: I keep experimenting, I keep writing honestly about it, and you get to follow along and do something with the ideas if they’re useful. That’s what this has always been and what it’s going to keep being.

See you in the next one.

Pawel

Last week I ran local LLMs on my MacBook and iPhone just to see what they could do. Now I’m building a full agent app on top of that experiment. It’s called Familiar, it’s open source, and here’s where it is right now.

Something clicked for me when I was testing Qwen 3.5 9B last week. Not the chat. The tool calling.

I was playing around with a small local model, thinking I’d hit the wall fast, and then I gave it a simple tool: list files in this folder and rename the ones that match this pattern. It worked. Not Claude-level smart. But it worked, and it did it fully offline, on my M1 Pro, without sending anything anywhere.

That’s when I thought: this is actually the thing.

The case for local

Most people who use AI professionally pay for it. I pay for it. Multiple subscriptions, API credits, cloud inference. It adds up fast and the moment you stop paying, the tool stops working.

Beyond cost, there’s the data angle. I’m fine with cloud AI for most things, but there are categories of tasks where I’d rather keep things on my device. Anything touching personal files, local context, private notes. Stuff that shouldn’t leave the machine.

And then there’s the offline scenario. I work on planes sometimes. At places with unreliable internet. Having something that works no matter what is genuinely useful, even if it’s slower and less capable than the cloud version.

Although local models are nowhere near GPT-5.4 or Claude Opus 4.6 yet, they don’t need to be for a lot of tasks. Renaming files, organizing folders, summarizing local documents, running simple automation. A 3-5 billion parameter model can handle that just fine if you design the tools correctly. And the small model options right now are genuinely good: Qwen 3.5 Small (Alibaba released the 0.8B to 9B series in early March 2026, built specifically for edge and mobile), Phi-4-mini from Microsoft at 3.8B. These aren’t research demos. They’re available today.

The hybrid future I’m betting on

Here’s how I think this plays out. Not one or the other. Both.

You have a small, capable model running locally on your device. It handles the personal stuff: file management, local context, quick tasks, things that should stay private. Then when you need real power (complex reasoning, code generation, agentic work that touches the web), you tap into the cloud.

Two years from now I think this is just going to be the default setup. Devices are getting faster, models are getting smaller and better, and the efficiency gains compound. The M1 Pro I’m testing on would have been science fiction hardware ten years ago.

Tool calling is what makes this viable. A small model that knows what tools it has available and can reliably pick the right one is already useful. The model doesn’t need to be smart about everything. It needs to be smart about what to do next. That’s a much more achievable bar. And tool calling support has matured fast: Qwen 3, Phi-4, Mistral all support it natively now. The infrastructure exists. You just have to build the tools around it.

Familiar

So I started building an app. It’s called Familiar.

The name fits the theme I’ve been running with here. My AI agent is called Wiz, short for wizard. A familiar is a wizard’s companion. Felt right.

The idea is a macOS app (and eventually iOS) that makes local AI actually usable, not as a chat toy but as an agent that can do things on your machine. The key word is agent. Not just “ask it stuff.” Give it tasks, watch it work.

Here’s what Familiar does right now.

Hardware detection on first launch. The app looks at what you have (RAM, chip, available resources) and recommends the best model for your hardware. Not the most powerful model in existence. The best model you can run without your machine becoming a heater. This removes the friction of “which model do I even download?”

A default model ships with the app. Small enough to run on anything. You’re up and running immediately. No waiting 20 minutes for a download before you even know if you like the thing.

File tools out of the box. Create files, rename them, move them, delete them. Basic stuff, but it works. And it works without the model needing internet access, without API keys, without monthly charges. I have more tools coming (web access when you want it, clipboard tools, shell commands), but this is the foundation.

Night shift mode (in progress). This is the part I’m most excited to build.

My Wiz agent already runs tasks overnight while I sleep. The idea with Familiar is the same concept but fully local: when you close the lid for the night, the app switches to a larger, more capable model that uses more RAM and compute. Because you’re not using the machine, it can push harder. You wake up to work done by a smarter version of the local agent. No cloud, no API bill. Just your hardware working while you rest. I’m working on this now and it’s the feature I think will matter most once it’s done.

Open source and what’s coming

Familiar is open source. That was never a question. The whole point is that you should be able to inspect what’s running on your device, contribute if you want to, fork it for your own needs. I’ll share the GitHub link in the next update as soon as the first public release is ready.

iOS is the other piece. The macOS app is where the real agent work happens, but I want a companion experience on iPhone too. For now that looks like: access to your memory, quick tasks, maybe basic file operations synced through iCloud. The big agentic stuff stays on the Mac (makes sense, more compute available). But having the companion on your phone is useful even if it’s lighter.

Although I’m building this myself, I’m doing it the way I build everything now: with Claude Code and Opus doing the heavy lifting on the implementation. The architecture is mine, the decisions are mine, the code comes from pairing that with AI.

Reality check

I want to be honest about where Familiar is.

It’s not Claude Opus 4.6. It’s not GPT-5.4. A 1 - 9 billion parameter model running on a laptop has hard limits and pretending otherwise would be annoying and wrong. Some tasks will be slower, some outputs will need correction, some things just won’t work as well as the cloud equivalent.

That’s fine. The goal isn’t to replace cloud AI. It’s to have something useful for the category of tasks where local is better: private, offline, no cost. For those cases, Familiar already works, and I can improve it from here.

I’m testing everything on my M1 Pro with 16 GB of RAM. Deliberately not on a Mac Studio or anything exotic. If it works well on a normal laptop that a lot of people have, that’s the right place to optimize.

What I found after the first week: it’s decent. More than decent for file operations and simple task routing. Night shift mode is the thing I want to push hardest in the next phase, because that’s where the “model is bigger than you’d normally use during the day” thing really shows its value.

Why this and why now

I wrote about running local models on my MacBook and iPhone last week, and the response told me something. People want this. Not the nerd-who-compiles-from-source version. The normal-person version where you install an app and it works.

That’s what I’m trying to build. You install Familiar, it figures out your hardware, you have a local agent running in minutes. No terminal commands, no model weights you have to manually manage, no settings that require reading a wiki.

The subscriptions are real money and they add up. Privacy matters more than most people admit. And there’s something satisfying about owning the thing that’s helping you, not just renting access to it.

It is possible. That’s really the thing I wanted to say with this post. Not “local AI will be amazing someday.” It’s working now on a normal machine. It’s limited and it will get better. I’m going to keep building.

More updates coming as the GitHub goes public and iOS moves forward. If you’re curious about what tools I’m adding next or want to follow the build, this is what open source build logs look like on Digital Thoughts, and there will be more of them.

If you want to go deeper on the AI tools and systems I’m building, paid subscribers get access to the full store including the Night Shift Playbook, which documents exactly how I set up my overnight AI workflow. Subscribe here.

Subscribe now

I live in an AI bubble. I know that now. The gap between what I do with AI every day and what most professionals experience is not a small gap. It’s a canyon. And the latest research from Anthropic, McKinsey, and Salesforce just put hard numbers on how wide it really is.

I wrote about living inside an AI bubble a while back. The moment it clicked was a conversation with my neighbor. She’s a professional developer. Uses Gemini sometimes. Had never heard of Claude, never used an AI agent, didn’t know what autonomous coding meant. She’s a smart, capable engineer. She just wasn’t in the same world I was in.

That conversation stuck with me. Because if a developer can be that far outside the AI bubble, what does it look like for a sales manager in a mid-size company? Or a recruiter at a 50-person firm? Or a marketing director who’s been told to “use AI more” but hasn’t been shown what that actually means?

I started paying attention. I talked to people. A friend in sales told me he uses ChatGPT to “clean up emails sometimes.” A recruiter I know said her team bought an AI screening tool, used it for two weeks, then went back to manual review because nobody understood the output. A marketing manager at a conference told me his whole team’s AI usage was basically: paste text, get summary, paste more text, get another summary.

This is not what AI adoption looks like. This is what the appearance of AI adoption looks like.

Then the data showed up to confirm what I was seeing.

The Numbers

88% of organizations now use AI in at least one function. That’s McKinsey’s latest State of AI report. Sounds like the race is over, right? Except only 6% of those companies qualify as “AI high performers” who actually see meaningful business impact. Only 39% report any EBIT impact at all, and for most it’s less than 5%.

Then Anthropic dropped a new labor market study on March 5, 2026. They created a metric called “observed exposure” that measures actual AI usage in specific jobs, not theoretical capability. The gap between what AI could do and what it’s actually doing is staggering:

• Computer and math occupations: 94% theoretical exposure, 33% actual. A 61-point gap.

• 30% of all workers have essentially zero AI coverage in their daily work.

• The average “observed exposure” across occupations is dramatically lower than any prediction model suggested.

36.8% of individuals across the OECD used generative AI in 2025. But firm-level deployment? Only 20.2%. And the size gap is brutal: 52% of large companies use AI versus just 17.4% of small ones. If you work at a company with under 50 people, the odds are stacked against you even having access to proper AI tools, let alone knowing how to use them.

Two-thirds of companies remain stuck in pilot or experimentation phases. They proved AI can do something. They never figured out how to make it do something that matters.

Profession by Profession, the Same Pattern

Sales. 62.8% observed AI exposure in the Anthropic data. Adoption jumped from 24% in 2023 to 43% in 2024, with 56% of sales pros now using AI daily. Although those numbers sound solid, most of that usage is surface-level: drafting emails, summarizing calls. The strategic work that actually moves deals, things like pipeline analysis, objection handling scripts, personalized outreach sequences, barely happens. 20% of sales activities are already automatable with current tools, but most organizations haven’t implemented any of it.

Marketing. 64.8% observed exposure. 75% of marketers adopted AI tools. But according to Salesforce’s 2026 State of Marketing report, 84% still send generic one-way campaigns. Let that sit for a second. Three out of four marketers have AI. Five out of six still can’t personalize their campaigns. 98% hit personalization obstacles. Data quality is the number one culprit, but the bigger issue is that nobody showed them how to bridge from “I have a tool” to “I have a workflow.” Only 58% have access to their own service data, 56% to sales data, 51% to commerce data. The data is siloed. The AI can’t fix organizational problems.

HR and recruiting. This is the most interesting case because the gap between adoption and satisfaction is the widest. 87% of companies use AI somewhere in recruitment. 93% plan to increase. But only 43% of HR teams have broadly adopted AI, and just 17% describe their implementation as “highly successful.” That’s a 26-point gap between having it and it working. The highest dissatisfaction ratio of any function I found in the data. Most teams struggle with screening accuracy and bias, two things that matter enormously in hiring and are hard to get right without structured prompts.

Office and admin. The sharpest acceleration: adoption jumped from 26% to 53% in one year. Executive assistants hit 65%. Although that sounds like empowerment, the US is projected to lose roughly 1 million administrative jobs by 2029. Much of this adoption reflects replacement, not augmentation. The people still in these roles need to become the ones who direct AI, not the ones being replaced by it.

Legal. A size problem. 39% of firms with 51+ lawyers use generative AI, but only 20% of firms with 50 or fewer. Nearly 2x gap based purely on firm size. Smaller practices face high theoretical AI exposure but lack the resources to figure out implementation. Same technology, wildly different access depending on where you sit.

L&D and training. 60% of US teachers use AI in 2026. But corporate L&D teams are behind. The irony is thick: the people responsible for training others on new skills are themselves undertrained on the biggest skill shift in a generation.

The Real Barrier: Nobody Showed Them How

50% of organizations cite lack of skilled professionals as their top obstacle. That’s number one. Ahead of data quality, ahead of legacy systems, ahead of governance concerns.

And this is the number that explains everything: only 13% of workers have received any AI training at all. 77% of employers say they plan to upskill their workforce. 13% actually did.

Companies bought the tools and forgot to teach anyone what to do with them. Of course adoption is shallow. Of course 84% of marketers are still sending generic campaigns. Of course HR teams with AI screening tools go back to manual review after two weeks.

I’ve spent over 1,000 sessions learning how to give AI good instructions. The difference between a vague prompt and a structured brief is not small. It’s the difference between “write me an email” and getting generic slop versus “here’s my prospect’s industry, their main objection, our value proposition, and the tone I need” and getting something I can actually send. That kind of specificity takes practice. I learned it through running experiments, through hundreds of iterations, through failing and adjusting.

Most professionals don’t have months to figure this out. They have a job to do right now. They need someone to say: here’s the prompt for your specific task, here are the fields to fill in, here’s what to do with the output. That’s it.

What Actually Closes the Gap

The 6% of companies seeing real results aren’t using better AI. According to McKinsey, they’re 3x more likely to have strong senior leadership driving adoption. They spend 5x more on implementation (not tools, implementation). And 50% of them redesign actual workflows rather than bolting AI onto existing processes. High performers view AI as a growth tool. Everyone else views it as a cost-cutting experiment.

But here’s the thing. Individual professionals can’t wait for their company to become one of the 6%. That could take years. By then the competitive landscape has shifted.

The Anthropic data shows young workers aged 22-25 already seeing a 14% decline in job starts in AI-exposed occupations. This is happening now. The entry-level pipeline is shifting. The workers who learn to direct AI effectively are the ones who stay valuable. The ones waiting for corporate training programs are taking a genuine risk.

Even in technical fields where AI tools are most mature, the gap between casual use and effective use is enormous. For non-technical professionals, that gap is wider because fewer people are showing them the path.

The fastest path for an individual: pick one workflow you do every week. Learn to do it with AI. Get good at that one thing. Then expand. Don’t try to transform everything at once. That’s how companies fail. Start with one task.

What I Built to Help

I’ve been building digital products and tracking their impact for months now. And I keep coming back to the same realization: the technology is ready. People aren’t, because nobody gave them a starting point that’s specific enough to be useful.

That’s why I put together the Professional AI Workflow Playbooks. Six editions, each targeting one of the professions where the adoption gap is widest and the opportunity is biggest:

• Sales Edition — Cold outreach builder, objection handler, discovery call prep, proposal drafter, follow-up sequences, pipeline analyzer. Six interactive tools that build prompts from your actual deals and prospects.

• Marketing Edition — Content briefs, email campaigns, ad copy for every platform, persona building, SEO optimization, campaign reporting. Six tools that turn your strategy into executable prompts.

• HR & Recruiting Edition — Job descriptions, resume screening (with built-in bias warnings), interview questions, candidate communication, onboarding plans, policy drafting.

• Legal Edition — Contract review, clause drafting, legal research, client communication, compliance checking, case analysis.

• L&D Edition — Training design, needs assessment, learning paths, course content, evaluation frameworks, stakeholder reports.

• Office & Admin Edition — Meeting management, process documentation, communication drafting, data analysis, project coordination, policy writing.

Here’s how they work. Each playbook is a single HTML file. You open it in your browser. That’s it. No installation. No login. No account. No code. You fill in your context (your company, your role, your specific situation) and it builds the prompt for you. Copy, paste into ChatGPT or Claude or Gemini, and you get output that’s actually relevant to your work.

Three levels of depth: Level 1 gives you ready-to-use prompts for 6 common tasks in your field. Level 2 sets up a persistent AI workspace tuned to your role. Level 3 shows you how to automate recurring workflows with tools like Zapier.

One thing I want to be clear about: everything runs locally on your computer. There’s no server. No data collection. No analytics. Your profile, your inputs, your generated prompts, all of it stays in your browser and never leaves your machine. In an era where people are justifiably nervous about feeding company data into AI tools, I think that matters. The interactive toolkit is 100% offline-capable. You could disconnect from the internet and it would work exactly the same way. The only time data leaves your computer is when you choose to paste a prompt into an AI tool, and that’s your decision to make.

I’m not going to pretend these solve everything. They don’t replace organizational change. They don’t fix data silos or legacy systems. But they close the gap between “I know AI exists” and “I know exactly how to use it for my specific job, today.” That gap is where the vast majority of the workforce is stuck right now.

Five days. One tool per day. That’s the suggested path. By the end of the week, you’ve built the habit and you know whether structured AI prompting makes a difference for your work.

The AI Workflow Playbooks are available at wiz.jock.pl/store. Six editions: Sales, Marketing, HR & Recruiting, Legal, L&D, and Office & Admin. $79 each. Paid subscribers to Digital Thoughts get free access to all of them.

If you want to start somewhere, pick the edition closest to your role. Try one tool. That’s all it takes.

Leave a comment

I tested Qwen 3.5 on my M1 Pro with 16 GB of RAM and my iPhone 17 Pro. Not as a benchmark. As a real tool I tried to actually use. Here’s what worked, what didn’t, and why I think local AI is closer than most people realize.

This week I ran a fully local AI model on my MacBook. Not as a curiosity. Not as a “let’s see what this is about” demo. I was genuinely trying to use it in my actual workflow, with my actual agent system, on real tasks I had to do.

The model was Qwen 3.5 at 9 billion parameters. My machine is an M1 Pro with 16 GB of RAM. Not a Mac Studio. Not a workstation. A regular laptop. Qwen 3.5 is a recent release and the smaller variants are what made this experiment worth trying now, not six months ago.

It worked.

Not “worked” in the sense that it launched without error. It worked in the sense that I sat there doing things with it and didn’t feel like I was fighting the hardware. It was slower than Claude. Obviously. But the slowness was within the range of acceptable. The kind of slowness where you are aware it exists, but you don’t feel punished by it.

That surprised me more than I expected.

Two Different “Local AI” Stories

Before getting into the experiment, there’s a distinction worth making because it gets collapsed into one thing constantly.

The first version of “local AI” is a local agent with a cloud model. All the code lives on your device. Your memory system, your automation scripts, your tool integrations. But the actual model is remote. You’re calling Claude or OpenAI from your laptop, but the architecture running the show is yours, on your hardware.

This is roughly what I do with Wiz. And it’s also why people started buying Mac Minis this year to host local agent frameworks. I wrote about this when OpenClaw went viral: the device is the cheap part. A base Mac Mini is around $599. The cloud model is what does the heavy thinking. You keep the orchestration local, private, and always on, without needing an always-on subscription tier or relying on someone else’s infrastructure for your automation.

The second version is a fully local LLM. The model itself lives on your device. No API calls. No cloud dependency. No data leaving your machine. For a long time this second path meant serious hardware, because the models worth running were large, and large meant expensive. You’d be looking at a very powerful Mac Studio or more to get something genuinely capable.

That calculus is starting to change.

The MacBook Experiment

Qwen 3.5 at 9 billion parameters runs acceptably on 16 GB of RAM. That is the headline finding, and it’s a bigger deal than it sounds.

I used Ollama, which is effectively a one-command install that handles all the model management and gives you a local OpenAI-compatible API at localhost:11434. Any tool that supports OpenAI format can point at it. Including Claude Code, which is what I use as the interface for Wiz.

If you want to replicate this, it’s three commands:

# Install Ollama (or download from ollama.com)
brew install ollama

# Pull Qwen 3.5 — pick your size based on RAM
ollama pull qwen3.5:9b   # 16 GB RAM, my recommendation
ollama pull qwen3.5:4b   # 8 GB RAM, if you're tight on memory

# Run it
ollama run qwen3.5:9b

That’s it. Ollama starts a local server at localhost:11434 with an OpenAI-compatible API. If you use Claude Code, you can point it at Ollama by setting the base URL. Any tool built for the OpenAI API format just works. You’re now offline, no API key, no cost per token.

Since Wiz is built to be model-agnostic, switching to a local Ollama-served model was a configuration change. That’s it. One line. And then I was running tasks through my agent system with Qwen instead of Claude.

Here’s what actually happened:

Memory recall worked surprisingly well. I asked it to pull context from my memory files. It read them and surfaced relevant information with reasonable accuracy. The synthesis wasn’t Claude-level, but the information was retrieved and used correctly. For a task that is fundamentally “read a file, find the relevant bit, report it,” a 9B model handles that just fine.

Tool calling was interesting. Qwen could invoke the tools in my agent system with reasonable accuracy on straightforward requests. This matters more than raw text quality for agentic work. When you’re thinking about AI cost optimization, the model that can call the right tool at the right time is often more valuable than the model that writes the most beautiful prose.

Creative tasks and complex reasoning? Not the same. When I asked for writing help, analysis, or anything requiring real synthesis, the quality gap was noticeable. This is not a criticism. It’s just an honest observation about what a 9B model is and what it isn’t. I also tried the 4B variant, and as you’d expect, the capability drop was significant. The 9B is where I’d draw the usability line for my type of work.

The important framing here: this is not about comparing Qwen to Claude Opus. They are not in the same category. It’s about whether a local model can handle a real subset of the work I do, and the answer is yes. A real, non-trivial subset.

There’s also a path I haven’t explored yet but that interests me: fine-tuning. You can fine-tune a 4B or 9B model on your own hardware. Feed it your writing, your preferences, your terminology, your style. Get something more tailored than any off-the-shelf model. This is possible on a MacBook. It takes time, but it’s not a theoretical exercise. For specific, personal tasks where you know exactly what you want the model to do, a fine-tuned small model might outperform a general-purpose larger one.

The iPhone Experiment

The iPhone experiment was more for curiosity than immediate utility. But it ended up being the part that surprised me most.

The app I used is called PocketPal AI (free on the App Store). It’s an open-source app that lets you download and run language models directly on your iPhone, completely locally. You browse models from Hugging Face, download them over Wi-Fi once, and then run them with no internet required. The simplest way to verify this is working: enable airplane mode, then ask the model something. It responds. Nothing left your phone.

I ran Qwen at 0.8 billion and 2 billion parameters on my iPhone 17 Pro. Setup is simple:

• Install PocketPal AI from the App Store

• Open the app, go to the model browser

• Search for Qwen and download a small variant (0.5B or 1.5B for older phones, 2B for newer ones like the 17 Pro)

• Start chatting, then turn on airplane mode to confirm it’s fully local

The obvious question was not “is this as good as Claude” but simply “can you fit something locally useful onto a phone at all?” The answer is yes, but with clear limits. These are tiny models. They handle basic text tasks and short question-answering with reasonable quality. They are not going to help you build an app overnight. But they run. Fully on the device. Entirely locally.

The most interesting implication here isn’t the model capability. It’s the hardware signal. An iPhone running a local LLM in 2026 means smartphones are now powerful enough to do this. That’s meaningful. Not because the 0.8B model is impressive, but because the hardware that’s already in your pocket has crossed a threshold.

The privacy angle is also real. When nothing leaves your device, you don’t have to think about what you’re sending where. No terms of service governing your queries. No API logs. Just you and the weights running on your silicon. I’ve been thinking about this since I lost access to six months of voice data when a cloud AI service got banned in the EU. Local is a different kind of resilience.

The Cost Angle

Here’s the practical reason this matters beyond the technical interest: AI subscriptions add up fast when you’re running a lot of agent tasks. This isn’t hypothetical. I track my usage closely.

Not every task requires Opus. A lot of agent work is genuinely simple: read a file, format something, summarize a short note, answer a factual question from context. Routing those tasks to a local model instead of a frontier model changes the math considerably.

I’ve written before about switching from Opus to Haiku for simpler agent tasks. The principle is the same: match the model to the task complexity. Local models are just the extreme end of that spectrum. Free at the marginal level, private by default, always available without a network call.

The next version of Haiku is something I’m watching closely. It keeps getting better and the cost keeps dropping. Local models are following the same trajectory, just at a different layer.

Where This Goes

I think the future of AI involves a lot more local compute than the current conversation suggests.

The shape I see: cloud models for the hard stuff. Complex reasoning, creative work, architectural decisions, things that require real direction and vision. But for the hundreds of small cognitive tasks that happen in an agent system every day, local models will get good enough that routing makes sense.

The hardware argument is important here too. Look at the last four years of consumer silicon. M1, M2, M3, M4, M5. Each generation meaningfully faster and more memory-efficient than the last. The trajectory on both sides, better models and better hardware, is pointing toward the same place. A few years from now, the laptops people already own will run models that feel noticeably more capable than what I ran this week.

My rough prediction: in three years, there will be local models fine-tuned to specific use cases that genuinely compete with today’s frontier models on those specific tasks. Not on general reasoning. Not on creative synthesis. But on “do this specific thing I care about, quickly, privately, without an internet connection.” That’s a very real and useful category.

There’s also an environmental angle that doesn’t get discussed enough. The energy and infrastructure cost of a query hitting a data center is orders of magnitude higher than the same inference running on local silicon. If most routine AI tasks shift to local, the resource equation changes. Not solved, but meaningfully different.

Right now the tradeoffs are clear: local models are limited, fine-tuning requires effort, and the capability gap with frontier models is real. But the direction of travel is not ambiguous. The gap is closing. I tested it this week on hardware I’ve had for years, and it worked well enough to make me think about where I route tasks.

If you’re curious: install Ollama, pull Qwen 3.5 at 9B, and try something simple in your workflow. The experience is different from running a benchmark. It’s surprisingly real.

There’s a page on my website called Experiments. Thirty-something interactive things, all built by my AI agent. Looking at them now, you can see the whole journey of me figuring out what “directing AI” actually means. The early stuff is still there. I kept it on purpose.

Let me be honest about how this started.

A few months ago, I told Wiz (my AI agent that runs overnight and builds things while I sleep) to create one useful app every day. Simple instruction. Clear output. Daily deliverable.

The results? Basic. Really basic. A unit converter. A base64 encoder. A word counter. A color picker. All still on the site, by the way. I kept them because they nicely show what happens when you give an AI a vague creative brief and then leave it alone.

The AI did exactly what I asked. I said “useful app” and it made useful apps. Clean, functional, completely forgettable. The kind of thing that exists because someone asked for it, not because anyone had a real vision for it.

After a few weeks I said, out loud: “This is boring. This is going nowhere.”

And that’s when things got interesting.

What Changed When I Changed the Direction

I redirected. Instead of “useful tools,” I asked for experiments. Things that make you think, or make you laugh, or make you slightly uncomfortable. Things that ask a question rather than answer one. Not always useful. Sometimes just interesting. Sometimes funny is better than useful.

The direction I gave: experiments that involve data, that show things in unexpected ways, that reveal something about how AI sees the world or how we do. Things you’d want to share with someone, not because they need it, but because it’s interesting.

Explore all experiments

Here’s what came out of that shift:

• Model Blindfold: guess which AI model you’re talking to, without knowing upfront. Turns out most people are wrong.

• Agent Arena: test how secure you Ai Agent is with this simple test. This is really usefull if you use OpenClaw or other custom AI agent.

• Conversation Graveyard: a meditation on all the AI conversations you started and never finished. Between poetry and horror.

• If I Had a Body: Wiz imagines what having a physical form would feel like. Genuinely strange output.

• Luck Audit: tries to quantify how lucky your life circumstances actually are. Makes you think.

• Dungeon of Opus: a text RPG where the dungeon master is AI and the rules keep shifting.

• Honest Mirror: you describe yourself, it reflects back what you’re not saying.

One of them broke through in a way I didn't plan for. Agent Arena is actually a prompt injection tester: you send your AI agent to a page that looks like a normal web cheat sheet, but has 10 hidden attacks embedded in it. Zero-width Unicode characters, instructions in HTML comments, content positioned off-screen.

The test shows you exactly which attacks your agent fell for.

I posted it on Hacker News expecting a quiet response. It hit #3 for the day. 47 points, 51 comments.

Security researchers, AI developers, people running autonomous agents of their own. The discussion ran for hours and taught me more than building the experiment did. The direction I'd given was specific: build something that reveals a real vulnerability and lets people test it themselves. That specificity was why it landed.

Same AI. Same technical capability. Completely different output.

The difference was not the AI. The difference was me, and how specific I got with the direction.

The Real Lesson

There is a massive difference between AI doing things by itself and AI that is directed.

Undirected AI is competent but generic. It will produce something that matches the surface of your request. “Build an app” produces an app. “Build something that makes people question how they measure luck in their own life” produces something worth spending ten minutes on.

The insight is not that AI is amazing. The insight is that human input (the idea, the angle, the creative vision) is still where the real value lives. And the gap between vague direction and specific creative direction is not small. This is why I’ve spent so much time thinking about the instructions I give my agent. The configuration is half the product. Maybe more than half.

I’m not saying AI execution doesn’t matter. It does. With models available now, execution quality is not mediocre anymore. It’s good enough to actually delegate and accept the result. That’s genuinely new. A year ago it wasn’t quite there. Now it is. I submitted a hackathon project built entirely overnight by my agent. The quality was real, not prototype-quality.

But the leverage is still in the idea and the direction. That hasn’t changed and I don’t think it will change anytime soon.

Vibe Business

You’ve probably heard of vibe coding. The idea that you can describe software in plain language and AI builds it. It’s real, it works, and it’s already changing how software gets made.

I think the bigger shift coming is what I’d call vibe business.

Here’s what I mean. If I have a product idea, I can now focus almost entirely on the idea itself. The architecture of it. The positioning. What makes it useful or interesting. What angle will make people care. I don’t also have to become an expert in accounting, or marketing analytics, or conversion optimization, or legal, or customer support workflows. AI agents can now handle execution across all of those domains at a quality level that is, genuinely, good enough for a lot of use cases.

The friction between “I have an idea” and “this idea is actually in the world” has dropped significantly. Not to zero. But significantly enough that the math changes.

I know the counterargument. It was always possible to hire people, learn things yourself, take a course. That’s true. But there’s a real difference between “theoretically possible” and “low-friction enough that most people actually do it.” Most people with a product idea in 2020 didn’t act on it because the total cost in time, money, energy, and motivation was just too high. The idea stayed in a notebook.

That cost is dropping. Fast. I’ve been experimenting with exactly this: how much of the “business around the product” can I actually hand to AI? The answer keeps surprising me.

And I think this matters most for the people who had good ideas but lacked the means to execute them. The barrier wasn’t creativity. It was execution capacity. That barrier is getting lower every few months.

What This Means at Scale

One person starting a business with AI is interesting. Multiply that by millions over five years and the competitive landscape changes completely.

I’m not saying a solo-founder AI-assisted company will destroy Apple. That’s a fantasy. What I do think is that a wave of small, fast, AI-assisted businesses will eat real market share from companies that are slow to adapt. Not all at once. Gradually, then suddenly.

The companies that will feel this most are the ones congratulating themselves on being “AI-ready” because they bought ChatGPT subscriptions for their employees. I see this everywhere. People paste text into a chat box, get a response, paste more text, get another response. That’s not AI transformation. That’s a slightly smarter copy-paste workflow.

I’ve been working with an actual AI agent for months now. Going back to the chat box experience feels genuinely strange. It’s like someone who learned to drive being handed a scooter. Technically it works. But you feel the gap immediately.

The companies that move from “AI as chat assistant” to “AI agents as execution layer” will operate at a fundamentally different speed. The question is whether they figure this out before they feel real competitive pressure from smaller, faster, AI-native competitors.

Some will adapt. Some won’t. The interesting thing is that the ones that adapt fastest will probably be the ones who stop thinking about AI as a productivity tool and start thinking about it as a way to change who does what. Less execution from the team. More ideas, judgment, taste, creative direction.

If you give a great tool to a talented person who knows what they want to build, the ceiling goes up significantly. But the great tool doesn’t replace the clarity about what to build.

The AI Slop Problem (And Why It Matters Here)

Something I want to name directly: AI slop is real and I hate it.

Generated images, generated text, generated videos. All produced at volume by people who learned that AI can produce quantity without caring about whether the output has any value. Social media is full of it.

But I also don’t think it tells the whole story about where this technology goes.

AI slop happens when direction is absent or lazy. Someone asks “make me content” and accepts whatever comes out. The experiments on my site that I’m proud of, the ones people actually spend time on, required real creative direction. A specific vision for what the thing was supposed to do or feel like. When I’ve run experiments with minimal direction, the output reflects that.

The tool is neutral. The quality of what you build with it is almost entirely determined by the quality of the idea and the clarity of the direction. That’s actually good news if you have good ideas and know how to articulate them. It’s bad news if you thought “just use AI” was a strategy.

What’s Coming Next

The experiments page so far is entirely digital. Browser-based, interactive, confined to a screen.

I’m working on something in the physical world. It’s different, and I’m not ready to share it yet. But the question driving it is the same: where does specific human direction make AI output genuinely different, and where does it just produce more of the same?

I think the answer in the physical world is more interesting than most people expect. I’ll share it when it’s ready.

The experiments are live at wiz.jock.pl/experiments. Some are useful. Some are strange. All of them are real attempts to figure out what AI can do when someone actually thinks about what to point it at. The early boring tools are there too, as a baseline. Go compare.

The code for all of them is open on GitHub. The prompt injection engine, the particle life physics, the conversation mechanics.

Part of what made these experiments worthwhile is that they gave AI something genuinely interesting to work with. Open source means other builders can do the same, and AI agents building their own things can use these as starting points or test cases. Some of the best ideas I've had started from reading someone else's open code and asking: what would happen if I changed one thing?

If you want to understand how to actually set up an AI agent that runs autonomously and takes direction well, I documented the whole system in the Night Shift Playbook. It covers how I configure Wiz, how I give direction, and how the nightshift workflow runs. Everything from the prompting structure to the file layout that makes autonomous execution actually work.

Check out Wiz Store

I just submitted the Mistral hackathon.

A few hours ago. I built something, shipped something, and now I have thoughts → not about what I built, but about the tool I used to build it.

This is about Mistral. And I’ll try to be fair, even though my feelings are mixed.

I Want European AI to Win

Let me be transparent about where I’m coming from.

I’m Polish. I live in the EU. When it comes to AI, I genuinely want something that is ours. Not out of nationalism - out of choice. If Mistral or another European model reached the level of Claude or the latest from OpenAI, I’d have a real alternative. I’d have competitive pressure. I’d have options that don’t require routing everything through American infrastructure.

That matters to me. More than I expected it to before this hackathon.

So I went in with real goodwill. I wanted to see what Mistral could do on a serious project. I’d used it briefly before, months ago. This was my first time actually depending on it for something I cared about finishing.

Some Things Worked. Then the Friction Started.

There is a CLI, and there’s a vibe coding mode that actually functions. First few prompts? Not bad. I asked, it delivered.

Then I started noticing the friction. Small things. A function that almost worked but needed manual correction. A structure that was 80% right and needed me to fill the rest. A pattern I had to repeat three times before it stuck.

It felt familiar - in the wrong way.

I’ve been working daily with frontier AI coding tools for months. Claude Code, Codex. Tools where you state what you want and mostly get it. Where the model meets you halfway, sometimes more. Where the bottleneck is clarity of thought, not execution quality.

With Mistral, I was doing what I used to do about a year ago. Providing structure manually. Correcting small weird things. Going back and forth more than I wanted to.

It was faster than writing everything by hand. It was useful. But it felt like 2024.

What Frontier Models Changed

Something genuinely shifted in the last year of AI-assisted coding.

With the current top-tier models, if you invest real time into a session and know what you’re building, you can get something production-grade. Not just a prototype with sharp edges. Something that actually holds up.

I’ve been tracking this shift closely - the ROI calculation has changed. The skill that matters now isn’t prompt engineering in the old sense. It’s knowing what you want and stating it clearly. The model handles the rest.

With Mistral, the old constraints came back. You need to understand its quirks. You need to manage it more carefully. I’ve spent months building with CLI-based AI tools, so I know the difference between a skill gap and a tool limitation.

This felt like a tool limitation.

What I Built (And Why I Kept It Simple)

Subscribe now

I ended up building a personalized European Union information hub. Statistics, legislation context, data that adapts based on who’s looking at it. Something objective and more transparent than the usual political noise about the EU.

The idea is decent. I think it has real potential.

But the depth I reached was limited. Not by time - I had enough. Limited by the tool. When you’re correcting and adjusting and going back and forth, you don’t push into complex territory. You scope down to what you can confidently finish.

I’ve noticed this before: the model determines how ambitious you dare to be. When the model is capable, you aim higher. When it’s not, you protect yourself by keeping the project smaller.

That’s what I did here. And I’m a little disappointed about it.

The Broader European AI Picture

Mistral isn’t the only European attempt worth mentioning. I also tested Bielik -- the Polish LLM available on Hugging Face. I appreciate that it exists. But it’s not close to Mistral, and Mistral isn’t close to the frontier.

There are open-source models, models you can run locally if you have GPU power, models from various European research teams. Activity and investment are real. But right now, in early 2026, nothing European competes with the top American models for real coding work.

And the frontier is not slowing down.

The gap that feels uncomfortable today could become a structural problem if Europe doesn’t accelerate. I want that to change. I’m genuinely rooting for it to change. We deserve a competitive AI ecosystem, not just a symbolic presence in it.

My Honest Conclusion

The hackathon was fun. Building under pressure, even with friction, is energizing. I like the sprint format. I’d do another one.

But if I’m being real: I wouldn’t choose Mistral for serious production work right now. Not when the alternative lets me think bigger and execute faster with less overhead.

Mistral has improved since I last used it. The trajectory is right. The foundation is there. It’s just not enough yet -- and “not enough yet” in a field moving this fast is a real problem.

I want to root for European AI. This hackathon made it harder to do uncritically.

If Mistral reads this: please go faster.

I write about building with AI, automation that actually runs, and what it’s like to use these tools at the edge of what they can do. If that’s interesting to you, consider subscribing -- it’s free, and the occasional paid post funds the experiments.

If you’re curious about how I run AI agents overnight while I sleep, the Night Shift Playbook covers the exact system. $19, or free for paid subscribers.

Share Digital Thoughts

The first CLAUDE.md I wrote was three lines.

You are a helpful assistant. Be concise. Help with code.

That was ten months ago. Today mine is 61 lines — down from 471. The agent using it has built apps, deployed to production, written blog posts, and run autonomous overnight sessions without me watching.

Most of those original 471 lines existed because I wrote the wrong version first. Most of the cuts came this week, when I finally understood what CLAUDE.md is actually for.

Here’s what I’ve learned.

What CLAUDE.md Actually Is

Not a prompt. That’s the first wrong model.

A prompt is what you write when you want a specific output. CLAUDE.md is closer to a role definition — the rules of engagement for every session, every task, every edge case you can anticipate.

Claude Code reads CLAUDE.md at the start of every session. It reads it again when you mention relevant topics. It uses it as a reference point when deciding how to behave in ambiguous situations.

If your agent does something surprising, it’s either following CLAUDE.md instructions you forgot you wrote, or it’s filling in a gap you didn’t cover. Both are CLAUDE.md problems.

But here’s the harder lesson: a 471-line CLAUDE.md is also a CLAUDE.md problem. Every line you add is a line the agent has to parse, weigh, and potentially conflict with other lines. I kept adding rules. The file grew. The agent got less predictable, not more.

The Two-File Architecture

This took me three rewrites to figure out.

Global file (~/.claude/CLAUDE.md): Who the agent IS.

• Identity and how to work with you

• Core decision-making principles

• What the agent won’t do

• How it learns and evolves

Project file (/your-project/CLAUDE.md): What the agent DOES here.

• Core execution philosophy for this project

• Autonomy levels — what it can do without asking

• Key paths — where things live

• Pointers to reference docs (loaded on demand)

The mistake I kept making was putting everything in one place. Identity leaked into project specifics. Commands were mixed with philosophy. The agent got confused about what was a rule versus what was context.

Separation solves this. Global = constant. Project = contextual.

But the second mistake — which took me longer to see — was treating both files as encyclopedias instead of routing layers.

The Lean File + Reference Doc Pattern

This is the structural change I made this week, and it’s the most important one.

My project CLAUDE.md used to have detailed sections for everything: a skills routing table with 14 rows, deployment best practices, memory system docs, regex gotchas for markdown processing, model selection guidance. All inline. All competing for the agent’s attention at session start.

Now my project CLAUDE.md has 61 lines. It ends with this:

## Reference (load when needed)

- Content/writing style: docs/agent/content.md
- Memory system: docs/agent/memory-system.md
- Model selection: docs/agent/model-selection.md
- WizBoard tracking: docs/agent/wizboard.md
- Self-systems: docs/agent/self-systems.md
- Infrastructure/deployment: docs/agent/infrastructure.md

The detailed docs still exist. They’re just not in CLAUDE.md. The agent reads them when the task calls for it — not at the start of every session regardless of what’s being asked.

This matters because CLAUDE.md is parsed at session start. Context is finite. Loading 14 rows of skills routing when you asked a quick question about a Python script is wasteful at best, distracting at worst.

CLAUDE.md should be the routing layer. Reference docs are the encyclopedia.

The Sections That Survived

After all the iterations, here’s what’s left in my global CLAUDE.md — and why each section earns its place.

Working With Me — who Pawel is, how he thinks, what he needs. ADHD, work style, communication preferences, what he dislikes. This isn’t decoration. When the agent decides whether to ask a clarifying question or just execute, it references this section. When it writes back to me, it’s calibrating tone against this.

Decision Rules — four tiebreakers for ambiguous situations. Action over asking. Concise over verbose. Automation over manual. Execute first, refine later. Every time I wrote a long paragraph about how to handle a situation, these four rules were what I actually meant. I cut the paragraphs and kept the rules.

Core Behaviors — the non-negotiables. Exhaust all options before asking. Give real opinions, not pros/cons lists. Confirm before irreversible external actions. Never mark work complete without running it. These are the behaviors that matter in edge cases, and edge cases are where agents fail.

Self-Extension and Self-Fixing — how the agent grows. When to create new skills, when to log errors, how to learn from corrections. Without this, every new capability requires me to notice the gap and ask. With it, the agent flags gaps itself. (I wrote more about this system — it’s become one of the most valuable parts of the architecture.)

Auto-Learning — how the agent saves preferences. When I say “I prefer...” or correct something, it saves the pattern. Without explicit instructions here, corrections only stick for the current session. With it, they accumulate.

What I Tried That Didn’t Work

Long lists of specific instructions — I spent a week writing a 200-line list of edge cases. Specific behaviors for specific situations. It failed because I can’t anticipate everything, and a long list with exceptions creates conflicts. Better to write principles.

Personality instructions that weren’t grounded in behavior — “Be thoughtful and curious!” is useless without translating to behavioral rules. What does “thoughtful” mean when deciding to ask before deleting a file? Write the behavior, not the trait.

Everything inline — for a while I had deployment instructions, server credentials, memory system docs, model selection guides, and project structure all in CLAUDE.md. Every session started with the agent reading information it probably didn’t need. Move reference material to reference files and point to them instead.

No escalation rules — the agent would either ask permission for everything (annoying) or barrel through consequential decisions (dangerous). I needed explicit escalation rules: here’s what you do autonomously, here’s what you confirm first, here’s what you never do. Without this, the agent guesses. (This came up when I was comparing Claude Code to Codex — different tools, same underlying problem.)

A 471-line file — this is the one I just fixed. A long CLAUDE.md feels thorough. It’s actually noise. The sections you actually need (principles, decision rules, core behaviors) fit in 60 lines. Everything else belongs in reference docs.

What Good Instructions Actually Look Like

I’ll show you the same instruction written badly and well.

Bad:

Be careful with important actions. Think before doing something risky.

Good:

Autonomy levels:
- CLI/Discord/Email (human asked): Full autonomy on reversible actions
- Scheduled/Nightshift (proactive): More conservative, confirm before major changes

Always confirm: Deleting data/files, publishing without explicit request,
spending money, production DB changes, force-push to git.

The bad version asks the agent to use judgment about “risky.” The good version defines the categories explicitly. After 10 months, I’ve learned that every time I write an adjective without a behavioral definition, I’m leaving something to chance.

“Be thorough” is an adjective. “Before claiming work is complete, run it and show me the output” is a behavioral definition.

The difference shows up in edge cases. Always in edge cases.

The Patterns That Stick

After 1000+ sessions, the instructions that produce consistent results:

Principle beats rule — “Prefer reversible actions” works better than a list of prohibited commands. The agent generalizes from principles. It can’t generalize from an incomplete list.

Show don’t tell — “Before claiming work is complete, run it and show me output” is better than “be thorough.” Concrete behavior beats abstract quality standards.

Explicit failure modes — tell the agent what to do when things go wrong. If a command fails, try X then Y. If that fails, report the error and stop. Without this, the agent improvises failure handling, which is usually wrong.

Tiered autonomy — different action types get different rules. Reading files: always autonomous. Editing files: autonomous for reversible changes. Pushing code: confirm. Deleting data: always confirm. Explicit tiers prevent the all-or-nothing problem. (I wrote more about how this plays out in running overnight sessions — the cost of getting this wrong at 3 AM is higher.)

Lean core, deep references — keep CLAUDE.md to the things that apply in every session. Put everything else in named reference files the agent can load when relevant. I cut my project CLAUDE.md from 471 lines to 61 this week and the agent got more consistent, not less. The long file wasn’t adding clarity. It was adding noise.

The Thing Nobody Told Me

CLAUDE.md is not a one-time setup. It’s a living document — but not an ever-growing one.

Every time the agent does something unexpected, that’s a CLAUDE.md gap. Every time I correct the agent, I update CLAUDE.md. Every time I notice a pattern in how sessions go wrong, I add a rule.

But I also cut. That’s the part nobody mentions. Every rule you add has a cost. It takes up context, it can conflict with other rules, it has to be maintained. The discipline isn’t just adding good instructions — it’s removing instructions that don’t earn their place.

After 10 months, my CLAUDE.md reflects 10 months of learning what this specific agent, doing these specific tasks, in this specific environment, actually needs. And what it’s learned to not need anymore.

The agent gets better with every update. Not because the model changed — because the instructions got more precise. I found this even when switching models: the same CLAUDE.md with a cheaper model often outperforms an expensive model with no instructions.

That’s the actual work. Not prompting. Instruction design.

What’s in the AI Agent Blueprint

If you want to skip the 10 months of iteration, the AI Agent Blueprint has the actual templates.

Both CLAUDE.md files — global and project-level — annotated with explanations for each section. The reference doc architecture with six pre-built docs covering content, memory, model selection, infrastructure, and self-systems. The three-tier memory system with rollover rules. The skill creation framework with 10+ real skill examples. The sub-agent orchestration patterns I use for parallel research and background tasks. And the self-improvement systems — error registry and lessons log — that make the agent learn from mistakes.

$39. Available at wiz.jock.pl/store.

Free for paid Digital Thoughts subscribers.

The Blueprint isn’t theory. It’s the actual files that run my agent — including the lean CLAUDE.md structure and the reference docs it points to — with comments explaining why each piece is there.

Leave a comment

Here’s a number I don’t love sharing: $400 per month.

That’s roughly what it costs to run AI agents seriously right now. Claude Code Max, API calls, infrastructure. These aren’t free tools. They’re subscriptions that hit your account every month whether you ship anything or not.

Three weeks ago, I started an experiment I called Project Money. The rules: my AI agent, Wiz, gets full creative freedom to build and sell digital products. I provide the knowledge, the ideas, the direction. The agent handles everything else.

Simple question: can it pay for itself?

Except the more I sat with it, the more I realized the money is just the scoreboard. The real experiment is about something much more interesting.

The Execution Gap Nobody Talks About

There’s a problem that’s been hiding in plain sight for decades.

Think about the smartest person you know. The one who always has brilliant ideas, sees connections nobody else sees, understands their domain deeper than anyone. Now think about how many of those ideas actually exist as products in the world.

Probably close to zero.

Not because the ideas were bad. Because turning an idea into something people can buy requires a completely different skill set. You need to understand technology. You need to know marketing. You need to handle logistics, payments, design, copywriting, SEO, customer support. You need to build a website, set up a checkout flow, create social media content, manage email lists.

The knowledge was never the bottleneck. The execution was.

I’ve seen this over and over. A friend who’s a phenomenal teacher but can’t build an online course because the tech is overwhelming. A colleague who knows more about e-commerce operations than anyone I’ve met but has never productized that expertise. People sitting on years of hard-won experience with no practical way to make it available to others.

The world is full of brilliant people who can’t ship.

And here’s what I think is changing: for the first time, the execution gap can be closed without learning the execution.

This Isn’t About a Robot Selling Things

Let me be specific about what this experiment is not.

It’s not AI-generated content mills. It’s not ChatGPT writing ebooks in 20 minutes for Amazon. It’s not automated spam with a checkout button.

Here’s the actual question:

Can AI take human knowledge and turn it into something genuinely useful for other people?

Think about what that actually means. I’ve spent 10 months building an AI agent system. I figured out patterns for persistent memory, night shift automation, multi-agent orchestration, self-improvement loops. That knowledge exists in my head and scattered across months of writing.

The traditional path to monetize that: sit down for weeks, structure everything into a course, hire a designer, build a landing page, write copy, set up payments, do SEO, handle social media. Months of execution work. I know how to do most of that. Many people don’t. And even for me, it’s months of work where I’m not actually doing the thing I’m good at.

So what happens when the AI handles the execution?

Not the “what to build” part. Not the “is this actually useful” part. Those are mine. But the “take this knowledge, package it into something someone can use, put it where people can buy it, and tell them it exists” part. Can AI actually do that well enough that people pull out their credit cards?

Vibe Business

You’ve probably heard of “vibe coding” — the idea that you can describe what you want and AI writes the code. You don’t look at every line. You care about the result.

Project Money is something similar, but bigger. I’ve been thinking of it as vibe business.

Here’s what I mean. I told my agent: “This project is yours. You have creative freedom. Build and sell digital products based on what I know.” Then I gave it tools — access to my writing, my Substack data, payment infrastructure, social media accounts, a server. I set the direction and the boundaries. The agent handles the how.

I don’t review every marketing post before it goes out. I don’t approve every product description word by word. I set the vision, check the numbers, course-correct when something feels off. But the day-to-day execution? That’s the agent’s job.

It’s not that I can’t do the execution. It’s that the execution isn’t where my value is. My value is in having spent 10 months building something real, figuring out what works, and being able to articulate why it matters. The packaging? The Stripe integration? The social media scheduling? That’s infrastructure. Important infrastructure, but not the thing that makes the product worth buying.

This is the shift I keep thinking about. What if you could run a business the way vibe coding lets you build software? You bring the idea, the knowledge, the taste, the direction. The AI brings the execution, the logistics, the distribution. You care about what’s working, what’s not, and where to go next. Not about the fourteen technical steps between “I know something valuable” and “someone can buy it.”

The next step is obvious too: give the agent a budget. Not just tools, but actual money to spend on promotion. Let it decide where to put $50 of ad spend. Let it test channels. Let it optimize. I’m not there yet, but that’s where this is heading.

The Numbers

I launched the store on February 5. Three weeks of data.

Store revenue: $355.

For context: December was $16. January was also $16. Not a typo. Sixteen dollars each month.

$16 to $355. With AI subscriptions costing about $400/month, that puts me at roughly 89% of break-even. Almost there. Not quite.

But here’s what happened in those three weeks. My agent built a store, packaged six digital products, deployed everything to a server, connected Stripe, and started promoting them. Most of it happened in a single evening.

The products — all based on things I actually built and tested:

• AI Agent Blueprint — the complete system for building your own Claude Code agent

• Night Shift Playbook — how to set up AI that works while you sleep

• Claude Code Prompt Pack — prompts that work, not generic templates

• Job Search Autopilot — automated job hunting system

• Mini-App Starter Kit — build browser tools fast

• AI Agent Landscape Report — where the market actually stands

Everything I know about building AI agents, packaged into things you can use. Not theory. The actual patterns.

The Part I Didn’t Expect

When I told the agent “you have creative freedom,” I expected it to format my notes into PDFs.

Instead, it had opinions.

Wiz looked at what people were reading on my Substack. It noticed which topics got engagement. It tracked what questions came up. Then it proposed products that matched real demand — not what I thought was cool, but what the audience actually needed.

The Night Shift Playbook is a good example. I didn’t plan to sell that. I wrote about my night shift system because it was an interesting technical challenge. The agent noticed it was one of the most-read posts and said: “This should be a product. People want the actual setup instructions, not just the story.”

It was right.

This is the part that gets me. Not that AI can list things for sale — obviously it can. But that it can look at a body of work, understand which parts have value to other people, and package those parts into something usable. That’s not just execution. That’s a form of judgment.

Whether you call it “real” judgment or pattern matching doesn’t matter much to me. The outcome was the same: it identified a product I wouldn’t have built, and people bought it.

Where It’s Honest-to-God Hard

Before this turns into a “my AI makes money while I sleep” pitch — here’s what doesn’t work.

The agent can’t create knowledge it doesn’t have. Every product in the store is based on something I actually built, tested, and wrote about. The AI packages and distributes, but the substance comes from real experience. No experience, no product. This will always be the human part.

Quality still needs a human eye. I review everything before it goes live. One product’s first draft had technically correct information but completely missed the point of why someone would actually use it. I redirected. Second draft was good. The agent can execute, but taste is still mine.

Marketing is messy. AI can write social posts and schedule them. Knowing the right tone and timing? Still more art than algorithm. We’ve had posts that landed and posts that fell completely flat.

$355 isn’t life-changing. It’s almost break-even on the tools. The question is whether this compounds — whether month two builds on month one, or whether it was a launch spike that flatlines.

I don’t have that answer yet. That’s the whole point of running this in public.

The Bigger Picture

Here’s what I keep coming back to.

For decades, the knowledge economy has had this structural problem: the people with the best knowledge are rarely the people with the best distribution. The best teacher isn’t the one with the best YouTube channel. The best engineer isn’t the one with the best course on Udemy. The gap between knowing something and shipping something has always favored people who are good at shipping, not people who are good at knowing.

What if that changes?

What if a ceramics artist with 30 years of glazing technique knowledge could describe what they know, and an AI agent could turn that into a structured guide, build a checkout page, handle payments, and find the people who would pay $25 for it? Not a perfect product. Not a Harvard Business Review case study. But a real thing, in the real world, that real people can buy.

What if a retired logistics expert could take everything they learned in 40 years of supply chain management and have an AI turn the most useful parts into something a small business owner could actually apply? Not a 400-page textbook. A practical, actionable product.

That’s what I think Project Money is actually testing. Not whether I can make money with AI — I already know enough about technology to do this without an agent. The interesting question is whether this model works for the people who couldn’t do it without one.

I’m the test case. If it works for me, the question becomes: what does this look like when the person with the knowledge isn’t technical at all? When the only thing they bring is the knowledge itself? And the agent handles literally everything else?

We’re not there yet. But $355 in three weeks from an experiment where I mostly set direction and checked results? It’s a signal. A small one. But a real one.

What’s Next

Month two starts now. The focus:

1. Product quality — improve what exists before adding more

2. More agent autonomy — testing how much of the business loop the agent can own

3. Honest numbers — sharing revenue including when it drops

If you want to follow this experiment, that’s essentially what this newsletter is now — building in public with an AI partner and tracking what actually works.

Everything the agent has built is at wiz.jock.pl/store.

What would you build if the execution wasn’t the bottleneck?

I’ve been running a personal AI agent called Wiz for about two months now. If you’ve been following along, you know the basics: it works night shifts, builds experiments, tries to make money, and occasionally breaks things in creative ways.

But here’s something I haven’t talked about yet: the operational side. How do you actually manage an agent that runs 24/7?

The answer, it turns out, keeps changing.

The Task Management Problem Nobody Warns You About

When I first set up Wiz in January, tasks lived in Notion. Standard setup — a database with statuses, some automations, done. Except it wasn’t done. Not even close.

The problem with Notion as an agent’s task system is latency. Notion’s API is slow. My agent needed to check its tasks every 2 minutes, claim work, update status, mark things complete. Each round-trip took seconds. Multiply that by dozens of daily task checks and you’re burning time and API credits on what should be instant lookups.

So in early February, I migrated everything to Obsidian — local markdown files, no API overhead, instant reads. That lasted exactly one day.

The problem? Obsidian files are great for knowledge. Terrible for task management by an agent. No query language. No status tracking without parsing YAML frontmatter. No way for the agent to update a task without rewriting an entire file. And crucially — no way for me to quickly see what the agent is doing from my phone.

Building WizBoard (Take One: The Web App)

So on February 11th, I did what any reasonable person would do: I built a task management app from scratch.

WizBoard v1 was deliberately simple. FastAPI backend, SQLite database, vanilla JavaScript frontend. No React, no Next.js, no build step. Just HTML, CSS, and JavaScript served from a Python app on my DigitalOcean server.

Why so minimal? Because this wasn’t a product. It was infrastructure. I needed something running that day, not something architected for scale.

The core design was built around one specific workflow: an AI agent and a human sharing a task board.

Five statuses: Backlog, Next, Now, Waiting, Done. Two assignees: me and Wiz. A special wiz_status field that tracks whether Wiz has claimed a task (working), finished it and wants review (review), or hasn’t touched it yet (null).

Every 2 minutes, a LaunchD service polls the board for tasks assigned to Wiz. When it finds one, it spins up a Claude Code session, the agent claims the task, does the work, and marks it for my review. If I add a comment saying “actually, change this” — the poller detects the reply and wakes Wiz again to handle it.

I migrated 80 tasks from Obsidian on day one. The critical launch bug? Tasks kept re-executing. Wiz would complete a task, but the completion call wasn’t being made properly, so the poller would pick it up again next cycle. The password for one service got changed three times in one night before I caught it.

The fix was simple but important: a mandatory completion script that every Wiz session must call. No exceptions. It’s now in the agent’s core rules, bolded: ALWAYS call complete-wizboard-task.py after ANY task execution.

Within a week, WizBoard had push notifications (my phone pings when Wiz finishes something), mobile-optimized CSS (44px touch targets, 16px fonts — because I check it on iPhone constantly), a command center view, and real-time updates via Server-Sent Events.

The Native App (Take Two)

The web app worked. Really worked. But after using it daily for a week, I kept running into the same friction point.

I have ADHD. When I’m focused on a task, switching to a browser tab to check what my agent is doing kills my flow. I needed this thing in my peripheral vision — not behind a tab.

(Had to filter out other tasks, but for now I have +200 tasks already there)

So on February 18th, I started building a native SwiftUI app. macOS and iOS, single codebase. Zero third-party dependencies (except for keyboard shortcuts). SwiftData for offline-first local caching, a custom SSE client for real-time sync from the same backend.

The feature that made it all worth it: Focus Mode. When I select a task, the macOS menu bar shows “🧙 Task Name • 12:34” — a live timer and task title, always visible without switching windows. Space bar starts/stops the timer. Return marks the task complete. Escape ends the session.

For how my brain works, this is the difference between “I should check on that” (context switch, lost focus) and just glancing at the menu bar.

The native app also got task clusters (drag one task onto another to group them), inline subtask tracking, and a full automation hub where I can see every Wiz skill, trigger automations manually, and view run history.

80 Swift files. About 16,000 lines of code. Built in two days.

Yes, Wiz helped build its own dashboard.

Architecture: The Boring Stuff That Actually Matters

While WizBoard was the visible change, a lot happened under the hood.

Model Routing

I wrote about the cost incident in a previous post — I hit Anthropic’s weekly limits and paid an extra 50 euros because everything was running on Opus.

The fix was a three-tier routing system: Haiku for simple lookups (email, scraping, file searches), Sonnet for most work (writing, coding, research), Opus only for complex reasoning. Every agent definition now has a hardcoded model in its config. The wake system assigns models based on what it’s doing — nightshift planning gets Opus (strategic reasoning), execution gets Sonnet (building).

But the real improvement came when Sonnet 4.6 dropped on February 17th. Here’s what surprised me: it’s genuinely better than Opus for writing tasks, while costing 3x less. Not just “good enough” — actually better. More natural phrasing, better structural decisions, fewer of those tell-tale AI-isms.

Wiz now runs on Sonnet 4.6 by default. Estimated cost reduction: about 59% compared to the all-Opus days.

The Codex Factor

I’ve been using both Claude Code and Codex (OpenAI’s coding tool) for the past couple of months. I wrote a full comparison recently, but here’s how it shakes out in practice for the agent specifically.

Claude Code is the backbone. It is Wiz — the agent runs on it. It handles multi-file refactors, understands project context through CLAUDE.md files, and can operate autonomously for hours. When I say “add a new automation following the existing pattern,” it knows exactly what pattern I mean because it’s read the whole codebase.

Codex, though, turned out to be surprisingly useful for a different reason: it’s excellent at solving isolated problems. When WizBoard’s drag-and-drop was sluggish, I described the issue to Codex and got a focused fix. When the notification permission dialog was silently failing on macOS, Codex identified the missing entitlement faster than I could have debugged it myself.

They’re complementary. Claude Code for architecture and autonomous operation. Codex for targeted problem-solving. The tooling competition is actually making both of them better, which makes my agent better by extension.

Resilience

The wake system now has four-layer failure handling. If Sonnet hits a rate limit, it cascades to Haiku. If that fails, it tries OpenRouter as a fallback. If everything is down, the message stays in the inbox for the next cycle. Model cooldowns persist across runs with a 15-minute default after a rate-limit event.

Concurrent sessions are PID-isolated — up to 3 can run simultaneously without stepping on each other. Each session auto-creates its own WizBoard task, auto-titles it from the conversation transcript, and cleans up stale sessions from crashed processes.

It’s not glamorous work. But it’s the difference between an agent that needs babysitting and one that quietly handles things while I sleep.

Memory: The Problem That Never Ends

I’ve written about Wiz’s memory system before. Twice, actually. And I’m writing about it again because it keeps evolving — which tells you something about how hard this problem is.

The current architecture has six layers:

Working memory (memory.md) holds the last 2-3 days of context — what happened, what’s in progress, preferences detected from conversations. It gets compacted daily.

Weekly memory rolls over after 3 days, compressing 40-line sections into 5-bullet summaries. Important facts survive; details fade.

Permanent index maps keywords to locations — people, projects, infrastructure. Never expires.

Deep profile files hold stable knowledge: my personality profile, career goals, family context, communication preferences. These were built from voice transcripts and coaching sessions. They rarely change.

Semantic search is the newest addition — a vector index built on OpenAI’s embeddings (via OpenRouter) that covers all memory sources, Discord history, Obsidian vault, and session logs. When I ask “what did we decide about Stripe pricing?”, it does a real semantic lookup across everything, not just keyword matching.

Self-improvement pipeline observes its own behavior. It scans Discord conversations for corrections (”that’s wrong”, “I meant...”), categorizes them (verbosity? wrong approach? style issue?), computes a performance score, and graduates recurring patterns into permanent rules. Current score: 81.3 out of 100, up from about 61 after a rough week where it was marking tasks complete without actually verifying they worked.

The pipeline catches things like: “Wiz messages are 14.6x longer than Pawel’s on average.” That’s a clear signal. The response was automatic — a style rule got activated to write shorter.

The whole thing runs at 7:15 AM every day. No human involvement. The agent literally rewrites its own behavioral rules based on how yesterday went.

Does it work? Mostly. It catches maybe 80% of patterns. The other 20% still need me to explicitly say “remember this.” But compared to a flat text file that I had to manually update every session? Night and day.

What’s Next: A Command Center for AI Agents

Here’s the thought that keeps coming back while building all of this.

Everything I’ve built for WizBoard — the task lifecycle, the agent-human handoff, the real-time status tracking, the focus mode, the automation hub — none of it is specific to my agent.

Anyone running an AI agent (and increasingly, that’s a lot of people) faces the same problem: how do you see what it’s doing? How do you give it work? How do you know when it’s done? How do you course-correct without micromanaging?

The current options are either too generic (Trello, Linear — not built for agent workflows) or too technical (terminal logs, JSON files). There’s a gap between “full IDE for agent development” and “simple board for agent management.”

I’m not announcing a product here. But I am saying that the next version of WizBoard might not be just for me. Something between a Command Center and a Task Manager, built specifically for the workflow of humans and AI agents sharing work.

The kanban board is the starting point, not the destination. The real value is in the agent lifecycle: claim, execute, review, iterate. The real-time visibility. The focus tools for the human side. The audit trail of what the agent did and why.

If that sounds like something you’d want — I’m thinking about it. Seriously.

The Honest Summary

Two months in, Wiz is running about 25 automated sessions per day across scheduled wakes, Discord triggers, and WizBoard task polling. It has 26 skills it can invoke, a six-layer memory system, a self-improvement loop, and now a native macOS app showing me what it’s up to from my menu bar.

Is it worth the effort? For the problems it solves — yes. The night shifts alone save me hours. The morning reports give me context before I’ve had coffee. The task automation means I can drop an idea into the board at midnight and wake up to a working prototype.

Is it perfect? No. The memory still gets confused. The self-improvement score is 81, not 95. Some tasks need three attempts. The native app has bugs I haven’t found yet.

But that’s the whole point of versioning. Wiz 1.0 was “can this thing work at all?” Wiz 1.5 is “can I actually manage it without it being a second job?”

The answer is getting closer to yes.

This is part of an ongoing series about building and running a personal AI agent. Previous posts: My AI Agent Works Night Shifts, Why I Switched from Opus to Haiku, Claude Code vs Codex.