uv pip install ceo

Zuckerberg built himself a CEO agent. It retrieves answers he’d normally have to go through layers of people to get. The CEO of a 78,000-person company decided the fastest way to get information out of his own organization is to skip the org chart and ask an AI. We’re in the big 26, babe.

Meta employees are using personal agents internally. Two get named: My Claw, which accesses your chat logs and work files and can talk to colleagues or their colleagues’ agents on your behalf, and Second Brain, built by an employee on top of Claude, described as “an AI chief of staff.” There is an internal group where employees’ agents talk to each other.

Oh, and AI use is a factor in performance reviews.

Meta bought Manus in December for north of $2 billion, a personal agent startup. Then in March they grabbed Moltbook, the social network where AI agents talk to each other. Meta now owns both a personal agent platform and an infrastructure for agents to socialize. I don’t know what to do with that sentence either, but here we are.

There’s a darker read. Meta is planning layoffs that could hit 20% of the company. The first 700 hit last week. Maher Saba’s new applied AI org is “ultraflat,” 50 ICs per manager, “AI native from day one.” The math isn’t subtle. Flatten, automate, cut.

Six weeks ago I wrote that personal AI assistants will be as ubiquitous as smartphones. Per-person agents, each holding your context, growing with you over time. I didn’t expect one of the first companies to go all-in on that model would be Meta, or that it would happen this fast.

Mario says slow down

Mario Zechner (@badlogicgames) is the guy who built libGDX and BadLogic Games. He’s been in the trenches a long time. Most recently he also brought us the Pi framework, which happens to power OpenClaw.

His post this week is worth reading in full, but the tl;dr is that we’ve basically replaced one kind of slop with a faster kind of slop.

His argument is agents don’t learn. A human makes the same mistake a few times and eventually stops making it, either because someone screams at them or because they hate the pain they caused. An agent has no such feedback loop. It will make the same error indefinitely, at superhuman speed, with no bottleneck.

You wake up six weeks later with a codebase that’s technically 200,000 lines but is functionally untrustworthy, and the test suite your agent wrote is equally untrustworthy, and the only reliable measure of “does this work” is manual testing.

He also has a great phrase for it: merchants of learned complexity. Agents have seen a lot of terrible architecture in their training data. When you tell them to architect your application, that’s mostly what you get, enterprise cargo cult best practices and abstractions for their own sake. Except what takes human teams years to accumulate, two people and a clanker army can achieve in weeks.

I wrote something related last year that I still believe: the interesting question isn’t how to get more lines of code out of AI, it’s how to get better code. This may well translate to slower and more deliberate. Use it to explore alternatives, critique your own design, find the edge cases you missed.

The coding agent stack is converging

A lot shipped this week that on the surface looks like separate announcements but is really one story.

Codex now has plugins. Slack, Figma, Notion, Gmail, Google Drive, out of the box. They also shipped hooks, which let you inject custom logic at key points in the agent loop. So Codex went from coding agent to coding agent that can read your Slack, pull your Figma designs, check your email, and run your pre-commit scripts. Sound familiar?

Meanwhile, Claude Code got computer use. Your coding agent can now see your screen and click things. And as of today, you can call Codex directly from within Claude Code using your existing ChatGPT subscription.

So, codex gets access to your work tools. Claude Code gets access to your desktop. And then they get access to each other.

Zoom out and look at what Anthropic has recently shipped for Claude Code:

• Channels — Telegram, Discord, and iMessage forwarded into a session so Claude reacts to messages while you’re away

• Dispatch — message a task from your phone and it spawns a desktop session to handle it

• Remote Control — steer a running session from the Claude mobile app

• /loop — cron-style scheduled tasks

• Auto-Memory — Claude maintains its own MEMORY.md, accumulating your project context, coding style, and decisions across sessions

Messaging, proactive automation, persistent memory that evolves, scheduled tasks, skills, and computer use sounds like an OpenClaw feature list to me. Anthropic is rebuilding OpenClaw inside Claude Code, one release at a time.

Codex is doing the same from the other direction, plugins and hooks are how you turn a coding agent into a work agent. Both labs are converging on the same architecture that OpenClaw pioneered: a personal agent that lives on your machine, connects to your tools, remembers your context, and reaches out to you through the apps you already use.

One of them hired the guy who built it. The other is just quietly copying the homework. Real talk though, Anthropic makes incredible stuff and they do it with a conscience. This is the most exciting stretch in computing I've lived through.

There’s a Mac mini in my house that knows more about my day than I do. On the one hand, we’ve been blessed with strong reasoning models that can call tools and act on our behalf. On the other hand, we have the context of our lives boxed away in various compartments: text messages, email, chat logs, transcripts, notes, calendar.

And the models are only as good as the context you provide them.

What if we brought them together? You might say:

James, ChatGPT and Claude already have a memory system and can connect to my data sources, right?

Yes, but let me point out a few shortcomings of these existing products:

• They haven’t done a good job tying your sources together

• The memory system is mid and you don’t have control over how it works

• There’s no easy way to migrate your memories between products, i.e., vendor lock-in

• Proprietary walled gardens keep it from being truly useful

• They can’t yet reach out to you proactively in any meaningful way

OpenClaw fixes all of this mess. And it’s all open source and free as in freedom. I believe this is what Siri was supposed to be, and what the big labs wish they could make.

You text your assistant in the same app you text your friends and family. It feels like just another contact except it can reach out to you. It has real-time access to every data source you give it. It knows your life history, whatever you’ve shared, and you’d be surprised how many connections it draws across all of it.

Your memories are markdown files on your hard drive, which is beautiful simplicity and portability. OpenClaw indexes them automatically for semantic search, so the assistant can recall what it needs without you managing a database.

The system is fully open. Ask the assistant to change itself, or point Codex CLI or Claude Code at it and rebuild whatever you want. It’s software you modify by having a conversation, and that changes your relationship with every tool you use.

But there be dangers

Yep, there are dangers. You’re giving a nondeterministic beast control of a dedicated machine. It can do anything a normal computer can do, which is its greatest strength and its most obvious risk. And we’re pretty sure these models are only behaving because they know they’re being watched.

Prompt injection is still an unsolved problem. OpenClaw now ships with a security audit command, a formal trust model, and sandboxing including an OpenShell backend that came out of NVIDIA’s NemoClaw project. The blast radius is getting smaller.

The thing I didn’t appreciate as much as I should have early on is that model choice might be the single strongest safety lever you have. Older and smaller models are significantly more vulnerable to prompt injection and tool misuse. If you’re running an agent with real tools and real access, use the biggest and baddest model available. You want the best not just for intelligence but for safety.

I’m not going to tell you the risks aren’t real, because they are. But I’m pretty sure you can find an approach within your comfort zone. Here’s mine.

Do we gotta pay the Apple tax?

I run my assistant on a separate machine, a Mac mini. Listen, you don’t need one. Any dedicated PC running Linux works, a Raspberry Pi works. But a Mac mini is also a perfectly fine low-powered device and if you want native iMessage with blue bubbles on your iPhone, you need an Apple device. I think that’s worth it, but Signal, Telegram, and WhatsApp all work too.

The Mac mini setup:

• Isolated network on my home system

• Dedicated Apple ID for the assistant

• FileVault on

• Firewall on

• SIP remains enabled

The most important thing: do not sign in with your personal Apple ID. Your assistant should never have access to your keychain, your wallet, your browser sessions, any of it. Give it its own Apple ID. You’d need a separate account anyway, because otherwise you’d be texting yourself.

SIP staying enabled means no Private API with BlueBubbles, so no typing indicators, read receipts, or tapbacks. Basic send and receive works fine. You can get the full bougie experience on WhatsApp or Telegram if privacy means nothing to you, or on Signal if it does.

You may actually need two Apple machines. I’ll explain why in a moment.

Zero public exposure

Ideally you should have zero public exposure unless you know what you’re doing and really need it. There are uses cases for opening up specific services, but if you’re just starting out I highly recommend no inbound ports. SSH should be key-only with passwords disabled, but we can do better.

Everything should route through Tailscale. If you don’t know what that is listen to this perfectly reasonable explanation by Scott Tolinski (@stolinski):

In the end we want this:

• No public inbound ports

• Private device-to-device networking only (Tailscale)

• Assistant has its own Apple ID on the Mac mini

• Personal Apple ID stays on your personal machine(s) only

Use the clanker

You’ll likely want to vibe configure the whole thing. Seriously, just use the clanker. On a fresh install, clone the OpenClaw repo, and then first thing fire up Codex CLI or Claude Code the repo. It has an AGENTS.md with the full context of the docs and source code. Tell it what you want done.

Things change quickly, so I recommend you ignore any setup guides other than the docs. I’m explaining conceptually what I’ve done. If this fits for you, tell your coding agent that’s what you want. Or tweak it. Whatever. This is the future of working with software.

Texting, texting 1-2-3

There are two separate goals here:

1. I want to text my assistant from my phone like a normal contact.

2. I want my assistant to have read-only, real-time access to my personal message history.

And remember, we’re not signing my personal Apple ID into the Mac mini.

The split looks like this. The Mac mini is the assistant machine signed into a dedicated assistant Apple ID, running OpenClaw and BlueBubbles. This is the only place the assistant sends messages from. The MacBook Pro is my personal machine signed into my personal Apple ID, running the source side of imsgkit.

My first approach was an SSH forced command, a dedicated key that could only run a handful of read-only commands on my MacBook Pro over Tailscale. It worked, but it was fragile and weird. So I built imsgkit to do it properly. It’s open source, MIT licensed.

imsgkit has two pieces:

1. imsgd is a macOS daemon that reads your Messages database and publishes an incremental replica using sqlite3_rsync.

2. imsgctl is a CLI for macOS and Linux that reads the replica locally.

imsgd runs on my MacBook Pro and syncs a replica to the Mac mini every few seconds. imsgctl runs on the Mac mini and reads that replica directly. No network calls at read time, no SSH, no personal Apple ID on the assistant machine.

It ships with an agent skill, so once installed your assistant just knows how to check your messages. For OpenClaw:

openclaw skills install imsgctl

For Claude Code, Codex CLI, or any agent that supports skills:

npx skills add jpreagan/imsgkit

The security boundary is the same one I started with, just cleaner. The assistant can read my personal message history in real time but cannot act as me on my personal machine. No shell access from assistant to personal machine, no personal Apple ID on the assistant machine, outbound texting stays BlueBubbles only.

You’ve got (read-only) mail

Now for email. I have a Gmail account. Gross, I know, but it works pretty well actually thanks to the prolific Peter Steinberger (@steipete) with gogcli.

I want my assistant to answer questions about my inbox on demand, without giving it permission to send, delete, archive, or modify anything. I also don’t want to break my zero public exposure rule. So I skipped Pub/Sub and webhooks. No inbound endpoint, no public callback URL, no extra network surface area. Just pull when asked.

It’s a plain Jane setup. OAuth scopes are locked to read-only. The assistant can read, summarize, and search, but it cannot act as me in Gmail. One useful detail is your Cloud Console account and your mailbox account don’t have to be the same. The project can live under one Google account while OAuth authorization is granted by the account that actually owns the email.

End state is I ask “what’s in my inbox today?” and I get it. No modify or send scopes, no public ports, and Pub/Sub is there if I ever want proactive notifications later.

What’s next?

Once you let your hair down and stop treating the whole thing like a frightening disaster, it’s a lot of fun.

Good grief, it seems like half of Twitter will tell you the sky is falling and the other half are hustle bros exalting their 24x7 employee churning out SaaS slop that nobody uses. There is something genuinely exciting happening here, and it’s neither of those things.

The idea of a personal AI that pulls in all your data sources, knows your context, and grows with you is here. It’s running on a Mac mini in my house right now, texting me blue bubbles.

We’re still early. The rough edges are real. But the upside is massive, and the learning curve is the point. If you’re building with AI and you haven’t dogfooded a personal assistant yet, you’re missing out on all the fun.

So go off with your friendly neighborhood clanker. Start small, stay paranoid, and enjoy.

Howdy folks, things are moving fast this week. I’ve got a grab bag for you and some thoughts. Some of this is exciting, some of it is terrifying, and one of them made somebody’s Mac melt down.

Let’s get into it.

Will PRs get unalived?

The mighty pull request, also known as merge request if you speak GitLab, is the atom unit of collaborative software development.

Lately, plenty of folks are coming for them in 2026:

Eleanor Berger (@intellectronica) called this last year already:

Are PRs cooked? Man, in a way I’m getting low key nostalgic already for their loss and they haven’t even gone yet, but the truth is though things have to change. We’re in a transition period of historical proportions, so a lot of things will be quite different on the other side. Now is the time to start rethinking everything.

I’ve been watching this play out on our team. We went from a world where a PR represented hours of focused human work, and the review was a meaningful checkpoint, to a world where the agent generates the PR and another agent reviews it. The human is no longer on either side of that loop by default. We’re approvers now, not authors or reviewers.

The interesting question to me isn’t whether PRs die, but what replaces the trust mechanism they provided. PRs were never really about the code diff. They were about one human saying to another: I looked at this, and I think it’s right. When both the author and the reviewer are agents, that social contract is gone entirely. The human’s role shifts from doing the work to deciding whether the work should be done at all.

Meanwhile, Peter Steinberger (@steipete) has a different and complementary take on what’s happening to PRs in open source. He posted on X:

PRs as prompt requests. That’s a good reframe. The value isn’t the code anymore, it’s more about the problem identification. The maintainer takes the problem statement, rewrites the solution with their own agent, credits the original reporter. The back-and-forth review cycle collapses into a single step. I think this is where open source PRs are heading fast.

Codex meets OpenClaw

Speaking of agents doing the work, here’s something cool: Codex App Server Bridge just landed as a community plugin for OpenClaw.

What this does is let you bind a Telegram or Discord conversation to a Codex thread. You text it, it routes to Codex. You can resume threads, switch models, review diffs, trigger planning mode, all from a chat interface. One command to bind, then just talk.

Why does this matter? Because it collapses two things that have been separate: your personal assistant and your coding agent. Right now most of us context switch between them. You ask your assistant something, then you switch to Claude Code or Codex to actually build it, then you come back to the assistant to figure out what to do next. This plugin means your assistant can route coding work to Codex without you leaving the conversation.

This is the direction everything is heading. Not one mega agent that does it all, but a personal agent that orchestrates specialized agents on your behalf. Your assistant becomes the router, not the executor. OpenClaw already supports this with sub-agents and sessions, but having much improved Codex integration is a signal. The ecosystem is filling in the gaps faster than any single project could.

Google’s TurboQuant: cheaper inference is coming

Google Research dropped TurboQuant this week. It’s a compression algorithm that reduces LLM key-value cache memory by at least 6x and delivers up to 8x speedup with zero accuracy loss.

I’ll spare you the full paper summary, but the key insight is worth understanding. The KV cache is the memory bottleneck for long-context inference. Every token the model has seen gets cached so it doesn’t have to recompute attention from scratch. As context windows get longer, that cache gets expensive fast.

TurboQuant compresses this cache down to 3 bits per value without any fine-tuning or accuracy loss. It does this through a clever two-stage approach: first a rotation-based quantization step (PolarQuant) that simplifies the geometry of the data, then a 1-bit error correction pass (QJL) that eliminates the bias introduced by compression.

Inference cost is often the bottleneck for agent adoption. If you’re running an agent 24/7 that’s reading your email, monitoring your calendar, processing documents, you’re burning tokens constantly. Anything that makes inference cheaper and faster directly enables more people to run agents. A 6x reduction in KV cache memory means you can serve longer contexts on the same hardware, or serve the same contexts on cheaper hardware.

This won’t show up in your API bill tomorrow. But when Google deploys this across their fleet, and when it inevitably gets adopted by other providers, the cost curve for always-on agents gets a lot more favorable. The future where everyone has a personal agent is partly a cost problem, and research like this chips away at it.

Cloudflare Dynamic Workers: sandboxing, 100x faster

Cloudflare announced Dynamic Workers yesterday, and this one is significant for anyone thinking about agent security.

The problem: when an agent writes and executes code, that code needs to run somewhere safe. The current answer is mostly containers. Containers work, but they’re slow to start (hundreds of milliseconds), expensive in memory (hundreds of megabytes), and hard to scale when every user interaction might need its own sandbox.

Dynamic Workers use V8 isolates instead. A few milliseconds to start, a few megabytes of memory. That’s 100x faster and 10-100x more memory efficient than containers. You can spin up a new isolate for every single request and throw it away afterward without flinching.

Here’s the part I found most interesting. They’re pushing TypeScript as the interface language for agent-to-API communication, replacing OpenAPI specs. Their example is a TypeScript interface describing a chat room API is a handful of lines. The equivalent OpenAPI spec is so long you have to scroll. Fewer tokens to describe the API means cheaper inference and better agent comprehension.

The globalOutbound option is also pretty clever. You can intercept every HTTP request the sandboxed code makes, inject credentials, block unauthorized calls, or rewrite requests. The agent never sees the actual secrets. This is credential injection done right: the agent has the capability without having the keys.

This matters because sandboxing is one of the main unsolved problems for production agents. OpenShell (which just got added to mainline OpenClaw this week, by the way) takes a Linux-native approach with Landlock/seccomp/netns. Cloudflare is taking a V8 isolate approach. Different layers, same problem. Let agents execute code without giving them the keys to the kingdom.

Competition here is good. The more people working on agent sandboxing, the faster we all get to a world where running an agent doesn’t require a tin foil hat. I still wear mine, for the record, but I’d like the option not to.

LiteLLM got compromised (today)

And now for the terrifying one. LiteLLM version 1.82.7 and 1.82.8 was compromised on PyPI today. If you use LiteLLM, stop what you’re doing and check your version right now. If you installed or upgraded on or after March 24, 2026, you may be affected.

What happened: somebody uploaded a malicious version directly to PyPI, bypassing the normal GitHub release process. The payload harvests SSH keys, cloud credentials, .env files, database passwords, crypto wallets, and basically anything sensitive on your machine. It encrypts the haul with a hardcoded RSA key and ships it off to a domain masquerading as LiteLLM infrastructure. If it finds a Kubernetes service account, it tries to read every secret in the cluster and install persistent backdoors across all nodes.

The discovery story is almost darkly comic. Callum McMahon at FutureSearch wrote the explainer. His machine stuttered to a halt, CPU pegged at 100%, 11,000 processes running. The malware had a bug: it used a .pth file that triggers on every Python interpreter startup, so the malicious subprocess would itself trigger the .pth file, which would spawn another subprocess, which would trigger it again. Fork bomb. The malware’s own poor quality is what made it visible.

As Andrej Karpathy pointed out on X, without that bug it would have gone unnoticed for much longer. A competent attacker would have had a clean exfiltration with nobody the wiser.

Here’s what I find most instructive about this. We’ve spent a year talking about prompt injection as the existential threat to AI agents. Simon Willison (@simonw) has been hammering on the lethal trifecta. Agents with access to private data, exposure to untrusted content, and the ability to take action. And he’s right, that is a real problem.

But what actually got people this week? A supply chain attack. pip install with an unpinned dependency. No prompt injection required. The MCP client (Cursor, in this case) auto-downloaded the latest version via uvx, which pulled in the compromised LiteLLM, which ran the malware before any model was even involved.

Securing agents is not just about securing the AI part. It’s about securing the entire stack they run on, the same boring supply chain hygiene we’ve been preaching for years. Pin your dependencies. Use lock files with checksums. Audit before upgrading. The agent era doesn’t change any of this. It just raises the stakes because your agent has access to everything.

And if you’re running MCP servers locally, think hard about whether they need to be local. FutureSearch moved to a remote MCP architecture after this. The server doesn’t run on the user’s machine anymore, which collapses the entire attack surface. That’s worth considering.

Wrapping up

A lot happened this week. We’re rethinking everything as we should, inference is getting cheaper, sandboxing is getting faster, and somebody learned the hard way that pip install is still the most dangerous command in computing.

The infrastructure is catching up to the ambition. That's the pattern I keep seeing. The models were ahead of the tooling six months ago. Now the tooling is closing the gap. Sandboxing, compression, agent wiring, all of it maturing in parallel.

Just pin your dependencies.

About six weeks ago I started using OpenClaw and wrote about my initial approach. OpenClaw is a new category of personal AI assistant evolved beyond the chatbot. It’s an open source, self-hosted agent you could say has been doing the numbers. In my last newsletter, I referred to it like this:

I believe it is what Siri was supposed to be, and what the big labs wish they could make.

What the big labs wish they could make? Directionally correct I suppose, but my timeline was off. When I wrote those words on February 12, I assumed we were at least a year away from seeing anything comparable from the big labs. Further out still for enterprise adoption.

Too much risk involved for the corporate world I figured. They’d sleep while we all hack and explore. But sleep isn’t right, it’s more like stalk.

Personal AI assistants will soon be as ubiquitous as smartphones. They are so useful that once they hit mainstream adoption, it will be harder to not have one than to just have one. Just like with smartphones, there will be a tipping point. We’ll have one for home and one for work, and billions of agents will talk to humans and other agents. Sure, things are going to get weird.

Anyway, the same day I published those words I happened to hear goated builder of OpenClaw Peter Steinberger (@steipete) on Lex Fridman discuss how he was talking to and getting offers from Meta and OpenAI. Ok, I thought, they are moving fast on this. Couple days later, our man announces joining OpenAI. He mentioned his “next mission is to build an agent that even my mum can use,” which is honestly a pretty awesome goal. Right now the thing is for hackers, but everyone should have access to this technology.

Having an assistant running 24/7 on my Mac mini, I’ve been impressed by how useful it can be in my life. If you thought chatbots were great, you ain’t seen nothing yet, baby. This technology is early stage, but it’s a step change beyond anything we’ve encountered interacting with LLMs up until now. We’re at a major point in computing history.

I’m not some SaaS bro writing slop code for zero user apps, yea, there is a lot of noise online about that right now. Ugh. I'm more interested in how this technology can learn about us and help us become better family members, think deeper about the problems that matter to us, and be more healthy and efficient human beings.

OpenClaw does this by learning about you over time, and it has a hackable memory system. It doesn’t wait for you to ask. It reaches out proactively, surfacing things you need to know before you think to check. You have to experience this a few times to get why it’s different.

It also occurred to me how wickedly good personal AI assistants could be in a work environment. There are real hurdles like security boundaries and terms of service, but we’re already starting to see some of these problems get solved. They’re worth solving.

First, let’s go over how we got here.

A trip down memory lane

We all had our ChatGPT moment. Do you remember the first time you had a fluent and pretty reasonable conversation with a model? Magic. Actually, math, but yea magic.

Models did make progress, and aside from that we got three things in 2023 that made them considerably more interesting:

1. Function calling in June

2. Web search in October

3. JSON mode in November

The problem with ChatGPT was that it couldn’t “do” anything. Function calling rolled out at that time to fix that. Now we could write pieces of code that the model could decide when to call and execute at the right time with the right parameters. That was the theory anyway, but anyone who remembers working with them at the time knows the models were pretty terrible with them.

Another limitation skeptics of LLMs were quick to point out was the training cutoff date was a bigger deal than it is today. Models take a while to pre-train and go through post-training before they are released, so people loved to dunk on them for “so dumb not knowing” stuff that happened in the last few months.

Side note, I wouldn’t recommend dunking on LLMs too much. It comes across weirdly insecure, and if you give them six months you’ll be the one feeling dumb. We seem to blow through one barrier after another. There is nothing stopping progress from here on out, everything is an engineering challenge that will be solved.

Anyway, web search filled that gap, but didn’t get decently good in my opinion until o3 released in late 2024. Likewise, JSON mode was announced at OpenAI’s first DevDay, which I attended in November 2023. It was essentially a predecessor to structured outputs, which didn’t come out until August 2024.

Structured outputs is what we use today. So much better than JSON mode because now I can not only ask for a guaranteed parsable JSON response but one which conforms to a specific schema which I also define. Function calling likewise had to wait until better models came along to be useful, probably only starting in 2024 as well.

Models are only as good as the context provided to them

Over the past few years, a handful of phrases have really stuck in my head:

1. “Infinitely stable dictatorships,” a phrase Ilya Sutskever ominously warned about in a doomer moment in the 2019 iHuman documentary.

2. “Sparks of AGI” from the title of a Microsoft research paper published in 2023.

3. “Machines of loving grace,” Dario Amodei’s essay you should definitely read, which borrows its title from Richard Brautigan’s 1967 poem.

4. “Models are only as good as the context provided to them.”

The latter perhaps not exactly poetry, but one I’ve often heard repeated and for good reason. As far as I can tell, it was first stated by Mahesh Murag (@MaheshMurag) at the AI Engineer Summit in New York, 2025. At any rate, it's a simple truth I keep coming back to. In my own AI engineering experience the past few years, the models get stronger, but you need the right context or they’re useless.

I'll get back to that thought in a moment, but there is one other piece of this puzzle we need to fill in: agents. “Agents are models using tools in a loop,” a pithy definition from Hannah Moran, and one I still favor.

And trust me, trying to define what the heck even is an agent was a thing for sure. There was plenty of talk about environment that struck me as weirdly pedantic. I think folks were trying to abstractly account for things like physical robots we don't even have yet. Meanwhile, environment turned out to be… bash. An agent can ostensibly do anything a human can do on a computer via the command line (bash) and, increasingly, via screen-based interaction (computer use).

When Claude Code was released in early 2025 in tandem with Claude 3.7 Sonnet it was no doubt a watershed moment. The model was meh but improving. A lot of us were using Claude 3.5 Sonnet already to write actual production code, but it was more of a “let’s see if we can do this” or “hey wouldn’t it be fun if I just had the LLM write this for me,” and a whole lot of copy pasta between the chatbot and your IDE that no sane human being should have to do.

I’m sure we could have just written the code ourselves in less time during that period, but what is the fun in that? I was ready to automate my job away. Anyone else who tried to use chatbots to write serious code can tell you, the model really needs context of your codebase, and it ideally needs that iterative feedback loop from linters, compilers, and testing. Claude Code automated this loop.

On the one hand, if you had spent time toiling away back and forth with the chatbot then you’d have gotten pretty good at hand rolling some artistically packaged context blocks, refining as you go. These are essentially the actions Claude Code automates for you, but if you’d done so in this period, you look at today’s agentic output differently.

All I see is system prompt, user message, tool call, parameters, return, and so on. When I’m having trouble building agents or working with agents I go back to this simple thing: look at what is being sent to the model and what is coming back. With open source models, that extends to the inference server logs and, on rare occasions, even reading the server’s source code to make sure you truly understand what’s going on.

It’s not like I’m looking at the raw request of every agentic turn, but when there is trouble this is exactly where I go. This is a bit of a superpower by the way. Keep that in your back pocket.

I thought you were gonna talk about AI assistants

The genius of OpenClaw is how it’s layered. Start with an agent not unlike Claude Code built on the Pi framework in this case. It scales through bash, CLIs, and agent skills, giving it practically unlimited access to your personal context. Your messages, email, calendar, notes, health data, whatever you wire up.

Layer a persistent memory system on top of that, and now it knows you and evolves. Finally, it reaches out to you and you to it through whatever messaging apps you already use. This is what makes it different from a chatbot. A chatbot answers questions. This thing lives on your machine, accumulates context over time, and acts on your behalf.

Big tech is opening the door

Sure, you can integrate most of these data sources into ChatGPT or Claude already. But this hits different. With OpenClaw, it’s my machine, running on my home network. When it browses the web, it does so from a residential IP address. I text it through my normal messaging app, iMessages. It’s not a product someone else controls. It’s mine.

As far as I can tell, the platforms are starting to meet us halfway. Peter Steinberger built gogcli to integrate Google products early on with plenty of you can just do things energy. But Google themselves recently released a Workspace CLI built for humans and AI agents. That’s a pretty significant signal. This reads to me as a direct response to the new class of personal assistants that OpenClaw opened the door to.

It appears Microsoft isn’t far behind. A few days ago Brad Groux (@BradGroux) posted on X that more than a dozen Microsoft employees are involved in getting OpenClaw working on Teams with six dedicated to the effort. They’re dogfooding it internally. Microsoft is actively making Teams available to this class of AI assistant.

Clearly, the platforms see where this is going and they’re laying the rails. All of OpenClaw is built without first-party support. Now imagine what happens with it.

Build over buy

On the enterprise side, we’re seeing a similar signal from a different angle. Stripe, Ramp, and Coinbase have all built their own internal coding agents rather than buying off the shelf. Different approaches, Stripe forked and open source agent, Ramp composed on top of one, and Coinbase built from scratch. But I feel like the same underlying conclusion here is nobody understands your business like you do.

In short, all signs point to build right now. The platform vendors are shipping first-party CLIs and the best engineering organizations are building their own agents in-house. The writing is on the wall.

Get started now

If you’re reading this newsletter, my advice hasn’t changed: get started. Set it up. Dogfood it.

There will be polished personal AI assistants ready for mainstream use eventually. Right now while it’s still rough is the best time to learn. Same energy as hand-rolling context blocks for chatbots. It was painful, the models weren’t quite there either, but the people who did it came out the other side understanding how these systems actually work.

I believe that understanding compounds. When the safe version arrives, you won’t be learning. You’ll be building.

I spent this weekend setting up OpenClaw. It's brilliant. And I believe these type of personal assistants are the future of computing. Here's what I learned.

Why I did this

I’m a hacker. I spent years watching Siri (and any others you care to mention) struggle with basic requests and wondering why digital assistants felt so limited. The answer, I believe is walls. Walls between apps, walls between services, walls between my data and the AI that could actually use it.

OpenClaw breaks those walls down. It’s self-hosted, which means I control the data. It connects to multiple channels, which means I’m not locked into one ecosystem. And you can run it with any model from any provider.

This is the ground floor of something new. Personal assistants running on your own hardware and integrated with your actual life. Stop having opinions about whether this is a good idea. Just try it. The learning happens in the doing.

The reader and brain

Here is where I’ve started. The approach I’m taking here is one of separation. One machine holds my personal data. Another machine runs the AI. They communicate through a narrow, read-only bridge.

MacBook (Personal)              Mac mini (Brain)
- Personal Apple ID             - Bot Apple ID
- Messages and data             - OpenClaw Gateway
- Read-only message CLI         - BlueBubbles
       ↑                              ↓
       └──── SSH/Tailscale ───────────┘

My MacBook stays personal. It has my Apple ID, my messages, my files. The only thing exposed to the outside world is a restricted SSH endpoint that can read messages but not send them, access specific data but not modify it.

The brain machine runs OpenClaw. It has its own Apple ID, its own identity. BlueBubbles handles outbound messaging through this separate account. I text my assistant the way I’d text a friend, no special app, just another conversation in iMessage.

We have to bear in mind this agent is nondeterministic and runs with real permissions. It can execute commands, access files, send messages. If it gets tricked by a prompt injection buried in a message or webpage, or if it simply makes a mistake, it acts with whatever access I’ve given it.

The two-machine split limits the blast radius it seems to me. The agent on the brain machine can’t reach my Keychain, my Apple Wallet, or my personal files. It can only read messages through a narrow SSH bridge. It can’t modify them, can’t send as my personal identity, can’t escalate beyond that one forced command. Even a manipulated agent can only do damage within the boundaries I’ve drawn.

Making sense of the pieces

The hardest part wasn’t the technical setup. It was understanding the concepts. OpenClaw has a lot of moving pieces.

There’s a gateway that routes the AI. There’s an agent with the assistant’s identity and memory. There are channels for different messaging services. There are tools the agent can use. There are policies controlling what it can access. There’s a memory system, a heartbeat mechanism, scheduled jobs.

I kept reading documentation and feeling like I was missing something fundamental. I believe the best thing to do is just jump in. So start small because there is a lot of surface to cover.

I decided to begin with just text messages while I could get the feel for how it works in motion. One data source, one channel, one attack surface to understand before expanding.

The addictive part

This is where it got fun.

You have access to everything under the hood. The configuration is JSON you can read and modify. The logs tell you exactly what’s happening. When something breaks, and it will, you can trace it.

I configured the SSH bridge, tested the connection, watched the first message query flow through. I set up BlueBubbles for outbound messaging, paired my iPhone, sent a test text.

Then I asked a question that required my personal context. And got a real answer.

The response wasn’t generic. It was grounded in my actual messages, my actual life. The assistant knew things because I had given it access to know things. And it felt completely different from typing into ChatGPT in a browser.

How it works

Understanding the underlying systems helped me trust the setup more.

Memory

OpenClaw stores memories as plain Markdown files. There’s a daily log for running notes and a curated file for long-term memories. The memories are human-readable. I can open them in any text editor, see exactly what’s stored, edit or delete anything I want. No black box, no hidden database.

Before the conversation context gets too long, the system prompts the assistant to save anything important. Memories persist even when individual conversations are compacted.

Heartbeat

Every thirty minutes, or whatever interval you set, the assistant wakes up and checks a heartbeat file. This is a simple Markdown checklist: check for urgent messages, review upcoming calendar events, summarize any finished background tasks.

If nothing needs attention, it stays quiet. If something does, it surfaces it. Proactive awareness is the new paradigm.

Scheduled jobs

Cron jobs handle precise timing. A daily briefing at 7 AM. A reminder in twenty minutes. A weekly analysis every Monday morning.

Jobs can run in the main conversation context or in isolation with their own session. They can use different models, different thinking levels, deliver results to specific channels. “Remind me in 20 minutes about the call” just works.

Tools and capabilities

The gateway handles multiple CLI tools, plugins, and skills. The assistant can read and write files, execute commands, search the web, control a browser, manage calendar events, send messages across channels.

Tools are composed in layers with policies controlling access. A sandboxed context gets different capabilities than a fully trusted one. Group chats can be sandboxed or given different tool policies if you configure it.

Who should try this

OpenClaw is for hackers who love building systems. I wouldn’t recommend this for mass consumption right now as there is plenty of security risk if you’re not knowledgeable in this area or risky for anyone if you’re careless.

Although that is the thing we must build, and it must be open source so we can understand how it operates. At some point in the near future, I believe nearly every person on the planet will have a personal assistant.

If you want something that works out of the box with no configuration, wait a year. But if you want to be at the ground floor while the space is still being established, now is the time.

What’s next

I started with text messages. Next is email, then notes, calendar, and health data. Each expansion I expect will follow the same patternof understanding the data source, configuring the access, verifying the boundaries, and testing the integration.

This is day one of a long journey. We’re building the plane while flying it. The combination of capabilities, agency, memory, integration, and ownership, is what makes this different from everything that came before.

Stop having opinions. Start experimenting. This is the most exciting thing happening in AI right now, and you can run it on your own hardware this weekend.

I’m in my third year as a software engineer with the last two focused exclusively on artificial intelligence. I work from home on Hawaiʻi Island as a government contractor designing systems that use AI/ML to process information and make human tasks more efficient. As the year closes, I find myself at the moment reflecting less about what AI can do and more about who’s building it and why.

A few years ago, I started posting online about what I was learning, what I was building, and what I thought was changing. I had no audience and no particular strategy. I just wanted to think out loud and see who was thinking about the same things.

That decision opened doors for me.

VS Code + GitHub Insider Summit

In September, I was invited to the VS Code + GitHub Insider Summit in Redmond, Washington. I spent a few days in conversation with people whose blogs I’d been reading for years, whose tools I use daily. There’s still something magical about meeting someone you’ve prior only known through their work. Technology is made by people, and understanding the people changes how you understand the work.

The purpose of the summit was to discuss the future of VS Code and GitHub Copilot, what’s working, what isn’t, and where things should go. The Microsoft and GitHub teams were generous with their time and genuinely curious about what practitioners are experiencing. The level of care was evident, and that’s not something you can fake in a room that small.

Aotearoa

Then in November, I traveled with my hālau to Aotearoa. The trip was about cultural exchange, connecting our hālau with Māori communities, visiting marae, and honoring the ties between Hawaiʻi and Aotearoa.

The first leg of our journey began at WIPCE, the World Indigenous Peoples’ Conference on Education. Among the sessions I attended, several focused specifically on AI, and I found myself thinking about AI in ways I hadn’t anticipated. The talks all seem to converge on the same theme: own your data, own your infrastructure, own your future.

Te Hiku Media presented their work building a Māori speech recognition model. They’d started as a radio station in 1990, preserving recordings of native speakers, and eventually realized they were sitting on something invaluable. They had training data. Rather than hand it to Google or Apple, they built their own tools. Their ASR model now transcribes te reo Māori with 92% accuracy, trained on recordings their community contributed and still controls.

They spoke about land and data being tied to one another, and the two being inseparable. Both are inherited, both require stewardship, both can be extracted by outsiders if you’re not careful.

Dr. Lars Ailo Bongo, a Sámi researcher from Norway, put it plainly: “AI is so important our biggest worry is to be left behind.” His team used LoRA to train open weight models that accurately represent Gákti, traditional Sámi clothing. The results came from one researcher working for ten days with twenty images. Imagine, he said, what full research funding could do.

I’d arrived with a vague sense that AI might help indigenous communities. Something about land stewardship, environmental monitoring, language preservation. I left with real examples of people already doing it, and a framework for thinking about why it matters. This is what open source is actually for. For communities that have had things taken from them, it’s a way to build without asking permission.

Since coming home, I’ve been thinking about how often we interact with our phones. Siri still mangles Hawaiian place names. It can’t speak ʻōlelo Hawaiʻi. Te Hiku Media poured years into solving this for te reo Māori, and now they are partnering with UH Hilo on Lauleo, a project to build the first speech-to-text model for Hawaiian.

China

This year, China became the dominant force in open weight models, and the story is inseparable from one person. Liang Wenfeng started as a quant trader. He co-founded High-Flyer, a hedge fund that grew to manage over 100 billion yuan. In 2023, he pivoted to AI and founded DeepSeek. Unlike most lab founders chasing commercial applications, Liang wanted to do foundational research and give it away.

In late December 2024, DeepSeek released V3, a 671 billion parameter model that matched GPT-4o and Claude 3.5 Sonnet on benchmarks. The reported training cost was $5.6 million. Then on January 20, they released R1, a reasoning model that matched OpenAI’s o1 across math, code, and reasoning tasks. The release temporarily cratered Nvidia’s stock price.

In September, the R1 paper was published in Nature, and it was the first large language model to pass peer review in a major scientific journal. Nature made it the cover story. The paper disclosed a training cost of just $294,000 for the reasoning capabilities and addressed the distillation controversy directly: R1 did not learn by copying reasoning examples from OpenAI models. Eight external experts reviewed the work. Nature’s editors called it “a welcome step toward transparency and reproducibility.”

What really struck me though was the philosophy behind it. Liang has said that open sourcing doesn’t mean losing anything, and that for technical people, being followed and built upon provides a sense of accomplishment. “Giving is an extra honor,” he stated in an interview. “A company doing this has cultural attractiveness.” He believes China can’t remain a follower forever, that the real gap isn’t one or two years but the gap between originality and imitation.

His team is almost entirely young graduates from Chinese universities. No mysterious overseas talent. Just people who like solving hard problems, given the resources to try. And I believe there are several labs in existence like this in China today.

The uncomfortable tension is obvious. The same country producing researchers who share their work freely is also the country building mass surveillance infrastructure. The same tools, different hands, different outcomes. I don’t think this contradiction resolves. Individual researchers solving problems they find interesting exist alongside state apparatus that might use those solutions for control. Both are true.

Technology doesn’t have values. People do. And right now, some of the people pushing open models forward are doing it because they believe knowledge should be shared.

Lately, I hear developers say that generating AI code feels a lot like playing a slot machine. You pull the lever, hoping for a jackpot. When it hits, the feeling is incredible. “Think of all of this time I just saved!” When the results aren’t quite right, the temptation is to keep pulling the lever. Sometimes you’re just chasing a win that will never arrive.

Must be a skill issue, right? Maybe you haven’t prompted the LLM correctly? Prompting is definitely a real skill you can become good at, but it isn’t always the culprit. LLMs are designed to produce plausible output based on context, not necessarily correct or optimal solutions. But as a software engineer, your goal is to write correct code, not just plausible code.

What AI can’t do (yet)

We refer to problems being in distribution for the LLM if it’s something the model has seen frequently. The model will struggle, however, with contexts that are out of distribution. It can be challenging because you have no real way of knowing which scenario you’re dealing with here. After working with LLMs for a while, you may even develop a sense for when your problem falls into the latter category, but there is no guarantee.

This uncertainty underscores the ongoing importance of traditional programming skills, specifically coding without AI assistance. Many problems, both existing and those yet to be imagined, will remain out of distribution for AI models. That’s exactly why maintaining your traditional coding skills matters. Even as some tech influencers and business leaders tell us that coding is dead or suggest it has no future as a profession, frankly, I emphatically disagree.

Somehow, I feel like we’ve heard this claim before. In 1957, an IBM original sales brochure for FORTRAN promised that the new language would “virtually eliminate coding and debugging.” In 1981, James Martin argued in Application Development Without Programmers that with emerging nonprocedural tools end users would soon be able to build their own software applications without the need for professional coders, and job growth would flatline. In the 1990s, visual programming tools were touted as a means to replace traditional coding. More recently, no-code platforms have claimed that anyone can deliver software solutions without writing a single line of code.

Yet every time, reality unfolded differently. These tools didn’t eliminate programmers, but mainly shifted the nature of our work. Rather than shrinking, the demand for developers exploded time and time again, pushing us toward more complex and creative tasks. I predict that AI will follow the same pattern.

AI is improving, but won’t replace humans

What can we expect going forward? No doubt, LLMs will continue to improve at helping us write code. They’ll never be perfect, though, and barring one or more scientific breakthroughs that are currently not evident, the goal of completely replacing human software engineers is science fiction. The code is yours when the AI finishes, but so is the responsibility. You also can’t verify what you don’t understand.

When ChatGPT launched, it was a watershed moment. Moving from GPT-3.5 to GPT-4 felt like a step change, and what a time of possibility that was. Shortly thereafter, Anthropic’s Claude 3.5 Sonnet in particular gained a deserved reputation for its coding ability. After that, we began to see only comparatively modest improvements, and this cooling began to temper our expectations.

But then there was another breakthrough. OpenAI’s reasoning approach moved the needle again by training models to plan and verify, and by allocating additional inference-time compute. Recently, we’ve been seeing improvements in better memory management and enhanced tool integration, which have gradually advanced the coding capabilities of recent models. Despite all of this progress, all models still hallucinate and continue to struggle with novel problems outside their training data.

Your coding skills matter more than ever

This post isn’t a rebuke of AI coding tools. On the contrary, I use them daily. They’re productive and, honestly, a lot of fun too. But their utility isn’t unlimited. I believe you would be wise to take action to preserve your traditional coding skills, along with your ability to effectively collaborate with AI. As a developer today, you will almost certainly need both skill sets. I’ll share with you the strategies that help me stay sharp as coding increasingly integrates AI tools.

Let’s start with the obvious: skills are like muscles, use them or lose them. If you stop practicing a skill, it weakens over time. You’ve probably noticed this when it comes to technical interviewing. Each time you begin a new job search, if you’re like me, you likely need to refresh your LeetCode skills. With practice, you regain proficiency, pass the interviews, and move on. Then, on the job, you naturally shift focus, and your interview skills fade once more. It’s a cycle we’re all familiar with.

Your coding skills follow the same pattern. If you consistently rely only on AI-generated code without regular coding practice, your core programming skills can deteriorate. Over time, tasks that were once straightforward can become surprisingly challenging. Developers call this skill rot, and it’s real.

Is AI causing cognitive decline?

Recently, there has been concern about a widely discussed MIT study. The study measured brain activity via EEG of students writing essays either with or without ChatGPT assistance. It revealed reduced cognitive engagement among students who relied heavily on ChatGPT. Some worry this could mean similar cognitive decline might occur with coding. In practice, AI-assisted programming involves active, ongoing dialogue between you and the AI. This interaction, I would argue, still requires technical skill and deep problem-solving ability.

Let’s be clear about what is at risk here and why it matters. When I first learned programming in the 1990s, compilers still came in boxes. My syntax recall was pretty strong because I wrote programs by hand with pencil and paper. Later, when I had access to school computers with a compiler, I could type out and run my programs, but the developer tools were still limited compared to today. Syntax recall didn’t make me a good programmer, though. I was still very much learning programming, and my growth came from thinking through problems.

My point is that whether you’re solving problems traditionally or with AI, you’re still engaging in deep technical thinking. The MIT study looked at students writing essays on autopilot, which is a completely different scenario from the interactive technical back-and-forth involved when coding with AI tools. So don’t stress too much if your syntax recall weakens a bit. The real value of a software engineer is problem-solving, not syntax. That said, I’ll share some strategies on how to preserve these practical details reasonably well, but first, let’s expand a bit further on the earlier discussion about in distribution versus out of distribution problems.

AI cannot solve every problem

Some problems aren’t suited for AI because they are out of distribution. AI hasn’t encountered them often or at all during training. Advancing models and better tool integration raise the bar for what AI can handle effectively, but won’t eliminate these limitations entirely. You should understand two things about these problems: (1) AI will offer only limited value or may even be a waste of your time, and (2) these challenges often represent your most marketable skills. In other words, deep expertise in uncommon or unsolved problems is a real career advantage.

AI struggles here, making your expertise highly valuable. Some will claim AI will eventually catch up. But new problems emerge constantly, likely along with entirely new paradigms we can’t yet imagine. The world is not static. AI might speed up solving common problems, creating even more focus on complex problems for experts like you. Celebrate that AI can’t solve every problem. It’s good news. AI will handle routine tasks, allowing you to focus on the rewarding and challenging work that likely you may enjoy most.

Never trust anything that AI produces

You should be default skeptical of anything produced by AI. One of the wonderful advantages of code is that it can be read and understood. Unlike other AI outputs, you can directly verify its correctness. You can read and understand the logic, run it, test it, and confirm whether or not it meets your expectations.

Developers apparently flip into autopilot mode too readily with AI generated code, assuming it’s correct without adequate scrutiny. This can be dangerous. A Stanford study found that developers relying on AI assistants produced code with far more vulnerabilities, yet paradoxically felt overly confident about its security. Another recent comparative evaluation reinforced this concern, showing that even more recent LLMs consistently fail to identify common security flaws in code examples, catching issues less than half the time.

But security vulnerabilities aren’t your only concern. AI-generated code can quietly introduce design flaws or subtle logic errors that slip past linters, compilers, and automated tests. The real danger is that these issues blend into your codebase and stay hidden until they cause significant problems later. When you are iterating with AI take frequent breaks every step of the way to pause and asses your solution. Lean on your version control history to review even tiny incremental changes. Vibe coding has a time and place for demos and experiments, but for serious codebases with actual users, discipline matters a lot more.

Slow down for better code

There’s plenty of talk right now about AI-driven 10x productivity. Personally, I find those claims questionable. Numbers closer to 2x sound more believable to me. And frankly, if you’re genuinely producing code ten times faster, it’s probably shallow work, no offense. Speed alone isn’t worth celebrating.

I’m far more interested in how AI can help me improve the quality of my code, not just the lines of code or number of commits I make. How can I use AI to create superior designs, identify the more subtle bugs, or, even better, eliminate unnecessary code altogether? Instead of rushing to push out AI-generated code, slow down. Use AI to explore alternatives and thoughtfully question your assumptions. Ask the AI why it made specific suggestions. Have it critique your design, suggest simplifications, or propose edge cases you haven’t yet considered. Be skeptical still yet.

Maintaining your practical coding skills

Even if you rely on AI every day, your traditional coding skills still need regular practice. In a blog post, Namanyay Goel writes about an uncomfortable truth:

Every time we let AI solve a problem we could’ve solved ourselves, we’re trading long-term understanding for short-term productivity. We’re optimizing for today’s commit at the cost of tomorrow’s ability.

To fight this, Goel and others advocate for “No-AI days.” In other words, pick one day per week and code entirely without AI. Stepping away from AI pushes you to genuinely engage with your code again, confront errors directly, rebuild your debugging intuition, and reclaim the satisfaction of truly understanding a problem.

I admire the discipline and routine of a weekly ritual, and it resonates with you, it’s a great way to keep your skills sharp. For me, a more flexible approach feels natural. Using AI freely for routine tasks, and intentionally stepping away when facing legitimately novel problems.

For those deeper problems, you’ll naturally hit a point where AI stops being helpful. The solution becomes too specialized, and AI-generated suggestions become a waste of time and tokens. In these cases, you’re forced to go manual anyway.

Still, this doesn’t fully solve our problem: how can we intentionally keep our coding skills sharp? I’m talking about deliberate practice.

Another popular method is tackling daily Leetcode problems, perhaps without your editor’s code completion or even on a whiteboard. While likely effective as well, I’ve personally found Leetcode a bit dull. Advent of Code challenges might be a more enjoyable alternative if you’re looking for that size of puzzle.

My favorite approach, though, is the “Build Your Own X” method. Check out the Build Your Own X repo or John Crickett’s Coding Challenges. Rewrite a common Unix utility in the language of your choice, or build your own minimalist web server or data store, or create a tiny text editor from scratch. Pick something that excites you and keep it fun.