It’s fun to see Block’s view on capabilities expressed in practice as they launch another open source project Berd.

As a reminder, this is how we described Jack’s views on products vs. capabilities when talking about the future of work:

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.

IT’S A HARNESS WITHOUT LOCK-IN

Berd is a unified interface to do your personal agent work. It doesn’t carry any of its own models although it does implement some built in agents.

Here are some of the key features:

It’s self-sovereign

Your chat history, skills, global prompts are stored on your computer as opposed to a model provider’s database. It’s also a nice interface to use, for example, if you use a combination of local models and say Claude or Codex.

It hosts your skills

An annoying quirk of how Claude and Codex work is that you have to develop skills separately from using them.

Berd helps you realize that skills are just markdown files so you can create simple ones directly in the UI.

It hosts your “agents”

An agent in this case is merely a single markdown file of context, kind of like a system prompt or AGENTS/CLAUDE file.

Memory doesn't even persist across sessions so I'm not sure it is very useful to think of these as agents necessarily.

It can access various models/harnesses

One of the things that surprised me is that Codex was “installed” by default since I had it as a CLI on my machine.

It's beautiful

The interface reminds me of Arc.

Every time you create a project, you get to pick the colors and the interface moves with the color of the project. The visual agents are visually striking. Lastly despite this inevitably being vibe coded, it doesn't feel like it. That’s really hard to achieve these days.

BERD IS PROBABLY NOT THE FUTURE OF WORK

Having said all that, I don't think Block is betting on Berd.

When Block released Buzz, we looked behind the scenes and described what could be learned from their development process.

Unfortunately the Berd repository was imported all at once. I suspect from their blog post that the tool was actually built before Buzz and Buzz became a refinement of their vision that agentic development needs to be social, superseding Berd.

I think some of the abstractions (visualizing bits of global context as tangible agents) are valuable enough to hopefully see further adoption.

The current desktop app will be useful in the meantime to people and companies who want to:

• Use different models within the same project (especially mix of say Anthropic/OpenAI models and local models);

• Have more privacy for more sensitive use cases;

• Retain their sovereignty and context;

• Educators (!). I think this app is a perfect way to teach kids about context management through agents, skills and other tools.

I was surprised in how smoothly it worked out of the box and it will be tempting to make this my UI of choice for certain cross-model tasks.

Recently I had the privilege of going on the Applied Methods podcast hosted by my friend James Mulligan to talk about how AI is reshaping work.

Instead of complaining that AI will take people’s jobs, James is building Applied Methods. It’s a platform that aims to observe and document the evolution of work and help everyone figure out their place in the new world. It features a job board tracking AI-native roles and a podcast interviewing people using AI.

A clearer signal sits with AI companies themselves: the labs building the models, the companies building the infrastructure, and the companies building AI-native applications. These are the organisations staffing, from scratch, for a world in which the method and the model are designed together.

Applied Methods tracks hiring at established and emerging AI companies. Every active posting is classified into a taxonomy of functions and roles that is constantly evolving: new roles emerge, existing ones shift, and the skills required to stay competitive are changing in real time.

Applied Methods exists to make those shifts visible early. Our taxonomy is updated in real time to reflect the meta as it moves. For the people closing the gap themselves, staying ahead of how AI companies are hiring is one of the more direct ways to stay competitive in a market that rewrites itself faster than it can be surveyed.

We covered a very broad range of topics from the past & future of Auditless, practical ways I use AI today, the changing nature of work, how to educate our kids and the risks facing consulting companies.

You are welcome to listen to it on your favorite platform and let me know what you think. I’m especially curious for any contrarian takes on education.

I’ll leave you with a quote from the pod:

You’ll still need yoga instructors in the wild — they don’t need to use AI. It probably takes away some of your credibility if you put Calm or Headspace on in the room. But if you’re someone currently using a keyboard to produce all your output, it’s possible you [will] find yourself spending much more of your time on distribution than on deliverables.

Silicon Valley operates in a special kind of micro-cycle.

It starts with an unresolved problem that creates a narrative vacuum. In the context of AI, for example:

- realizing that open source models are viable,
- that AI companies enjoy lower margins,
- or that vertical AI platforms are squeezed from both sides.

This is how you get a narrative vacuum.

Of course, few people have a clue how to solve the problem so VCs hold off from deploying capital. Then one of the ~100 or so independent thinkers in Silicon Valley comes up with a solution, usually in the form of a new type of startup that carries a new pseudosecret.

Eventually the pseudosecret comes out and becomes a blueprint. Startups copy each other and faithfully replicate the most minute details such as website design, GTM approach, even the way they talk about the mission or the way the Founders dress. The best way to get a feel for this is to look at YC batches since the accelerator amplifies pattern replication.

I want to share a couple of unique brands that have caught my attention and talk about what blueprints they may represent.

DISCOVERY LOOP

The design is obviously very vibe-coded but who cares when your team picture has the 4 engineers Google would never put on a plane together.

They are describing a sort of proto-OpenAI but targeting a vertical (scientific discovery). The “product” itself would be the agentic/auto-research loop.

Our general approach is to automate the experimental loop. We think this approach is broadly applicable across many different fields of science and engineering. We’ll initially focus on ML research and engineering, but believe the approach can help with important subproblems in nearly every one of the fourteen. NAE Grand Challenge problems. We think doing this well requires strong expertise in machine learning as well as large-scale systems.

The latter point is especially relevant as a comparison to early OpenAI which benefited from Greg Brockman’s systems engineering as much as from the research team.

EngramLab is another company modeled in this fashion:

LEAN LUXE

In complete contrast with AI companies, Lean Luxe pivots away from a branding oriented newsletter into a social cohort experience focused on helping millennials make friends in their thirties (a nod to 2020 anyone?).

The branding, newsletter design and copy is on point for this target audience. It’s by no means the only Substack-first business out there.

8090

You may not like it but this is what peak performance looks like. Enterprise companies depend on contractors to deliver software and new AI-augmented contractors are emerging. A related-trend is supporting software development at scale.

POOLSIDE

Next-gen open-first companies are another interesting category. Companies moving so fast (often through leveraging vibe-coding) that they haven't had time to work out what the product will be yet. OpenClaw is another example of course.

Covenant have also done some ground breaking model training work leveraging crypto incentives:

GENERAL INTELLIGENCE COMPANY

Our final example is companies that market how they work as much as the product. The General Intelligence Company blog is a great source of ideas for how smaller startups are getting an edge:

A two engineer code review totally ruins this dynamic. If your engineer is able to manage five simple tasks, two manageable tasks, and one complex task at a time, your two engineer code review system now requires them to review ten simple tasks (theirs and others), four manageable tasks, and two complex tasks. This will be the hardest thing to adapt to if you run an established engineering org.

One thing that ultimately unifies these companies is that they are very clear about either being very pro-AI or wanting nothing to do with AI/software (Lean Luxe) and that is reflected in brand, product and messaging. These companies also represent clear views of possible futures and how they participate in shaping those futures.

Jack just launched Buzz.

It's a Slack replacement (group chat platform) that aims to bundle together Slack + Slack-native agents like Centaur and Claude Tag and a slice of GitHub (the ability to create and review PRs).

While on the surface it seems more like an experiment and I don't think it has too much strategic significance at this stage, it was in fact open sourced. Wouldn't it be useful to look at how a (self-proclaimed?) best-in-class organization builds with AI?

FIRST, THE BASICS

None of this should surprise you but Block is not reinventing the wheel on basic context management. There’s a solid README.md, an AGENTS.md file, a CLAUDE.md symlinked to it.

There's also two custom skills in the repository (and I assume a lot more shared at org level). The AGENTS.md file is further broken down into files like SECURITY.md, TESTING.md, RELEASING.md, etc. that cover the relevant operating procedures.

Team members tag both Codex and Block’s own Builderbot for code reviews:

The repo calls for an in-depth harness with extensive end-to-end and smoke tests:

All commit messages are written by Claude/Codex. For simpler fixes, engineers seem to be merging their own changes into main without awaiting review.

Nothing ground-breaking so far.

1/ VISION SETTING

Block chose to create several Vision files, each of them serving as a high-level PRD, describing the key app surfaces and domain model. Here's the main one:

(AI is clearly writing these files.)

The system architecture file also has an impressive level of detail although this may be one of the few that is targeted at humans as much as it is targeted at agents (the ASCII diagram being the hint).

2/ BETTER REVIEWS WITH PR SCREENSHOTS

A chunk of the repo (skills and readme) is dedicated to explaining the PR screenshot functionality which allows agents to create reviewable previews of features, here’s a part of the skill:

I'm guessing that screenshots may be easier for other agents to review (as opposed to say a staging preview).

Pretty cool and I expect this may be the most forked part of this repository.

3/ HOW IT STARTED

Finally, I went back to the original commit for this service and it used to be called Sprout and didn't even have an app.

The initial architecture and vision docs were already there suggesting that the team had deliberated on a domain model quite a bit before focusing on the desktop features and concept taxonomy.

Ultimately, the repo isn't dissimilar from what your AI projects probably already look like. It started pretty humble (but with a coherent core of context) and expands from there. It’s also a pretty engineering-driven project which fits Block’s thesis that we covered earlier:

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.

I feel I have to apologize that I don't have a hot take about Buzz.

I think it’s an interesting project which incorporates some aspects of the crypto/cypherpunk ethos but after the statements Jack made about the future of work, I was much more interested in what Buzz reveals about how Block ships code.

In short, their AI use is not that different from yours & mine and the areas where they are doing something a little different are working towards higher engineering velocity: enabling PR screenshots to speed up reviews, having great in-repo context for agents, not having engineers waste time writing documentation or reviewing smaller fixes.

As a Twitter intern, it’s pretty cool to see we may never go back to a slower mode of work.

Private Equity acquisitions used to be relatively deterministic. Skilled investors could guess the percentage growth of EBITDA they could create with a playbook of 10-20 repeatable changes they could apply to a business. Most of these changes were industry agnostic: renegotiate contracts, increase prices, trim management, etc.

Private Equity investors discovered early that the ways in which companies tended to be bloated, biased or simply irrational made certain improvements almost guaranteed to work. Most of these programs required very little resources too. An operator could come in from the PE firm, get installed as the CEO or CFO and often implement most of the playbook in the first year or two.

From my conversations with PE-backed CEOs, I think AI has changed this and blown the playbook wide open.

PE-backed CEOs now have to make trade-offs across 3-different roadmaps.

MODERNIZATION

This is the first and most direct descendant of traditional PE interventions. Legacy companies have legacy software, legacy processes and legacy attitudes. All those things have to change. It’s the software side that’s most interesting, however.

Operating teams could rarely afford to come in and modernize an entire software stack. For one, they would have had to bring in a significant amount of additional engineers and that’s not great for improving EBITDA over a short-term horizon. The second reason was that improvements didn't have to be holistic. If a company is making $15M a year using legacy software, they can probably make $30M a year using that same software by doubling prices. Hold things constant if they are hard to improve and move the needles that are easier and faster to move. Third, never rewrite software or so it used to be the case.

Now there’s more reason to consider refactoring:

• AI is making engineering so productive that rewrites feel attainable;

• Competitive pressures are higher – both existing competitors can move faster and new startups can enter and chip away at market share;

• There’s an awareness that having legacy code makes agentic engineering less effective or could prevent attracting the type of talent that can make the most of agentic engineering;

• The idea that a rewrite could be difficult would imply a lack of organizational comfort over AI tooling. When Anthropic engineers talk about leveraging looping, why are we talking about human bottlenecks for something as deterministic as a software rewrite?

OPERATIONS

The second big roadmap item is expecting that everyone can do their job better with AI.

It’s just not obvious how go get there yet.

Does it mean completely scrapping the vendor list and looking for more AI-native applications?

Does it mean running one hundred internal transformation projects touching every single department?

Does it mean equipping everyone in functional teams to use Claude and build tools for themselves even if they are non-technical?

Or perhaps building a super agent that can understand the entire company and help everyone do their job?

The truth lies in finding the right combination of these ingredients and while operations can be the most impactful area, it’s harder to impact because the people with the domain expertise are often not the ones with engineering experience and not the most AI-native either.

PRODUCTS

Finally, companies are paranoid about how relevant their existing products & services are and how they should imbue them with intelligence.

At one point everyone wanted a chatbot, now having an agent or MCP server on the roadmap is table stakes. But the best companies are seeing OpenAI and Anthropic as direct competitors and are rethinking their strategic moats entirely.

Satya Nadella’s and Alex Karp's comments on sovereign AI are no doubt part of their GTM but that doesn't mean they are wrong. Company moats won't just be reduced to proprietary data and physical assets, there is room to build AI-powered products around proprietary capabilities and use them to create feedback loops that create more data or improve the company’s own proprietary models.

If Prime Intellect making $100M in ARR is any indication, there’s a lot more proprietary model development happening behind the scenes than we may think.

Not only do PE-backed companies have to decide how to juggle the 3 possible roadmaps in parallel, they have to resource all of the work too.

And from where? All three roadmap items require a degree of AI-nativity that neither the PE-backed company nor even the PE operating team may already possess.

I was very lucky to get exposure to management early.

Being a management consultant requires you to plug into a new company and get work done without any formal reporting influence from day 1. Often the people that were excited to hire you aren't the people you are working with. I also got to be managed by many, many different people as projects lasted 2-3 months at a time. I learned a lot from their successes and mistakes. My first chance to manage another consultant happened in my 2nd year as an Analyst in McKinsey (too easy, McKinsey’s hiring is just too good!). Then, I became a Product Manager – an funny role, no direct reports but still a “Manager” by name. Then Principal Product Manager managing another PM and finally as a Founder, managing people I've hired directly.

I feel pretty comfortable working with people now. I'd by no means call myself a leadership coach but I know not to be an asshole and still get things done and you'd be surprised how many managers set the bar lower than that.

Management takes time to learn and more so because you have to develop a management style that suits your strengths and adapt it to each organization and person you are working with.

As I talk to people about how to better use AI I'm realizing it’s hard for one person to help another.

You can teach someone to use spreadsheet software with a 10 hour course. I'm not sure a course like this exists for AI, certainly not outside the narrow scope of a single job in a single company.

Learning how to use AI well is like learning management. It’s a long journey that we are all early on. Our use of it has to be shaped in line with the way we like to work and our strengths. There are aspects of AI that are similar to tools such as choosing a provider, configuring it, etc. but the day to day delegation decisions and feedback loops are much more akin to management than using a tool.

This presents a new type of problem for companies looking to “align” AI use. It’s a tool so we want to use the same tool, the same configuration, the same context. But it’s also management and everyone wants to do it their own way.

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.