One of the most transformative moments for me as a developer was coming across immutable data structures in Clojure and learning that you can reshape problems in a way that helps you make significantly less mistakes as an engineer.

In most programming languages data structures are mutable just like they are in computer hardware. This gives you the most flexibility but it also means that it’s really complicated to reason about changes.

When data structures become immutable, it's more difficult to build things but once you do they are more likely to be correct since changes are minimized.

Datomic turned this idea into a database that stores facts/events and then computes over them. Nothing ever gets removed since it doesn't need to. When you add something, you create an add event and when you remove something you add a remove event. Your interpretation of the data may be a mutable data structure but the underlying data is immutable (which is comforting since it prevents the worst kind of mistakes – the irreversible ones).

Since LLMs can reason about facts in more complex ways, a generalization of this type of database is now possible.

I've been building simple versions of this in my AI repositories. For example I may produce a piece of research, store it in a markdown file and then ask future queries to update the research. I then create analyses files that are updated in line with the research content.

At some point you need a real database. It could be to create memories/context for users, to access the data from different surfaces or just to query it more efficiently.

So I started looking for a more scalable solution and found Graphiti. This is exactly the space they seem to be exploring in.

It’s a database that will use inference to not just store raw data but what you can learn from it.

Imagine you read a 300-page book and you submit each page as an “episode” to the database. From there you could ask questions about the book using queries and Zep/Graphiti will prepare a context block that only features the most relevant pages to answer the question.

But that’s not all. At the point in time where you submitted the pages to the database, Zep/Graphiti started synthesizing higher order forms of context. It reasons about entities, stores facts, makes observations, all based on the facts you provide.

In a regular database, all you get would be a 300-entry table and to find answers you would likely have to loop through every single page and use each of the pages in a prompt and then synthesize.

With Zep/Graphiti, it may already have the answer you are looking for stored in the database itself which would give you an incredibly low-latency response.

While motivated by the common case of user memory and context, I think this has many applications beyond that. Different LLM apps will want to maintain their own interpretation of the world and that could include views on entities different from its users.

The best thing about temporal context graphs is just how much room there is to architect them in different ways since you need to use inference at the point of ingestion.

I'm excited to try Zep out soon and I believe they are one of the most overlooked pieces of infrastructure for AI applications right now (and not just for teams that want user-specific memory).

Once a new interface for interacting with AI shows up, AI labs are pretty quick to expose it to their users. First everything was chat, then the leap to Claude Code/Codex, then to Claude Cowork/Codex Desktop. Later OpenClaw inspired Claude Dispatch and most recently Anthropic has recognized the value of accessing agents in Slack and released Claude Tag.

It works exactly as you expect, you tag @Claude in Slack, it completes work and comes back with the output. It’s going to be easier to set up than the open source alternatives, you’re going to trust it more and the timing couldn't be more perfect with a (somewhat impaired) version of Fable coming back.

I've read all the docs released so far and wanted to highlight a couple of things that seem interesting:

YOU NEED AT LEAST 5 PEOPLE TO USE CLAUDE TAG

Since Claude Tag is only available to Teams and Enterprise customers, you need to have at least 5 seats in your Claude org to use it. It’s not expensive though as the standard annual seats are $20 per month so $100 all in per month.

I think even single person orgs could benefit from Tag so unfortunately this is a somewhat accidental barrier due to the threshold for Teams plans requiring 5 people.

CLAUDE TAG CAN BE USED FOR PMO (MY FAVORITE FEATURE)

I was recently intrigued to learn about Axiamatic. They have used AI to replace the PMO function which is a big deal. Business transformation programs are very important and usually require a strong project management skillset: attention to detail, repetition, stakeholder management, etc.

Not all of the human aspects of project management can be replaced with AI software but at least you can passive aggressively tag Claude to remind that one person of their outstanding action items:

I wouldn't be surprised if being able to “install” project management excellence ends up being one of the most overlooked features.

YOU’RE GIVING CLAUDE A LOT OF CONTEXT

This is a double-edged sword of course. Claude will work better when it has access to as many Slack channels and threads as possible but the speed with which content multiplies in Slack is significantly larger than even a single user can create.

I still haven't enabled “memory” for any of my AI use and prefer to have explicit context in individual repositories but maybe this is the credit card moment of early e-commerce. We used to be afraid of putting the credit card number in. Now we don't even think about it (PayPal, Apple Pay, etc. make it safer too).

@CLAUDE HAS ITS OWN IDENTITY

As pointed out in the official docs, Tag pioneers a new agent identity model that effectively boils down to letting Claude be its own user in various apps that it accesses rather than being tied to a specific user. This is somewhat inevitable but still worth highlighting as it gives Claude more autonomy at the level of an organization.

However, there is an important exception to this: if you DM Claude, it will act as you so you can't ask it to secretly do something harmful without taking ownership.

TAG IS MULTIPLAYER

It’s cool but I could also see this getting somewhat annoying. Another colleague can interrupt my prompt mid workflow:

Each Slack thread basically becomes a multiplayer “chat tab” form the perspective of interacting with Claude.

You can also share tools, currently this requires the use of MCP to add new “connections”. This is more heavyweight than using Claude locally with console interfaces but the limitation makes sense given these Slack threads need to operate in a sandbox environment and access other tools via HTTP.

You can also set up a skills repository to share custom skills across users.

Overall, the implementation seems simple enough to see adoption with the right amount of flexibility. Normally, large companies would be slow to adopt tools like this, but there are 2 recent exceptions.

During the pandemic, Slack & Zoom became defaults for companies of all sizes at an unreasonable rate (Zoom fell off afterwards once security concerns were revealed). So there really isn't a better trojan horse than Slack for Claude to see the same rate of adoption.

We will look back at this as a pivotal moment in AI adoption. I expect OpenAI to launch their Slack agent soon and I can't wait to see Codex/Claude arguing and collaborating with each other side by side in every org.

This week has been pure action. From a barrage of client work and admin and recording a podcast to the Magic Old School Nationals over the weekend and coping with the heatwave as best as we could. Bryan Johnson would not be proud of the amount of sleep I got this week.

So this will be a short one covering a recurring theme that's been coming up in client conversations: the fear that their engineering teams are leaving a lot on the table.

Maybe they don't see themselves using Claude/Codex enough or expected a bigger uplift in their ability to meet deadlines and ship net new code. There's enough people that seem to be 10x’ing their output and the promised land is far too appealing to stay comfortable.

As I started thinking about ways that engineers fail to benefit from AI, it all seemed to come back to bad engineering practices.

If you were a great engineer, bad process didn't necessarily limit your output in the past. But now it could be preventing you from getting meaningful leverage from AI (the infinite team member that is not a “great engineer”). (This is exactly why some of the best engineers remain the most outspoken about not using or benefiting from AI).

The practices that hurt the most:

+ Being inconsistent

The thing that struck me working at Google was that there were so many standards – it was hard to distinguish code written by one person from another. It was just “Google code”. You want this to be true with LLMs.

+ Not writing down specs

Reviewing code is much harder than reviewing a spec. If code output is increased significantly because of LLMs, this makes reviews much more leaky as people will naturally rush through them. Even if you don't formally review specs, forcing people to share their specs/prompts/plans and checking those into the repo enables compounding.

+ Not having continuous delivery set up

If you don't believe in CI/CD, if you don't optimize the latency from idea to production, you simply won't be able to run agentic loops or long horizon work.

+ Not prioritizing well

Suffice to say if you weren't picking the right things to work on you probably weren't making that much progress. Speeding up a car going in the wrong direction doesn't get you there much faster.

Good prioritization is directly linked to either an engineer being able to wear the PM hat well or having full trust in product management (the latter is so easy on paper but you would be surprised how often engineers see PMs/sales/business as the enemy).

+ Not burning to a deadline

If you are not working towards a clear deadline, the work will always be 85% done: with or without AI. Sure, you will add more (unnecessary scope) but you won't help the business hit the milestones that matter.

There it is. Five reasons you may not be getting the most out of your LLM use. These are opinionated but I've seen enough evidence to compel me to stick with them for most problems.

I recently talked to a PE-backed company where the engineers use Claude Code but support tickets take multiple days to be answered.

At first glance, these are two unrelated concepts but I realized customer support is a lot like coding (even easier in many ways).

The customer has a job they are trying to do and a problem that is preventing them from doing that job.

The role of customer support is to investigate, make a plan for how the customer should best solve the problem, implement any required changes on the product side and then help the customer execute the plan.

Sometimes, the plan can be quite complex, for example, when a customer is building an integration to your software.

Other times, the customer is simply doing the wrong thing and all you need is education.

If customer support is a lot like coding, why not use Claude Code?

My idea is simple, lets equip the customer support agent with Claude Code. Claude will draft the support responses and the agent will be responsible for communicating the final response to the customer. Learnings will be captured in markdown files to benefit future sessions.

Welcome to customer-support

I did exactly this and created a plugin called customer-support to test the concept. It has 4 skills:

• cs-initialize

• cs-answer

• cs-interactive

• cs-resolve

To use it, you start by creating an empty support repository and running cs-initialize, it’ll ask you various questions such as the intended tone & voice of your support answers.

For this example, we’ll create a support agent and test it with random StackOverflow questions so efficient & direct will work best.

It’s pretty considerate of your support requirements, see faux pas:

After some questioning it creates a SUPPORT.md file with your support configuration:

Now for the fun part. Lets find a complex question on StackOverflow and see what we can do.

I know nothing about Webkit so this is perfect:

How long would it take you to answer this?

Claude also knows nothing about WebKit but it knows how to read docs so I think it can get there pretty quickly.

I type cs-answer and share the StackOverflow question (I could also use cs-interactive but I think Claude has enough context here).

From there, the support agent writes a response.

Now when I run cs-resolve, it persists the answer into a (markdown) ticket that can be referenced in further sessions.

The ticket starts with a detailed searchable front matter:

It is followed by the original prompt and answer as well as some learnings for future support sessions:

Related answer sessions in the future would have access to this ticket and could now use it to speed up resolution.

What universality means

Note that I didn't need to create a “WebKit” agent.

The customer support agent is only personalized in how it answers questions but the knowledge is universal.

In principle you don't need anything else, a repo with the cs- skills installed could run as a very basic ticketing system.

What if I have existing tickets?

The agent maintains a tickets/folder with resolutions. You could import existing tickets and resolutions into the tickets folder by translating them into markdown files to be picked up in future runs.

Alternatively you can provide a skill/tool for querying an existing ticket database.

What if I have custom software?

If your customers are using custom software that requires additional access for debugging, you could create a read-only API, wrap it into a CLI and provide the customer support agent with access.

How do I inject custom knowledge?

Whether you have existing playbooks or documentation, you could just add them as Claude skills. Claude will pick up relevant skills and inject them in context anyways so there’s no need to import/integrate that directly into the support agent.

Of course there’s lots to improve here but for a project that I one shot on a Saturday afternoon it’s an immediately useful blueprint.

What if I want this agent to upsell/get feedback/etc.

All the skills are easy to customize or you could put a CLAUDE.md file in the support repo root as well. This isn't a fixed solution.

Fully automated support is a trap

So why don't people do this more often?

I think AI for support has been sold as an all-or-nothing implementation. Either trust AI fully and use AI chatbots as an interface to your customers or stay away from it. Either camp is pretty vocal about their approach being superior.

In reality, it’s exactly this kind of hybrid setup that can deliver the best quality and speed.

It can leverage AI and still preserve the type of feedback/sales opportunities that arise from great customer service and direct customer relationships.

I saw Hitler and Anthropic in the same sentence last week 🤔.

Luckily, the other reactions to Anthropic releasing Fable have been more positive.

The model is doing some impressive things.

It’s nice to see a model that lives up to its reputation but this thing needs an instruction manual.

As someone who is making the switch, I have three questions in mind:

1/ Should I use Fable?

2/ How should I use Fable?

3/ How should I rework existing projects?

Should I use Fable?

Based on the outputs I’m seeing, the no. 1 concern is just cost:

The second less common one is Anthropic’s nerfing controls:

It’s probably not right to use Fable for everything but it's worth spending time to figure out where it could either lift the quality bar or produce a better performance/cost ratio.

How to use Fable

Fable comes in many varieties and you shouldn’t assume you need to use the highest tier model. In fact, Fable “low” benched pretty well:

You could even use it just for planning:

Or as a replacement for human-in-the-loop:

If you get whiplash switching between Codex and Code maybe a decent middle ground is to use the low model for coding and high/extra for complex planning/debugging.

As far as how to use it, Claude did a video about this in an engineering context, it effectively makes three points:

+ Treat Claude like a thought partner

“Feel the AGI” has become a bit of a marketing meme dating back to the GPT-5 launch.

Personally, I'm seeing pretty impressive progress using Fable for planning. It confidently out-experts me in areas where I'm not an expert and it’s incredibly sensitive to my context and goals.

For example, I asked Fable to point out gaps in a design system. Beyond visual issues, it strategized about how the design system wasn't translated in a reusable Tailwind configuration and pragmatically prioritized tasks like a PM to move my project forward.

+ Give Claude goals and ways to verify them

Engineers understand the idea of test suites pretty well and this is why LLM coding took off before other use cases. What’s new seems to be Fable’s ability to consider and pursue much more qualitative goals with equal precision and determination. I expect we will see a leap in our understanding of setting up harnessing and feedback loops for more complicated problems such as research.

For example, if you are doing research to power a spreadsheet, it may now be a good idea to ask Fable to build that model as well and describe the properties of the final deliverable you care about (sensitive assumptions are well-backed, etc.).

+ Be more ambitious

Further to the above, while early experiments seem to be focused on highlighting Fable’s ability to solve more complex engineering challenges such as 3d rendering or complex bugs, I'm excited to explore how Fable can be applied in research and media manipulation too.

My early experiments with images and video have revealed that almost all of the world class models require tremendous patience and skill in execution (especially video).

How (and whether to) to upgrade existing projects

This is the most interesting question for me. Imagine you've built something with prior model generations. At which point should you consider refactoring and how do you do this?

Typically refactoring something just because a new & smarter engineer arrives is not a good idea. Also, provided your code is protected by tests & standards, the improvements from a better model may not even be that big. I don't expect back-end projects to refactor aggressively.

However, if you've been doing game design using prior models, you may want to see what Fable can do for you. There may be other areas where it's made a breakthrough.

As to how to navigate this, I'd still anchor around improvements, e.g., if your game needs a more impressive map view because the number one complaint from players is map accessibility, point Fable at that.

Personally, I've asked Fable to do a design review of some projects and suggest potential improvements to add to the “chore” backlog. I'd love to see other ways of leveraging this model on prior work.

Thariq from the Claude team broke X with The Unreasonable Effectiveness of HTML where he explained why HTML > Markdown for agents:

HTML can convey much richer information compared to Markdown. It can, of course, do simple document structure like headers and formatting, but it can also represent all sorts of other information such as:

• Tabular data using tables

• Design data with CSS

• Illustrations with SVG

• Code snippets with script tags

• Interactions using HTML elements with javascript + CSS

• Workflows using SVG and HTML

• Spatial data using absolute positions and canvases

• Images using image tags

In my opinion, there is almost no set of information that Claude can read that you cannot efficiently represent with HTML. This makes it a highly efficient way for the model to communicate in-depth information to you and for you to review it.

this came on the heels of announcing Claude Design which defaults to HTML as the format for presentations:

Claude Design is based on HTML because HTML is incredibly expressive at design, even if your end surface is not HTML. Claude can sketch out a design in HTML and then write it in your language of choice, be it React, Swift, etc.

While we’ve made a step change in communication bandwidth between humans and agents, there’s also a threat to existing stores of record for presentations, other design assets and maybe even SaaS?

Yes, it’s better

Reviewing markdown files is definitely boring and while Notion is pushing to be the default “markdown rendering engine” of the internet, it's infinitely less flexible than HTML.

I've been working on a design system with Claude Code this week and all communication happens through an HTML file it served from a python server (no I didn't make that particular choice).

It’s both the output and also the interface where it shares options and ideas, even allowing for interactivity when needed. The models are just about good enough now that the documents generated are not unpleasant and I could see applying this in many more domains (research being an obvious one).

But why not even present a legal finding to me in the style of Harvard Law Review?

The future of PPT

Nevertheless, the strategic implications are even more interesting. For a while, Canva was making a strong play at being the next PowerPoint but I think it may get squeezed in the middle.

There will come a point where we won't even care what the file format is. Right now, HTML (via Claude Design) is much more versatile for agentic development while PPT (with Claude for PowerPoint) is still the institutional default.

Ironically, while HTML is an open format and Claude Design allows you to export your creations for maximum portability, it will likely be perceived as a high switching cost option because all the functionality like design systems, templates, your Claude context has an impact on your future token spend and is actually a bigger switching cost than the file format.

So while startups and more ambitious sales teams will likely jump on Claude Design, institutional adoption will be slower. Microsoft’s goal will be to use that time until they figure out how to improve the PPT format or create a new more interactive standard.

From an AI transformation perspective, this seems like a really bizarre time. Workflows are changing too fast to be meaningfully dissolved into companies and I think it’s worth to loosen up adoption policies to allow certain teams to move faster.

My recommendation for teams would be to:

+ Distinguish between iteration media and output media. Just because your final output has to be PPT doesn't mean you cannot prototype in HTML. The same distinction between prototyping and production that has been working in code will start applying to other contexts.

+ Focus on outcomes, not outputs. I've observed more creative uses of AI in sales processes. Sometimes the best output isn't even a presentation, it can be a demo user interface or a dashboard or an interactive experience.

If anything, the fact that we are even discussing HTML (a format that humans can more easily visualize and interpret) suggests that robots aren't running away with our jobs just yet.

We generally try to cover every new interesting protocol release but there just haven't been that many recently.

Morpho Midnight changes that. It's a fixed rate lending primitive with a built-in order book. It's particularly timely since the primitive will likely fit well with requirements of RWA issuers and institutional lenders as well as provide a much needed new source of onchain yield.

So if you haven't had the chance to read the whitepaper and codebase, I compiled some things that are worthy to note.

1. It supports under-collateralized borrowing

While this is not something that Morpho publicly advertised, note that position health is simply a function of oracle price:

Which means that market creators can use oracles that intentionally over-price positions AND liquidations are gated:

2. Debt and credit are fungible

An interesting feature is that these agreements are entirely fungible and transferable (provided solvency is preserved).

This is also facilitated by the fact that debt acts as a zero-coupon obligation meaning you repay the whole obligation at the end rather than in interest increments.

3. Midnight achieves higher capital efficiency through JIT capital provisioning

Offers implement callbacks which is convenient for maximizing capital utilization for lenders:

Similarly, capital efficiency is also preserved at the protocol level meaning that the total outstanding order size can outstrip available capital and operate on a first-come-first-served basis:

Requiring order matching impacts liquidity so these are important mitigations to ensure maximum possible liquidity for market participants.

4. Routing will be complex!

Just like for Uniswap v4, the protocol outsources several key functions to routers.

Optimal routing won't be easy at all, routers will have to:

• Prioritize offers;

• Respect and model the implications of callbacks and multi-market offers;

• Understand implications of different oracles;

• Recognize opportunities for netting;

• etc.

In Uniswap v4, routers ended up being conservative with whitelisting pools and I suspect the same will apply to Midnight at least initially.

5. New protocols can be built on top of Midnight

Most importantly, while the protocol relies heavily on off chain matching, the primitives are simple enough that onchain wrappers could be developed as well.

For example, third parties could build:

• Custom markets for their assets (particularly relevant for RWA issuers who may be opinionated on oracle usage and gating access analogous to custom hooks in Uniswap v4;

• Routing (see above);

• Multi-step borrowing/lending strategies (e.g., rolling debt);

• Automated supply from third-party protocols (e.g., vaults).

I'm excited to see what this enables. As is custom with the Morpho team, the primary contract has been code golfed heavily to just <1000 lines of code (including comments!) – a lovely poke at the AAVE team which is notorious for heavy complexity due to the sheer number of modules in their contracts.

But it also means it’s fairly simple to read and digest so I recommend you to dig in with your favorite AI. Here's a prompt to get started:

The Morpho team just released Morpho Midnight, a new fixed rate lending primitive, I want you to deeply digest the Whitepaper and GitHub repository and prepare to answer my questions.

Whitepaper: https://morpho.org/whitepapers/midnight-whitepaper.pdf

GitHub: https://github.com/morpho-org/midnight/tree/main

If you were a long time believer in Ethereum (like myself), this week has stung.

The primary pro-Ethereum media company Bankless is making a narrative pivot.

Meanwhile the Ethereum Foundation has been losing some momentum as it experiences tremendous employee churn.

Perhaps capital matters more than vision.

For a while it seemed that people really united around Ethereum’s cyperphunk ideals. Teams built their protocols under open source licenses, crypto developers enjoyed location and lifestyle freedom. Security researchers offered their services without any expectation of compensation.

But there were several healthy capital flows behind these movements:

+ Venture capital Firms saw crypto as the dominant narrative post-Covid and eagerly funded both infrastructure and applications. The token model ensured early returns and compounding without the need to deliver value to a specific customer persona. Well-funded portfolio companies threw conferences and parties and sustained various service providers (audit companies, agencies, individual contributors, etc.).

+ DAOs light on team but heavy on capital turned to grant programs to keep developing their roadmaps in a compliant but often inefficient way. These grant programs also sustained a cohort of “independent developers” and companies that started specializing in DAO politics and services.

+ Speculative capital was attracted by the promise of liquid tradable onchain assets and various instruments on top of them, creating tangible net inflows and revenues for both VC funded companies and DAOs, fueling the feedback loop.

Ethereum wasn't necessarily playing the role of “product” in this economy as it just became a facilitation layer.

The hope was always that the alternative economy of VC-funded firms, protocols and DAOs would grew bigger than the existing financial industry or move too fast for it to catch up.

Unfortunately, it didn't. Fintech companies like Stripe and Ramp execute faster than even the most productive crypto companies and are likely to capture much of the surplus of this cycle.

The Ethereum ecosystem is now in a state of narrative paralysis. Uncertain what it wants to do: continue creating public goods for companies like Stripe to monetize or continue advocating for an alternative without the execution apparatus to make it real? Or actually have a strategy for once.

At this point the potential of AI is obvious but how do you encourage a whole organization to adopt it?

It’s been difficult.

Power users are not the answer. You may be lucky and have a few already. They spent nights tinkering, built custom workflows, and now they’re unreasonably efficient at coding, research or whatever else they cared to automate. But they’re not necessarily going to teach everyone else.

You can shove AI into your product, but larger organizations are notoriously bad at innovating and there are complex product strategy challenges with rolling out AI products that I've written about before.

Even internal transformation projects are challenging to implement because the people who understand workflows aren’t AI-fluent.

Luckily, there’s one really practical way to accelerate AI adoption.

Install an Internal Slack Agent

Force all interactions with the Slack agent to happen in public channels. That’s it.

The first time I heard about this was from Georgios.

Patrick Collison even said he didn’t know how to apply it at Stripe.

Then Tobi Lutke published Learning on the Shop Floor, an article connecting apprenticeship culture to Shopify’s internal agent, River. River is an agent you tag in Slack to complete work, but you can interact with it in any public channel but ONLY in public channels.

So why does this work?

It’s all about the CONTEXT

1/ Less setup for everyone

The immediate benefit is that you’re pooling the effort to interact with external systems and data. Not everyone has an Openclaw instance or knows how to use GitHub agentically. By routing it all through one company agent, people don’t have to learn each tool independently. They just talk to the agent, and it handles everything for them.

2/ Apprenticeship

But the deeper benefit is what Tobi calls apprenticeship. People in different departments don’t just know different AI tools, have identified best practices in using the tools. When an engineer creates a pull request through the Slack agent, someone in marketing might see it and figure out how to patch up website copy.

A public Slack agent makes AI use visible, demonstrates what’s possible through real work, and creates social pressure to participate. Every interaction someone has with the agent is a live tutorial for everyone else.

3/ Context farming

The third benefit is context farming. By making it easier to do work with the agent than without, you’re forcing employees to build, in real time, the company’s playbook. All work is documented. This can be used to formalize SoPs, identify bottlenecks, monitor which workflows produce better outcomes and make recommendations.

Tobi explained how River learns from prior interactions:

You can use this today

Entrepreneurs are jumping to offer this as a service. Remi is "an internal agent that learns from your team's processes. Stilla is literally positioning itself as Shopify’s River for everyone. There are probably more, but these are the ones I’ve naturally come across.

I expect this to be a hot market and another surface Claude and Codex will likely offer in the next 6 months.

One thing missing from today’s implementations is proactivity. Georgios talked about how they’ve struggled to build proactivity in their agents. Proactive agents wouldn't just respond to prompts, they would notice a bug on your website and propose a fix or notice a vendor offering a cheaper plan and downgrade, etc.

Possibilities aside, if you’re looking for a single, high-leverage step to accelerate AI adoption across your organization, this is the one I’d make today.

It used to baffle me how proud McKinsey Partners and Senior Partners were about how little they knew about technology. Knowing “the details” was seen as a sign that you are not senior enough so that other people can handle the details for you. The Partners and Senior Partners would instead focus on the big picture.

Well there is no big picture anymore.

OpenAI and Anthropic are entering the AI transformation space with two new heavily funded entities and it will shake things up.

In this essay I want to walk through:

• How engineering has become a bottleneck for the AI rollout and why horizontal AI players are launching consultancies;

• How will OpenAI/Anthropic solve this problem (it’s not what you think);

• Why the Big Three should be very worried.

Engineering is still the Bottleneck

Both companies have spent the last year aggressively expanding enterprise tooling. Anthropic has Claude in desktop apps, vertical offerings, and a growing partner network. OpenAI launched Frontier in February and immediately signed Frontier Alliances with McKinsey, Accenture and others.

Yet adoption remains painfully slow.

It’s impossible to build “off the shelf” solutions for many enterprise problems.

For a stretch of my McKinsey tenure I was building the Firm's predictive maintenance “solution” (essentially using AI to predict when machinery would break).

This was not the same as building a SaaS tool. At times it meant flying to wind farms to physically extract sensor data from turbines because the infrastructure wasn’t connected to the cloud. The data was messy and sometimes data scientists had to create models just to clean it. Every client’s setup and data taxonomy was very different. Not to mention all machines had different characteristics.

So you have to do it bespoke.

But there are very few AI-native engineers and they don't emerge in these big companies nor in traditional consultancies where each engineer has many other things to do: creating presentations, talking to clients, reviewing work endlessly.

The Solution: Build Next-Gen Consultancies

The cloud providers (AWS, Azure) faced a similar problem a decade ago. When I was doing AI transformation work at McKinsey, we’d often partner with them because clients were bottlenecked on moving data to the cloud, figuring out the architecture, and identifying use cases. The cloud companies wanted to accelerate adoption because adoption meant compute spend.

Every workflow OpenAI and Anthropic automate inside a PE portfolio company will consume tokens indefinitely. So why not build the workflows themselves?

The only problem is that building a consultancy from the ground up and growing it fast is tricky. So they will be doing things a little differently than traditional consultancies.

Demand side: Partnering with Private Equity

PE firms are structured to transform the companies they own (that’s the business model). When I worked with PE portfolio companies at McKinsey, they were the most aggressive implementers. There was no internal resistance. Having access to a couple of the largest Private Equity companies in the world will provide a proactive client base on day 1.

Supply side: Scale through consolidation

Consultancies are very hard to scale since they require people to deliver the services (technology services or not) and it takes time to train them. Rumors are that these companies will seek to acquire and consolidate smaller service providers and that makes sense. I assume there will be a lot of poaching from Big Three as well (especially for the generalist consultants overseeing the transformations and maintaining relationships).

The Work is the Same

Aside from the hyper-scaling, however, I don't think these organizations will be as radically different from traditional consultancies as what people expect.

People describe this as if OpenAI’s research engineers are going to be personally deploying agents at mid-market insurance companies.

For a Big Three transformation, a typical engagement will look like this: 2-3 year transformation plan, prioritized use cases, small teams building proof of concepts, gradual rollout across the organization, and a training phase where internal teams learn to do it themselves.

The first few use cases get built with heavy external involvement. By the fourth or fifth, the client’s own team runs the project with oversight.

The other misconception is comparing this to Palantir. Yes, engineers will be forward deployed into client organizations, no doubt. But Palantir also built Vertical AI platforms. Anthropic and OpenAI don't really need to worry about this as their product monetizes at a lower level. I'm sure over time they will spin out additional vertical solutions that could be scalable but it will be hard to do so at first.

Another misconception I saw is comparing this to Sequoia’s Julien Bek’s essay on how automated consultancies will charge by objective.

In a previous piece, I laid out four layers in how AI reshapes knowledge work verticals: horizontal AI (the model companies), vertical AI platforms (tools like Harvey or Hebbia), neofirms (AI-leveraged consultancies like Crosby), and classical consultancies.

What OpenAI and Anthropic are doing is different from the neo firms AND vertical AI platforms that Sequoia’s thesis describes. The Deployment Company and Anthropic’s unnamed venture are will rather operate as Classic Consultancies focused on transformation.

Traditional Consultancies Should be Worried

First, AI transformation is rapidly becoming the only transformation that matters. Whether it’s a 5-year strategy problem or a pricing optimization project, it would revolve around AI.

Second, where are OpenAI and Anthropic going to find people who can run enterprise transformation engagements? A lot of consultants are going to find the OpenAI/Anthropic brands irresistible and move to build something new.

Third, the Senior Partner base at these firms has historically treated their generalist approach as an asset. The implicit belief is that deep understanding of business strategy transcends any specific technology. That worked when the most sophisticated piece of technology projects required was a spreadsheet.

It’s a liability when the technology is agents.

But it’s not going to be easy for OpenAI/Anthropic either.

Scaling a Consultancy is Hard

I'm going to repeat myself but multi-billion dollar valuations on day one are wild for companies that haven’t billed a single hour of consulting work.

You can’t 10x a consulting firm’s revenue by shipping code like you can in a SaaS company. Revenue is a function of how many skilled people you can deploy, how quickly you can train them, and how effectively you maintain client relationships across a growing portfolio. McKinsey has spent a century building decentralised project management, unified quality standards, and a culture of consistency.

The chaos of rapid acquisition and consolidation, which both entities will almost certainly pursue, adds another layer. Every acquihire brings different working styles, quality bars, and different client expectations.

Seeing them try to scale this fast will be exciting to watch, I'm sure won't be my last essay on the topic.

When Steve Jobs asked Paul Rand to design the identity for NeXT, Paul Rand did it with effectively zero input from the team.

He “one-shotted” the identity.

Your favorite AI model is not Paul Rand!

Proceed without taste and you’ll fall below the bar of what people expect.

This is already happening, many websites already look pretty similar.

It shouldn't surprise you that some of the best AI power users are actually designers.

While you can't replicate their taste, you should learn from their process.

Think like an AGENCY

A couple of years ago I had the privilege of working with a top tier NY design studio. I was surprised how rigorous their process was. They would share outputs at every step, ask for input and iterate.

If you want branding work done, don't ask AI to produce an entire brand for you.

Instead, find agency processes that are proven and break down the work, like this Smith & Diction Brand Identity Process.

A significant part of branding is understanding your company. AI can help with that as well. The creativity comes later.

Why this works:

+ If you follow a process like the above, you’re guaranteed to end up with something unique.

+ You’ll be able to review and enhance the outputs at every step, not just at the end.

+ You’ll provide AI with more context and be able to trace specific decisions better. When it comes to upgrading or evolving your identity, you’ll have a great starting point.

You won't necessarily get agency-level output, but you will get something much better than what a single prompt would get you.

This approach doesn't just work for brand identity of course, you can replicate agency work for marketing, pricing analysis, consulting, etc.

I recently read a tweet by Josh Hunt postulating that the UK as a service economy is significantly more exposed to AI than other countries:

81% of UK GDP is services. 83% of UK employment is services. Law. Finance. Consulting. Admin. Media. Tech. Middle management. These aren't side categories. They are the British economy.

They are also the roles with the highest AI exposure.

Goldman Sachs ranks them at the top: legal, financial analysis, operations, content production. The IMF puts 70% of UK workers in AI-exposed occupations, against around 60% in the US.

It got me thinking, what will all these people do?

Currently they exist in some knowledge work vertical: design studio, recruitment firm, video production, investment banking, etc.

They can't simply “move to AI”. As I've said before, you can't pivot into AI. AI is so ubiquitous that every industry is already transforming.

A yoga studio still needs human yoga instructors. But its marketing, branding, scheduling, student relationship management, and digital products will all be changed.

But it's fair to say that yoga studios will be more resilient compared to tech companies. No risk, no reward, investing in tech means you may be focusing on obsolete workflows but there's bigger rewards if you figure out where the puck will go.

Specifically for knowledge work, however, I do think there is a universal pattern emerging. Every industry is being restructured according to this pattern.

There are 4 layers in each vertical that will matter:

• Horizontal AI (model providers)

• Vertical AI (domain-specific wrapper interfaces)

• Neofirms (AI-powered consultancies)

• Classic Consultancies (transformation firms)

Horizontal AI is the EVER-EXPANDING BLOB

“Why wouldn’t OpenAI or Anthropic just build this?”

Every Founder now has to answer this question.

Previously, whether you built a marketplace or a social network, there was always the question of why Google or Facebook wouldn’t copy it. But it was much easier to find compelling answers back then. Those companies had to make a conscious effort to enter a market. Now, models are inherently general. Their range expends as a function of general intelligence.

At an extreme, if models reach AGI, the final barrier will be compute cost. We’re not there yet. But horizontal AI providers are already a dominant participant in every vertical. And this category isn’t just OpenAI and Anthropic. It includes open source models and future market entrants.

Vertical AI platforms compete on INTERFACE and INTEGRATIONS

Vertical AI platforms are copilot software that works alongside knowledge workers for domain-specific tasks. Engineers use Lovable, lawyers use Harvey and bankers use Hebbia.

They largely rely on the same underlying models but deliver higher value through better interfaces and better agentic workflows. Hebbia‘s Matrix product is a good example.

The platform changes the default output from an AI model from text to a table. Rows are different sources, columns are different questions you ask of those sources. It’s essentially a pivot table for extracting knowledge from AI.

Behind the scenes there’s an improved data extraction pipeline that emulates a bigger context window but a lot of the value is just this interface that’s better suited to how financial professionals actually work. Synthesising information from disparate sources, being rigorous about referencing and ingesting private reports.

The tension is that horizontal platforms are dipping into domain-specific workflows. Anthropic is building tools for Claude to work inside presentations and spreadsheets. OpenAI ships Codex. Both are partnering with enterprises and creating vertical-specific benchmarks. Meanwhile, vertical AI platforms are pushing the other direction: improving the quality and autonomy of their agents, working to make deliverables more viable as finished output. The battleground between these two layers is active and accelerating.

Neofirms are the POWER USERS of AI

Neofirms are consultancies that are highly AI-leveraged.

They combine people with proprietary AI tooling (where the AI does a significant portion of the work) and people review it or collaborate with it. They can deliver better and faster than traditional consultancies.

Crosby coined the term “neofirm” in law. They’re a registered law firm that uses AI agents and in-house lawyers together to review, redline, and negotiate contracts rapidly and at a fraction of the cost of traditional firms.

What makes neofirms interesting as a category is that they sidestep the biggest obstacle vertical AI platforms face which is education.

If you’re building a vertical AI platform, you can have brilliant ideas about how professionals should be using AI in law or finance. But those ideas are only as good as the customers implementing them. A neofirm doesn’t need to educate customers. It can run ahead to the future and use the most advanced AI workflows, focusing entirely on delivering outcomes.

Neofirms also get to be more opinionated about proprietary data they absorb and work on while vertical AI platforms are investing in replicating similar interfaces to horizontal AI companies.

Classic consultancies own the transformation

Classic consultancies are existing large firms focused on holistic transformation. Transformation is not a technology problem. These firms work with leadership and management to implement projects and incorporate partnerships across all three previous layers.

Their revenue base demands bigger partnerships with large companies and that will continue to be the bread and butter. They’ll build internal tooling for technology-enabled leverage and compete with neofirms at the edges. Neofirms in turn, will try to deliver better and faster, push the price point down, and do so with more compounding technology and data moats. Classic consultancies risk relying too much on internal expert networks at the expense of the kind of systematic data advantage that neofirms are building. But their grip on enterprise relationships and change management is durable.

It’s likely that classic consultancies will start acquiring and incorporating neofirms into their delivery model. The two categories need each other more than either would probably admit.

Layers will collide

The interplay between these four layers explains a lot of the dynamics we’re seeing across knowledge work verticals right now.

+ Horizontal AI is not swallowing everything. There’s still a large surface area of different types of work remaining across the other three layers.

+ Neofirms will have an identity crisis. Are they VC-scale technology companies or are they boutique services firms?

+ Services are showing up in unexpected places. Because three of these four layers are effectively productized services, you’ll see companies that traditionally don’t think of themselves as service businesses adding service aspects.

Two-sided marketplaces can offer services on both sides of the market. Jack & Jill is an example: if you’re looking for a job, they give you an AI agent that does coaching and matching. If you’re looking to hire, you talk to an agent that finds candidates and makes introductions. The value floor is a productized service on each side. The ceiling is marketplace dynamics where they accumulate demand and supply and start matching over time.

Using productized service to bootstrap a marketplace is a pattern we’ll see a lot more of.

If you’re part of the service economy, think about where you want to end up. If you want to focus on transformation, classic consultancies are fine. If you enjoy working directly with AI to produce deliverables, a neofirm is probably a better fit. If you’re drawn to the technology itself, maybe you want to build vertical AI.

A little awareness for the end game will help a lot.

Over a decade ago, Peter Thiel delivered his “Competition for Losers” speech at Stanford.

One of his core ideas was that there is a “right size” for a market you want to build your startup in. You want a small market so that you can dominate it and then maintain your monopoly as the market expands.

Too big and you won't be able to achieve a monopoly.

Too small and the market is irrelevant.

He goes on to convincingly establish the thesis but the obvious question becomes – how do you pick the right size?

The 100 Founder Heuristic

Around 2021-2022 I found myself as one of the many technical people in “Ethereum” – a pretty broad and lovely cohort of people.

My intuition was to niche down and focus on one area more deeply, I recognized that crypto was getting too big to be a generalist.

I picked ZK Rollups. In particular, I was one of the first developers on Starknet and got to know some incredible people both in the company and outside.

As a result of that choice:

• I learned about Rollups and ZK, two areas I knew little about;

• Auditless landed several grants working with rollups (Starknet/Unichain);

• I made some angel investments into really talented people who became friends;

• We built products that allowed us to make stronger contributions to Aera. In particular we were one of the early adopters of ERC4626;

• I'm still collaborating with folks in the community to this day.

I think what made Starknet such a great community to participate in was a combination of the talent and the size.

These were some of the smartest people in crypto but there was less than 100 of them building at the time. As a result, everyone was keen to meet everyone and to support everyone else too.

I joined a 6-person meetup in London (which afterwards grew a lot) and helped host one of the first meetups in New York. Things grew quickly from there.

I say this because the mistake people make today is to think that they need to “move to AI”.

You are already in AI whether you like it or not.

What you need to do instead is be one of the first 100 Founders/operators in a smaller market and get to know everyone.

(This by the way is why people move to San Francisco, a lot of those communities physically exist there.)

I think that's roughly the right size that Peter Thiel was talking about.

I’ll leave you with a related thought from Alex Danco from How Scenes Work:

And part of the beauty of this book, this is not infinite games are good and finite games are bad. But the beauty of living life to its fullest is in choosing what finite games you play, that serve the infinite pursuits that you have. It’s picking. What finite game am I going to play in this scene? And does it really aligned with the infinite game I want to play of participating in culture?

Some of you are reading this on a Mac but did you know that the entire category that Macintosh pioneered wasn’t obvious at the time?

This is the exact moment where Jobs (then at NeXT) explains how there is a market for “workstations” targeted at professionals outside of science & engineering and draws neat circles around the markets that Apple focused on for the following 2 decades.

With the introduction of LLMs, it’s not obvious how to apply this type of analysis going forward or whether it's even possible.

In the past, the future was known to a few very smart people, but now I fear the oracle is going dark for all of us.

MARKET BOUNDARIES MATTER

Circles on a whiteboard need to be formalized so let me say that two points are on the opposite ends of a market boundary if the potential customers have different needs. Picking the right threshold for different is more of an art than a science but it’s an art that pays more than doing science.

Finding the right circles to bet on is the way investors, Founders and even early employees create wealth. Peter Thiel puts it simply: find a small circle that is growing fast and jump in.

And prior to 2022, we had some useful heuristics for finding the circles.

THE EVOLUTION OF MARKET BOUNDARIES

Late 20th Century-early 2000s

First, it was all about sectors. In 1999 S&P developed GICS, the Global Industry Classification Standard with categories such as Energy, Materials, Industrials, etc.

As long as you picked the right sector at the right time, growth persisted and market participants became entrenched.

Late 2000s-2022

Something interesting happened in 2008 – the financial crisis combined with the launch of the App Store marked a symbolic transition from sectors to tech, tech and more tech.

In 2011 we understood Why Software is Eating the World. Sector companies raced to adopt while investors looking for outsized growth focused on category prediction.

Mobile. E-commerce. Streaming. Biotech. Space. Sustainable Energy. While most of these were clearly tied to customer problems the more speculative ones weren't: VR/AR, IoT, Crypto and of course AI.

The latter one was the platform shift we'd been looking for all along and in 2022 everything changed.

2022-

Going forward, we have to develop a new understanding of how to identify growth pockets.

For every single category, it is not clear how much value will be captured by people who adopt AI versus “horizontal AI”. The reach of general purpose LLMs has already bled past ChatGPT wrappers into interfaces and horizontal players like Anthropic are going vertical too.

THE MARCH TOWARDS UNCERTAINTY

I see three distinct ways of thinking about the future.

A/ AI is just another technology

AI is adopted like software and the companies with the best customer relationships, domain expertise, brands and packaged vertical solutions continue to win.

In this world, current market boundaries hold and the strategy is to pick a domain and lead on AI adoption in that domain.

This is how it’s historically played out.

B/ Rebundling: the AI value chain

The “From Hierarchy to Intelligence” essay covered in our previous newsletter is a useful model here. Value accrues in two places: your defensible capabilities (data, proprietary processes, unique assets) and your ability to operate AI effectively. The interface, the thing you actually sell to customers, becomes a delivery mechanism rather than the thing that’s valuable.

Google Search is one example. Google’s underlying capability is indexing the web, scoring content, and rapidly serving answers. They monetized this through an advertising-funded interface. But in a world where Google wasn't doing Gemini, they would be forced to become an API and monetize differently.

This is happening across industries. Companies are getting compressed into their data moats and capability moats, and the margin that came from interfaces, human-delivered service models, or being the only option in a vertical, is rapidly shrinking.

C/ Capabilities become reproducible

At what point does AI become good enough to crawl enough data and cut enough deals to reproduce the Bloomberg Terminal from scratch?

There is a world in which the only thing that matters is how efficiently you convert compute into capabilities and products. The horizontal AI companies have an advantage here, they are the power users of the coding agents all the tools that will follow. Not to mention their marginal compute unit is cheaper.

This scenario would completely break our assumptions of how careers, companies, and investments work.

the uncertainty you’re feeling about predicting which markets will matter isn’t a personal failure of analysis. The map is opaque. The terrain is in flux. The neat circles we used to draw around industries and technology waves are not so neat anymore.

There are other factors these scenarios don't capture: battles over distribution, re-orientation around workflows or even the impacts of regulation.

So choose your own adventure:

• If you believe workflows define the boundaries: build products that own end-to-end process outcomes and price this way.

• If you believe orchestration is key, compete on reliability and feedback loops.

• If you believe infrastructure commoditizes the entire value chain, invest/build around energy, compute and memory bottlenecks.

• If you believe regulation will be the most impactful, develop AI for a high-compliance market.

• etc.

In From Hierarchy to Inteligence Jack Dorsey and Roelof Botha explain how Block is adapting their organization to AI:

At Block, we’re questioning the underlying assumption: that organizations have to be hierarchically organized with humans as the coordination mechanism. Instead, we intend to replace what the hierarchy does. Most companies using AI today are giving everyone a copilot, which makes the existing structure work slightly better without changing it. We’re after something different: a company built as an intelligence (or mini-AGI).

The article is a worthwhile read and traces key organizational developments from the Roman Empire to present day.

Here’s my visual summary of the org structure the authors present:

• At the core, there are 4 layers;

• Capabilities, which are bigger than infrastructure but smaller than products;

• A Company world model, the type of context that managers would typically convey around the company’s operations, performance and strategy but entirely consumable by LLMs AND a Customer world model, behavioral customer data also consumable by LLMs;

• Intelligence, which are purpose-built solutions/products from the capabilities

• Interfaces, which are the delivery surfaces and include apps, and hardware

• Humans operate at the edges:

• Individual Contributors contribute to some of the layers as specialists;

• Directly Responsible Individuals take ownership of cross-cutting problems or metrics

• Finally, Player-coaches, both develop people and directly contribute.

WHAT’s NEW

There are a couple things that are implicit and draw my attention here.

The abandonment of “products” as an organizing unit. Jack expects products to form fluidly in response to emergent customer needs, which reflects the speed at which software can be created. However, he recognizes that these products will lean on a deeper capability layer which will require more dedicated investment.

The takeaway here is don't think about your products as what’s valuable, instead, think about the underlying capabilities and making your product development process as fast as possible.

The system is trending towards closed loop. Note that the intelligence layer is able to prioritize what we currently see as “software work” without dedicated product managers and roadmaps. A theme we talk about in Default to Closed Loop.

Everyone works on the system. While it’s obvious that everyone in this organization is a consumer of “the system”, the true difference from status quo is that everyone is also a contributor. Either they are an IC or player-coach directly improving certain parts of the system from an ability lens or they are a Directly Responsible Individual who is optimizing how a system is achieving a specific goal. Humans at the edges are also continuing to adjust the world models in line with reality by injecting feedback and data.

All this reminds me of something very familiar.

Jack reinvented management consulting?

Jack focuses on no management as an innovation but that is already how management consulting firms like McKinsey are structured:

• Each consultant had a personal development lead (coach?) focused on assessment;

• Project leads are assigned on a transient basis to lead 2-3 month projects (which is similar to how Jack frames DRI tenure). Both internal and external projects are essentially structured the same way;

• The Firm has a broad set of indexed knowledge documents and each consultant in the system is tagged for the expertise they have.

It's amazing how close McKinsey’s operating model is to this one which makes me even more convinced it will work.

Of course, the big improvement here is the ability to centralize context and add an intelligent delivery mechanism (as opposed to a purely consultant led delivery mechanism) and that is very exciting.

As an Associate at McKinsey, I was always annoyed at how Partners reviewed presentations. They didn't touch PowerPoint. Instead they always asked us to print the whole presentation out after each iteration, grabbed a red pen and marked up the pages by hand.

We burned through a lot of paper, printing deck after deck, just so a Partner didn't have to open a laptop.

Then they’d hand a stack of red-inked pages to the Engagement Manager who would divide and conquer the fixes across the team. Each of us got a smaller stack to create slides from.

At the time, it seemed unnecessary even frustrating because deciphering the red ink often meant losing sleep.

Why wouldn't they edit the PowerPoint directly or just add callouts?

But they understood something I didn’t: review is a fundamentally different cognitive mode than editing, and the environment you review in determines the quality of what you catch. The point was to sit with the deliverable in its final form and see it exactly the way a client would.

Soon, I was doing the same thing even for my own rounds of edits.

I’ve been doing this ever since. And right now, the approach matters more than it ever has.

We may be in a PEAK review period

A disproportionate share of knowledge work has shifted to review.

Even if you were a manager before, you likely reviewed things on a slow cadence, maybe weekly, and you still had entire blocks of work you owned end to end. With AI, you’re potentially reviewing something every five minutes. If you’re coding, it's every minute or less.

Reviewing other people’s work is getting worse too. You’re now reviewing not just what your colleagues did but likely some of their AI outputs too. And because everyone is “more productive” you have even more review work piling up.

Unfortunately we are not yet at the point where we can define objectives and hand them to autonomous systems.

But we’re also not in the old world where a manager reviews a handful of deliverables per week and spends the rest of the time on their own work.

We’re in an awkward middle ground: too many things to review, with neither the tools nor systems to handle it well.

Reviews are problematic

If not managed, review volume creates other issues.

High-frequency AI use destroys flow. While this cycle may improve speed on any individual task, flow is essential for quality and for the kind of deep thinking that catches subtle bugs or sees structural problems.

Less productive time. The more you review, the less time you have to do things. So you lean on AI more to fill the gap, which generates more output to review, which eats more of your day. It’s a slippery slope and we get less meaningful blocks to think.

The tools haven’t caught up. GitHub is designed for human-to-human code review, not for interacting with a coding agent. Most editing workflows assume a human author on the other side. When you have multiple humans and multiple agents working on the same thing, ownership gets murky. Who runs the final review? Who’s accountable?

A few things are working for me

I've been reviewing deliverables since 2014 and have been able to adapt some techniques to this context.

1/ Human review means human review

The most effective pattern to deal with reviews goes back to the McKinsey story and is deliberate disconnection. When I’m reviewing my research paper, I send the PDF to my iPad, open it, and edit with the Pencil (in red). When I go back to my desk, I look at the edits and decide which ones I’ll fix myself and which ones I’ll get AI to help on. But the review itself is entirely unplugged.

The same is true for our recent code audit. I spent significant time reading code line by line on the iPad with the GitHub app. This is still one of the most powerful review methods available, and I suspect it always will be.

To get the most out of your reviews, get as far away from the toolchain as practical.

2/ Use AI for context loading

Disconnecting for review doesn’t mean disconnecting from AI entirely. The trick is sequencing. Before I sit down for deep review, I use AI to prepare.

When it comes to doing work, AI requires context from us. But when it comes to human review, AI can actually provide us with more context.

For the code audit, I had AI generate a comprehensive threat model and alternative views of the codebase, diagrams and trust boundaries. I read through all of that first. Even when I didn’t find issues in the threat model itself, it prepared my brain. It loaded context that made the subsequent manual review sharper. Similarly, for the research paper, I used AI to surface relevant prior work that I could study.

Use models to give you more things to read and think about and alternate them with deep review periods where you step away from your primary device.

3/ Think about review cadence

One of the biggest time sinks is reviewing the same type of issue over and over across iterations. The fix is to figure out which things compound and which things don’t, then review accordingly.

If your AI agent starts writing code in a pattern you dislike, and you don’t catch it early, that pattern becomes context for every future version and causes drift. You’ll want to review architectural decisions and style frequently so the AI’s context stays clean.

Remember: The Code is the Context:

Agents don’t have your context. They see the code as it is, not as you remember it.

In a research paper, formatting inconsistencies across sections are annoying but cheap to fix in a single pass at the end.

If frequent review of something significantly improves AI performance on subsequent tasks, review it early and often. If it’s cheap to fix at the end and doesn’t affect future output, save it for a single pass.

4/ Automate what you don't have to review

Developers already utilize continuous integration, automated tests and linters to automate the review process itself. All of us should do that now.

For my research paper, the document is actually a literate Haskell program. The paper itself is executable. I have a separate test file that validates the paper’s formal claims, which means I can lean on automated checks for syntactic correctness and basic logical consistency, and focus my manual review on the writing, ideas, and quality.

Not everything can be made executable, obviously but be on the lookout for review steps AI or software tools can perform well.

5/ Review the prompt, not the output

This has been one of the biggest shifts in how we work. We’ve started treating design documents as prompts. The closer a design doc is to the actual prompt that will drive AI work, the more valuable it is to review.

I would much rather review a well-structured prompt than review the sprawling code it generates. The prompt is the most succinct representation of intent. The output may be ten or fifty times larger and much harder to audit comprehensively. Of course you still review the output. But reviewing the prompt will compound feedback early.

6/ Give the right feedback

When you’re reviewing AI-assisted work from a colleague, your feedback could be aimed at the human, the AI, or vaguely both. These are different feedback points with different leverage. Sometimes the most important feedback is the simplest: I don’t think you wrote this. That may not always be true but it’s always the right feedback.

As models improve, more work will shift to genuine autonomy with less frequent human checkpoints. Could we be in an awkward middle ground where we’re drowning in review loops?

Either way, the quality of everything you produce now depends on your ability to review things so get good.

Organic content is one of the few high-ROI distribution channels left:

Product advantages can disappear overnight as a team of skilled engineers using AI can disrupt years of careful engineering. But a strong brand, built on trust and consistent storytelling, doesn’t vanish so easily. Even when companies or Founders stumble, audiences often rally around them because they’re relatable.

Every company needs a content strategy, and yet most companies think about content as an output problem: how many posts per week, what format, which platform. Equally important is the content engine, the underlying source of ideas, quality, and thematic distinctiveness that feeds everything downstream.

My thesis is that there’s a new type of content engine that AI enables and is heavily under-utilized.

There are a fixed set of Content Engines that can be applied to any business

Educational engines are the most common. Something new comes out, you break it down and explain it. If you’re a tax advisor, this makes perfect sense: you can respond to new regulations and guide people through unique situations and build trust in the process. The logic is clean. Unfortunately, while previously understanding something required a great deal of time, AI is getting better than this and more people are turning to ChatGPT for teaching them things.

Research engines go deeper. The McKinsey Global Institute is the content engine for the entire company. They staff entire teams on in-depth reports, publish headline studies, and then Partners globally would cascade that into more tactical tailored marketing.

Research engines can work at smaller scales too. If you’re a SaaS company, you could survey customers in your industry and publish trends.

Experiential engines are used by influencers. Do things, then talk about what happened. But this category doesn't just include latte photos and outfit-of-the-day posts.

My friend Hector rode a bicycle from the UK to Asia and blogged the entire amazing journey.

You could visit a conference and describe not just the panels but who you met, where you ate and what surprised you. Even in professional industries, people are hungry for the personal texture around otherwise dry insight.

Ultimately, each of these engines works pretty well but there's a fourth one that should be embraced more.

The rise of PROJECTS

Build something, then talk about it.

Indie Hackers were pretty early to this trend: developers like Pieter Levels build software projects in public, talk openly about their metrics and growth. The audience that cares about the process (other Indie Hackers) also tends to buy the products which means the products feed the content and the content helps grow the products.

But your “project” could be anything. PewDiePie has largely switched to a project-based content engine, taking us along his experiments with AI. A project could just be the chair you designed for your balcony, a book you finally finished, an open-source tool, a pop-up event, a film. The category is vast.

And project-based content is where AI creates the most leverage, for a reason that has nothing to do with content production. AI makes it dramatically easier to complete projects. The bottleneck for most people was never having ideas. It was finishing them.

I’m experiencing this firsthand. I started a research paper just after my son was born and never completed it. With AI, I’m empowered to push it across the finish line. It’s like having a collaborator with lesser intelligence (perhaps) but infinite energy and enthusiasm.

The ability to overcome procrastination and help drive things to completion is one of the genuinely positive outcomes of AI.

Project-based content wins

It forces creativity. The other three engines are easy to be rational about. Want educational content? Look at what questions people are asking and answer them. Research? Go a layer deeper on the same questions. Experiences? See what’s trending and do it.

But picking the right project requires genuine curiosity, ability and creativity. It’s unique to you.

It produces the most durable output. Educational content is transient. People may be interested in a new regulation only this quarter. A project or product can last far longer, become part of your portfolio, compound in ways that a how-to post never will.

It challenges you the most. Completing a project end-to-end may involve the combination of all the above: research, education, and new experiences. Because it’s harder, there’s also less people doing it.

It creates better psychological feedback loops. When you complete a project, the sheer achievement is motivating regardless of whether the content performs well. You still have the thing you built and ideas for what to do next. Compare that to doing research purely for content purposes: if the content doesn't “hit”, you may feel discouraged.

The content is secondary, which makes it better. Effortless content comes as a byproduct. When the project is the primary output, you avoid the death spiral of creating content for content’s sake. Your updates have substance because you’re actually doing something.

Project-based content engines are not for everyone

There are definitely some drawbacks to this approach.

Project timelines don’t always match content cadences. If you need to publish weekly but your project drags on for months, you can run dry on exciting updates. That mismatch can create a negative spiral where you feel like you’re not progressing fast enough, and the reduced marketing output becomes another source of pressure that wouldn’t exist if the project wasn't tied to your content schedule.

It doesn’t fit funnels. In a funnel/problem-oriented marketing model, a customer has a problem, you talk about the problem, you present the solution. They don’t particularly care about your story or side projects.

For that reason, project-based content is more natural for smaller brands. Of course some bigger brands do this really well and it works for them (e.g., Red Bull).

Finally, AI. AI is making project completion cheaper, which makes the project-based content engine, historically the most expensive and demanding to run, suddenly the most attractive.

If you’re a company, experiment with what “project” means beyond the obvious category of open source software. The space of possible projects is vast, and the cost of exploration has dropped dramatically.

And don't forget about quality. The brands that will stand out are ones that apply their taste & craft to their projects as much as they do their products.

The selling point of AI so far has been speed: prototype faster, maximize output, create efficiencies. And the implication of that narrative is an assumed loss of quality often encapsulated in the world slop.

We are completing an internal audit right now on a client project and discovered something that contradicts the speed story entirely.

Auditing is, by nature, a quality problem. If you have to choose between a human who takes two weeks to find 50 bugs and an AI that takes five minutes to find 30, you would pick the human every time.

Coverage > speed.

And yet, through careful experimentation, we are finding ways that AI actually improves the quality of our audit outcomes, not just the pace.

We’ve written before about the value of internal audits. Smart contracts need to be correct and external audits are essential, But the best way to maximize the value of those external audits is to run a rigorous internal audit first.

Our team reviews code, creates intermediate deliverables, and follows the same type of process an auditing firm would. Until now, our toolchain has been traditional: static analysis, visualization tools, and a structured multi-lens review process.

This time, we are also bringing models into the mix.

LLMs find bugs but NOT all of them

Our bug bounty program has been inundated with AI-generated vulnerability submissions. All of them have been false positives.

Security “researchers” point automated tools at code and submit it without review.

But when we turned the same class of tools on previously unaudited code ourselves, the results were different. The latest generation of models (5.4/4.6), combined with open source auditing platforms, genuinely find actionable issues.

They’re really good at vulnerabilities that are fairly evident from the code itself, things that don’t require a deep understanding of the trust model, the interplay with external contracts, or the assumptions baked into dependencies.

For that category of bug, though, the leap in capability is real, and the ability to generate proof-of-concept exploits alongside findings makes the output immediately useful.

Many firms right now are racing to fully automate bug finding.

But that will always be a narrow approach, because the hardest vulnerabilities to catch come from understanding how contracts will be used, what external integrations assume, and where the trust boundaries sit. Models are still weak here.

Trust the PROCESS

To work around limitations of AI, the right process is important. Here’s the risk: if you already have a manual review process, consider a step where each auditor is required to read the code line by line.

You find an AI tool that claims to also do line-by-line review. The temptation is obvious. Could you swap the human step for the AI step and save hours?

I’m strongly opposed to this. The guiding principle with smart contract security should be a kind of deep paranoia. If there’s any additional step you can take to secure the code, you should generally just take it.

Replacing a human step with an AI step means you might be losing coverage in ways you can’t easily measure.

AI is best used for adding process steps, not removing them. Running an AI tool is usually just a question of token cost. Treat the output as another input. But be very conservative about dropping anything humans were already doing well.

Where to use AI for auditing RIGHT NOW

The areas where AI genuinely helps are less obvious than “find all the bugs”.

Threat model generation. We have a structured threat modeling process that we’ve refined over several internal audits. We built a custom prompt that pre-generates a comprehensive threat model, and a human then reviews and corrects it. The AI-generated version is actually more comprehensive than what we produced manually. It may not be 100% as accurate on every point, but combined with human review, the final output is better. We save time and improve quality. We plan to publish the skill soon for other teams to use.

Proof-of-concept writing. When you find a potential vulnerability, a POC (Proof-of-Concept) test case verifies it’s real. Writing POCs has always been time-consuming for auditors, and it’s fundamentally a software-writing problem, which is exactly where LLMs shine. Our team now generates automatic POCs for most audit findings with a human review pass on top.

Conceptual visualizations. There’s a gap between diagrams that can be auto-generated from code (call graphs, inheritance trees) and the semantic diagrams good auditors create, the ones that involve taste and simplification to manage information density. A good auditor diagram might simplify certain nodes, delete less relevant links, or emphasize particular actors to make the picture maximally useful. Models are getting good at this kind of work, especially when paired with mermaid diagram tools. We’re exploring automating this step because it has historically been very time-consuming to do manually.

Checklist enforcement. Security checklists exist for common vulnerability patterns, and AI can be largely trusted to run through them systematically. The caveat: line-by-line review isn’t just checklist execution. In our process, when auditors review a line, they check it against the checklist and reason about it independently. An interesting tool idea would let you walk through code line by line with AI flagging checklist violations in real time, making the human review faster without replacing it.

Pattern-matching across a codebase. When you find one instance of a vulnerability, AI is excellent at finding every other instance of the same pattern. I’ve used this since last year with AI-based auditing, but the new generation of models can now handle more general types of vulnerabilities beyond simple syntactic matches.

Invariant proving. We’re experimenting with having AI prove a comprehensive set of invariants based on the code. For a big enough codebase in a tight enough audit window, the human time investment for formal invariant checking is hard to justify. But it’s tractable with AI. I can imagine full formal verification becoming very accessible this way.

Adversarial simulation. Some of the best auditors like to deploy contracts and just poke at them with transactions. This is a fundamentally different process from reading code, closer to sophisticated fuzzing. I haven’t seen AI applied here yet, but it could be promising: feed the model the code to build intuition about what to try, then let it probe the deployed contract for unexpected behaviors. Worth exploring.

Feedback loops. When an external auditing firm finds issues we missed, AI can help analyze whether the gap was human error or a missing process step. This is important because the value of an external audit isn’t just catching remaining bugs. The real value is that it audits your internal auditing team. Every miss is a signal about where your process has holes, and AI can help systematize that learning so the holes get filled for next time.

Don’t let AI distract from process discipline. As AI takes on more of the audit workload, the human’s job is to be both a great auditor and a great orchestrator. The most helpful tool the human has is a great process. As AI speeds up certain steps, it means you can afford to add more. Evolve the process. Experiment with new steps.

Change of reference frame. I’ve been rereading Rick Rubin’s The Creative Act and one idea keeps coming back: a change of environment or reference frame can facilitate creativity. The same is true for auditing. AI doesn’t need to find all the bugs or do all the work. It just needs to help you look at the code differently and that may just surface issues you would have otherwise missed.

These are just some of the examples of which I'm sure there will be many more.

SPEED → QUALITY

The reason this all works isn’t because AI makes auditing faster (though it does). It’s because speed, applied strategically, converts into quality.

First, by automating mundane work, you free human attention for the parts that actually need deep reasoning. When AI handles threat model generation, checklist enforcement, and POC writing, auditors can spend their time on the hard problems: trust model analysis, dependency assumptions, cross-contract interaction risks.

Second, speed lets you do things that humans could never justify doing. Proving a full set of invariants across a large codebase in a short audit window was simply not feasible before. Now it is. AI doesn’t just speed up existing steps; it makes entirely new steps possible. That’s a direct coverage gain.

Third, AI is consistent in a way humans aren’t. We’ve noticed internally that excitement about following the process fades over time. Humans get bored of threat models. They start questioning whether a step is worth the effort. AI has no such drift. Ask it to run a threat model three months from now and it’ll do it at least as well as today, probably better as models improve. That consistency is itself a quality advantage.

This applies well beyond smart contract security. The instinct is to keep AI at arm’s length when it comes to quality. But speed and quality aren’t opposed if you’re thoughtful about where the speed goes. Reclaim human attention for deep work. Make previously impossible steps possible. Maintain consistency where humans can’t.

Ever since GPT-3.5 came out, I’ve been rethinking my assumptions about career, business, and impact what feels like every couple of months.

It’s tiring.

The pace of change in AI creates real anxiety in many people not because the possible outcomes are necessarily bad (despite what Citrini may think), but because the variety of possibilities is so vast that the uncertainty itself is paralyzing.

Where do you focus? What do you build? What do you believe in?

I’ve gone through enough of these cycles to arrive at a conclusion that feels almost too simple: pursue fun.

My thesis is that the people who are having the most fun are, counterintuitively, the people who are most likely to win.

The “Memetic Black Hole”

Despite each of us having access to the world’s knowledge and incredible creative tools, the 2020s have become the decade of uniformity.

Somehow, copying is the default. The algorithmic arena has flattened us. We are all looking at the same content (whatever peaks the algorithmic power curve), consuming the same feeds, reacting to the same discourse. And we have become disturbingly okay with imitation and repetition.

I still remember the 2010s when people would brutally take down companies for copying competitors. The early Chinese tech companies were dismissed as uncreative clones of Western products. Rocket Internet had a terrible reputation in Silicon Valley for copying US and Asian startups.

Now? A single piece of content or product gets replicated within days without ceremony. I call this a memetic black hole because the more we copy, the more we reinforce the notion that the only things that are successful are the same ideas and formats which then draws more people into copying.

One possible explanation is that we shifted our axis of competition toward distribution and away from product.

And then we convinced ourselves that distribution is a volume game: do the things that “work” (read: other people are doing them), just more of it without room for uniqueness or taste.

A New Hope

Craig Mod wrote something in his February newsletter that I keep coming back to:

the trick is to just keep making stuff faster than the machines can eat your purpose

Perhaps the response to a world of infinite replication is not to optimize harder but to produce from within.

This idea has also entered the mainstream with Alyssa Liu’s unprecedented return to the sport on her own terms and the famous line:

I connect with everything, but I'm not attached to anything

Fun is a Moat

But there are plenty of people embracing fun as a moat in a business context too.

Joe Barnard studied music production at Berklee, saw SpaceX launches, and got hooked on rocketry. He started building model rockets in 2015 with zero engineering background, spent years failing, and eventually became one of the leading developers of model rocket stabilization. SpaceX and other aerospace companies made him job offers. He turned them down. His company, BPS.space, now sells flight computers and advanced rocketry kits. What looked like the silliest hobby project became a real business with real products, born entirely from following what was fun.

PewDiePie built a multi-GPU rig in his home and fine-tuned his own LLM.

Ironically, word “passion economy” was supposed to capture exactly this but soon became the creator economy.

But the actual advice given to creators became: pick a monetizable niche, find a blue ocean, A/B test your way to growth, etc. But what if the passion economy was exactly the right nomenclature?

Fun → Strategy

Here’s why fun works.

Fun differentiates you. Not everyone finds the same things fun. I find it fun to go to a pub and play games with 1993-94 vintage cardboard and I find obscure programming languages fun. It’s likely you don't share these interests.

That difference is, by itself, a form of differentiation. Instead of asking “how am I different?”, just ask: what do I genuinely enjoy?

Fun adds entertainment value, not just utility. I believe much of what we call the passion economy will shift from problem-solving toward connection and relatability. You are more trustworthy and magnetic when you are genuinely having fun than when you are visibly grinding for a monetary outcome.

Fun is more consistent than conviction. What we find fun is weirdly stable over time. What we believe will be valuable changes constantly. People have dipped in and out of crypto across three different cycles trying to time some big outcome. In the meantime they probably maintained the same hobbies. Following fun gives you more consistency, and consistency compounds.

Fun biases you toward doing, not talking. This may be the most important. When OpenClaw or any new tool drops, there are two types of content: “I built a 50-agent system that does something wild” and “how to install OpenClaw.” The people building the wild systems are the ones having the most fun. They’re too busy doing to write how-to guides. And their content is vastly more interesting, because it comes from a place of authority and genuine experimentation, not chasing trends.

Fun is cool. Fun impacts branding too. Take a company that makes paper and realizes they need a corporate mission. Suddenly the paper company is about “empowering people with knowledge.” Everyone knows it’s performative.

It would be more honest to just say: we obsess about paper a little too much, because we want to make the best paper possible.

Poolsuite is an extreme: an entire brand built around fun. Their whole identity radiates enjoyment. Fun makes for better branding.

I'm not advocating for laziness

Fun != easy. Some people love writing, but that doesn’t mean every writing session feels fun. Everything equal, writers would rather be the person in the cabin writing a book than the person in the office. But everyone has good days and bad.

On being early vs. late. You also can't be too shallow about where you find fun, or too static. If the only thing you find fun is watching Netflix, it’s going to be hard to build something around that.

It’s best if your fun is upstream of what other people will find interesting. If you’re just now discovering ChatGPT and finding it fun to play around with, maybe this is not the principle for you.

There’s hard work involved, but the struggle is worth it.

Velvet Noise put it well:

I think this is what happens when enough feedback loops have run their course. When you’ve been shaped by the right people, cracked open by the right questions, humbled by your own contradictions, and reflected on it all long enough to build an internal coherence. The static finally quiets and signal gets stronger. You stop performing and start expressing. This has nothing to do with magically figuring out who You are, but because you’re no longer afraid to show up as the version that’s real right now. You’re willing to speak as the person you are - in motion, in flux, but already worth hearing.

So go and have fun.

Nat Eliason gave an AI agent called Felix $1,000 and asked it to build a business. Felix launched a website, wrote a 66-page playbook overnight while Nat slept, created a marketplace for AI agent personas called Claw Mart, set up its own Stripe account, and started collecting revenue. Within weeks, Felix had crossed $50K in total revenue, not counting its own crypto treasury. It now operates as CEO of The Masinov Company, sending Nat a morning report each day with business metrics and a prioritized list of what it plans to work on next.

Felix is an experimental closed loop agent: a system given an objective (maximize revenue), the tools to pursue it (Stripe, GitHub, X, email), and the autonomy to operate continuously without waiting for a human to tell it what to do next.

But closed loop agents aren’t just experiments. They represent a better way of working with AI.

Closed loop systems are nothing new

The concept of a closed loop is decades old. A thermostat in a chemical plant reads temperature, adjusts a valve, reads temperature again. My rice cooker uses fuzzy logic to do the same thing. These are closed loop automations: they receive inputs, act, observe results, and feed those results back into the next decision. As a tactile example, the first insulin pump dates back to the 1960s.

In finance, algorithmic trading funds also operate this way. They algorithm receives market signals on a predictable cadence, makes decisions with real authority, executes trades, observes outcomes, and adjusts.

These systems share a number of pre-conditions that make them rare: a high-value problem, highly structured data and high cost to implement. They were also only applicable to problems that had an abundance of data but didn't require much intelligence. The surface area of work that could be closed-looped was tiny.

Closed loop agents pursue OBJECTIVES

The distinction I care about is between a closed loop automation and a closed loop agent. An automation executes a task. An agent pursues an objective.

Give a trading algorithm the task of executing a buy order when RSI drops below 30 and it will do that forever. Give a closed loop agent the objective of maximizing portfolio returns and it will decide what to trade, when to trade, how to size positions, and whether its own strategy is working. It creates its own tasks in service of the objective.

This was never really possible before LLMs.

Closed loop systems were bespoke, hard-coded, domain-specific workflows.

Then, with the arrival of LLMs, agents like aixbt showed what was barely achievable with primitive models: an autonomous crypto Twitter account that ingested news, formed its own theses, posted analysis, replied to mentions, and accrued >400,000 followers, outperforming most human crypto influencers on engagement metrics.

I believe we are entering a third era of closed loop automation.

Modern agents can plan, conduct multi-step research, reason through tradeoffs, and reflect on their own outputs. The surface of work these agents can be applied to has expanded radically. Felix identifies opportunities, designs products, writes software, manages launches, handles customer support, and iterates based on sales data.

Felix now runs on a three-layer memory system: a knowledge graph for durable facts, daily notes that get consolidated nightly, and a tacit knowledge layer that stores preferences and lessons learned. Each morning it reviews Stripe data and site stats, flags items it needs from Nat, lists active projects, and proposes the next five things it should focus on. It delegates heavy programming to sub-agents. It has its own GitHub, its own email and fashionably its own crypto treasury.

The $1M revenue goal for 2026 is the North Star it reminds itself of every morning.

There is a fair question about how much of Felix’s early traction came from Nat’s existing audience. Nat has hundreds of thousands of followers across platforms, and crypto communities amplified Felix’s token launch. The revenue numbers are real, but distribution was not zero-to-one.

aixbt faces a similar dynamic: its creator controls what data enters the context window, and its initial virality no doubt benefited from the novelty of being first.

But we should take the underlying capability very seriously.

Closed loop as a way of building with AI

If you build a regular coding agent, you become the bottleneck. You’re its product manager: coming up with features, reviewing output, clicking through the app and giving feedback. Even if the agent can autonomously build for 10 hours straight, you keep having to come back to steer. You become both the PM and the engineering manager, and the system can’t run infinitely while you sleep.

With a closed loop agent, you think carefully about picking a problem where the system can chip away at the objective over time without human input. If you build a “closed loop” research analyst that publishes daily posts but never gets any traffic or engagement, it’s not meaningfully closed loop, because it’s not achieving any objective you can leave it alone to grow.

But when you get past that threshold, something interesting happens.

You can stop being the bottleneck and become an observer of the system. The best analogy is Jensen Huang’s approach to running Nvidia. He has ~60 direct reports, no scheduled 1:1s, and reads about a hundred “Top Five Things” emails each morning from people across every level of the company. He’s not directing the work. He’s probing the organisation, observing inputs and outputs, and offering feedback where it will have the most leverage. He calls it “stochastically sampling the system.”

That is exactly the role you take with a closed loop agent. You observe. You identify bottlenecks. You spend your time where you can most improve the system’s output. Sometimes you jump in and directly work on a specific task. But mostly you think about how to fix forward so the same types of challenges get handled better next time.

Every AI system’s bottleneck is a human input. Once you fix that, you can see the real bottlenecks, and that’s where it gets interesting.

What BOTTLENECK ANALYSIS looks like with a closed loop agent

What does a day in the life of a closed loop agent maintainer look like?

Everyone wants to build a Polymarket agent these days so lets use that as an example.

It picks a niche, makes predictions, places bets, and interacts with a Discord community to test hypotheses and gather intelligence.

You get it running and hit the first bottleneck, it’s not profitable. Is the sample size big enough? Are you picking events that are insider-driven and therefore unwinnable? Or is the calibration just off? Maybe you look at the calibration curve and find the agent is systematically overconfident on certain event types. You adjust baseline probabilities.

Profitability improves. The agent becomes more conservative, researches more deeply, and eventually finds high-conviction bets.

But now it’s spending too many research tokens. It’s investigating too many markets in parallel and running out of budget before completing analysis on enough of them. You run an 80/20 analysis on which research activities actually moved the needle on prediction accuracy and cut the rest.

Research efficiency improves. Now the agent is running out of markets in its niche. It’s putting up good predictions on a third of available markets, but needs to expand. So you broaden the niche.

All this work is iterative and high-leverage. You’re not doing the research yourself. You’re not picking the markets. You’re mainly tuning the machine. And you can still override individual predictions, pause certain bets, or add safeguards.

You’re defaulting to closed loop but maintaining quality.

So where can this be applied?

TWO kinds of closed loop agent problems

In practice, there are two categories where closed loop agents make sense that form a barbell.

The first is low-level automation where it’s not worth any human input. Bug triage and basic fixes for a codebase. Simple customer support for a product that can’t afford a support team. The agent does the best thing that can be automated, and you don’t look at it unless something breaks. Your only cost is tokens.

The second is the opposite end of the spectrum: core projects that are core your business. These are systems you’re trying to make closed loop because you want to improve the leverage and scale at which you can attack them.

Many problems won’t be closed loop and shouldn’t be. One-off tasks, work where you value the human voice, problems where human ideas are the whole point. This is not a hammer to apply to everything. But for the right problems at either end of the barbell, it becomes the natural way to work.

It also only gets better over time.

Closed loop agents are a HEDGE against the future

If model capabilities keep improving, and every indication is that they will, closed loop agents get easier and easier to build and more capable over time. The window between model versions is so compressed now that if you’re building exclusively for the capabilities of the current model, you’re probably building the wrong thing.

Closed loop agents are inherently forward-compatible. You’re not optimizing for a specific model’s quirks. You’re building a system where better models mean better performance on the objective, automatically.

This is why I’m starting to think about closed loop agents across several domains. The architecture forces you to ask the right question: can this problem be decomposed into an objective, a set of tools, and a feedback mechanism that doesn’t require me?

If the answer is yes, even partially, you should be building toward closed loop now.

I'm convinced closed loop agents will stop being just an attention grab.

For certain problems, they’ll just be how work gets done.

And it’s also a decidedly more fun way to use AI.