In this episode, I want to walk you through how to build a truly
AI first team of business. This month, Y Combinator, one of
the most famous start up accelerators and venture capital
firms in the entire world who have been the place that Airbnb,
Coinbase, Dropbox, Reddit, Stripe, basically most of the
biggest businesses in the entire world have come from.
And they share incredible insights every single quarter.
And this month they shared a playbook for building what they
see as an AI first company. And the contrast here is not
just somebody or a team or a business that uses AI, but that
is built on AI. They're the very heart of every
new idea that is emerging in the world, based in San Francisco
around the most innovative people and ideas you can
possibly imagine. They showed 6 principles from
what they're seeing with all the latest hot AI start-ups that
they're working with. And I'm going to talk about a
very publication of how this is actually playing out real time
by Jack Dorsey, the ex founder of Twitter, who has a new
company called Block. I'm going to explain the
playbook. I'm going to talk about what
that actually looks like when it's running properly and give
you some ideas to bring to your next team or business meeting.
This is in the loop with Jack Hot.
I hope you enjoy the show. So let's start with a bit of
background. So about 10 days ago, so about
24th of April, Diana Hugh, a general partner at YC, he
basically overseas their AI companies program published what
was called the playbook for building an AI native company.
And it blew up, of course, soon as it was shared.
And the reason it spread so fast is that a, it's named something
that a lot of people are watching happen without quite
having the language for or the playbook for.
And the fact that it covers team or company going through this AI
journey. It was described as AI, as your
company's operating system, open versus closed loop systems and
companies and teams making a company or team fully queryable.
And the rise of 1000 ex employee, team member and
engineer. And essentially why this means
that middle management disappears and why start-ups or
smaller companies have a huge opportunity to win right now
because of the natural challenges that big companies
face. And what's quite interesting is
a couple months earlier, Jack Dorsey, who has basically run a
lot of these principles real time.
So Block, Jack Dorsey's company, for anyone not familiar is, is a
fintech company. So you might have seen Square,
the payment provider systems when you go to buy a coffee or
whatever. And it's basically a
peer-to-peer money app used by about 57 million Americans and
companies. And in February of 2026, he
decided to cut 40% of the entire block workforce in a single
letter, not because it was struggling.
The business actually profit was up, you know, nearly 25% over
the last quarter, but actually because the architecture of the
company he believed no longer matched what the technology of
LLMS now makes possible. And so when she published this
playbook, you know, two months later, the block story was a
really fantastic case study of this playing out in real time.
And I'm not placing a value judgement or whether that is
good or bad right now. I'm just going to talk about
what an AI first company and team really looks like.
So let's get into the playbook. So there's 8 principles and and
principle number one is that AI is the operating system, not
just a tool. So most companies right now are
doing something quite similar. They're rolling out, you know,
enterprise licences, putting AI assistance on the sidebar of
every application. They've got internal prompt
engineering workshops. That's not AI as an operating
system that is making existing processes a little bit faster
without actually changing anything.
And Dorsey frame this as the turbocharger on a horse cart.
The horse is still doing the work.
You just made the horse a little bit less tired.
And the distinction drawn in this principle here is that your
company should not be able to function without AI in the same
way it can't function without Microsoft Teams or e-mail or
Slack. Not AI makes us work faster.
AI is actually how everything gets done.
And the test is quite simple. I think could your most
important daily team workflows run for a week if you switched
off all AI tools? If the answer is yes and the
work would carry on more or less normal but slower, then you're
just using AI as a tool and you're not running it as an
operating system. I'll give you a couple of good
examples. We've quite literally built
internal tools for managing all systems that literally building
them using public APIs from Twitter, for example.
We have every process that is built around AI now and we
haven't got enough people to suddenly run all of those
anymore. We we would literally be ceasing
to function as a team. For example, every task of
scheduled task on one system feeds into the next system to
run the next process. Every team takes those outputs
and puts it into the next process.
We we can't function anymore. Block shared a really
interesting example. Jack Dorsey's company.
Essentially they've got something called Manager Bot.
It sits inside Square and monitors each merchants
inventory levels, sales velocity, their staffing, and
other signals are upcoming events and weather patterns.
And it doesn't wait for a merchant to notice a problem or
ask for help. It literally surfaces an action
before the merchant even realizes there's a problem.
You can't just switch that off on a Friday and start again on a
on a Monday. It's not a feature, it's now a
layer of their entire system. Principle number 2 is closed
loops, not open loops. So an open loop is basically
where a decision goes out, something happens, and the
result never really comes back in.
In AI, that is a pillar of success and effectiveness.
You know, most companies are running almost entirely on open
loops and they have no idea whether things are working or
not, or if the agents are making the right decisions or they're
not able to scale these systems because that closed loop doesn't
exist. And I've talked about This is
why, you know, MD file structures that we talked about
in the last episode exist where an agent logs its decision and,
and stuff like that. But that's just not scalable, as
I've mentioned before, because these decisions need to be
logged at scale and each agent needs to pick up from that
decision. And most companies are basically
running entirely on open leaps and have zero idea about what's
working as a result. And that's how companies have
always worked. They've relied on humans to be
the closed leap to retain that bit of information about whether
something was successful, put in a spreadsheet or a dashboard
maybe, that a human may check every few months or weeks.
A good example is you run a marketing campaign, you see the
total conversion numbers. You do not know really which
specific touch points drove that conversion.
Some tools give you that insight.
You don't have an idea of maybe the sequence of interactions,
the variance of messaging that worked, and the information
always exists but doesn't root back into how you design that
next campaign in a systematic way.
And a lot of the time, that's because you take insight, you
take data and then you draw insights from it to shape your
next things or your next ideas. But for agents, that doesn't
work because an agent is not a human and you can't trust it in
the same way. It's fallible.
Whereas a closed loop system is a process where the outcome of
every single decision roots back into a structured database
really, so that an agent can pick up that decision and make
subsequent decisions automatically.
Again, you're scaling intelligence.
A good example of this is what we're building with mindset,
which is called Memex. Essentially, you plan work in a
document. That document has all the why
and the how this is going to be delivered, which creates a set
of decisions to make. Humans and agents make those
decisions, and then suddenly all of that is split into tasks.
You then assign that to all the agents and people and they go
off and deliver that work. Every single piece of task and
item within that task that's delivered by a human or an agent
is automatically updated into that task.
So it's literally constantly scaling all the decisions that
were made and as a result, every agent or person that picks up
from that next, say, task or project or whatever it might be
in the future has access to all decisions at scale.
You don't need to provide a context.
You don't need to worry if this is going to do the wrong thing
because it has access to those decisions.
As a result, you can suddenly run at scale AI systems that can
take huge decisions and actions because it has such amazing
context. That's a closed loop system.
So as an action for you this week, pick a process and then
close it. What's the most repetitive task?
What's the AI process or human process and where is that
getting locked? You could take an MD structure
format like we talked about last week that can work.
That has some problems at scale. You have what we call decision
drift, where not every decision gets logged in the proper way.
So the agent of the human misses key context and decisions.
But it's a good start. If you have called Co work,
describe the process, ask it to design what a closed loop system
would look like, where it gets measured, where the output goes,
where the next agent picks up from.
So when you think about this, think about asking the agent to
create closed loop systems, and then every agent or system or
scheduled task that you create should then read from that
place. So principle #3 is making your
company fully queriable. So think about what happens in
most companies when, say, someone new joins at a senior
level. They spend months in meetings
talking to people, getting chucked into things.
So they get to grips with everything.
They have to understand what decisions have been made.
They have to figure out institutional knowledge.
It's not indexed anywhere. It cannot be queried easily.
They just have to ask people all the time.
This is what Hugh calls an Inquiry Able Company, and it
describes most organizations that existed before 2024.
So what this means in practice, for example, is instead of
emailing A colleague to ask why a decision was made six months
ago or last week, you just open a search interface and ask it
and you get all the information, the context, the emails,
everything instantly. A good example of this is we
have a system for managing every project and plan and code that
was written at the moment. It was in an It was initially in
an MD file structure that was very advanced, but we've now
moved out to Memex. Every decision, every
information, it's all stored in there.
So it's instantly queryable from a product delivery perspective
and team members in the product process can query and out.
When a developer goes, OK, I want to deliver any project,
they don't have to ask anyone about architecture or decisions
or projects from a week, six weeks, a month ago.
They literally just go to that system and start making it from
there. Many companies have already, you
know, started doing this. They've got AI note taking,
Notion for say documentation, Slack instead of e-mail.
But that's all very basic stuff. And This is why I think one of
the most important spaces, and I'm not just saying this because
this is what Memex does a lot of the time as a company that's
I'll probably describe at the forefront of a lot of these new
changes. We spot things that are really,
really important quite early. And in the next 1218 months, the
most important things is going to be a decision layer, A
decision register, not a meeting summary that has loads of
unstructured text and information, An actual organized
database of every decision that was made, connected to each
project and person that delivered it, and importantly,
every agent. Because again, the the new
paradigm here is that you no longer design processes and
systems for human to human collaboration.
It's all about agent to agent to human collaboration.
Humans are a coordinator now, not just doers.
So as an action, think about where decisions are getting
logged. Think about how you can make
everything queryable so you can always say to somebody who asks
a question, have you asked X system?
So then the culture internally should be 1 of initiative.
Because once you remove those barriers, in my opinion, you
also remove excuses. So you encourage and enforce
people to take initiative and go and make decisions.
So principle #4 is the idea of 1000 X team member, engineer,
employee and what that means for how you know, hire.
So you know, for software companies, we'll just take the
engineer as the first example. Software companies for 30 years
operated in a band of roughly 200,000 to $400,000 of revenue
per employee. And that range is held
throughout most of the package software era.
So when you buy a perpetual license for 12 months all the
way through SAS through to mobile, it was a bit of a
structural ceiling on what a person plus a computer could
actually just produce. But that ceiling is now well and
truly gone. You know, Cursor, the AI coding
tool, hit $2 billion of revenue and generates $6.1 million per
employee. So that historical benchmark is,
is is gone. It's 20 times the traditional
revenue per employee ceiling that we used to have.
And these aren't productivity improvements, they are a
different level of output per person and function.
And that thousand X team member employee engineer concept
therefore actually means one person doing what used to take
an entire team. I'll give you a good example.
We for this product launch built an internal Twitter tool,
created a research report that scanned over 20,000 public
GitHub repos. So loads of different public
repos for code to analyse the drift between the MD file
structure and what's actually being written in code to bring
to life what we see is this big problem of decisions getting
made by agents but not updating your rule set for agents.
Using the tools, we then create an entire strategy, a content
strategy based on real Twitter conversations that were
happening in vocabulary and language to make it super
applicable to people and really understand the problem set.
We then created and set up MCPS into Google, into Google
Analytics and Google Ads and to run experiments on our
proposition. So what is the best way of
describing this product and problem set that resonates to
people? And we did it all from just
talking to AI and setting up MCP servers.
And then we pull in automatic reporting from different places
into reports and models, which create new insights, which
creates a new document as an MD doc, which we send straight to
our AI coding. So core code in in our MIDE
which spins up a new landing page to test new hypotheses.
All of this, all of this was done by literally probably the
equivalent of 1 1/2 persons working part time.
That would have been probably months of work.
And we literally were doing that in literally over a bank holiday
weekend. So the level of pace change and
things you can achieve is insane.
I think the hiring implication here is quite uncomfortable
because most hiring today still uses some version of challenges
or basic questions. If you take the engineers,
you're given a challenge. So write this function, debug
something, build this feature in a few hours, and then you test
it. But in a world where agents do
all of this, do the execution, you're screening for the wrong
thing. The skill that matters now is AI
management is being able to precisely describe what should
be done for you. Can this person define what good
enough looks like? Can they have the taste and
judgement to make decisions? Do they have the initiative to
get an idea and execute and move forward?
Can they take the output and verify whether that was done
properly and have the judgement to decide what to do next?
These skills are hard to test for, but the interview doesn't
have to be complicated. Instead of these challenges or
basic questions, give people a, let's say, a product brief and
ask them to write a specification.
Not to build anything, but to define what it should do, what
edge cases it needs to handle, the process that you're going to
go through and then see what happens.
Just because someone's a really good person in their job doesn't
mean they're going to be a fantastic candidate in this new
AI first world. And it's why education needs to
rapidly change. The way we teach people to think
about the world needs to change fast.
So yeah, next time you go for hiring, think about how you can
attract the right person and actually learn whether the right
candidate through a different type of process principle #5 is
token Max, not headcount Max. Now, again, I covered this in a
recent episode. I, I have mixed feelings with
this. I, I mentioned it a lot, so I'm
not going to go into it, but it was a really popular episode.
I recommend you go listen to it. But the principle that they were
talking about is that most companies are still treating
inference. So spending on tokens, which is
what happens when you produce words through a language model,
is essentially constrained. Like finance saying we don't
want to spend too much here. We have to approve tickets to
increase spend per person, which basically means that if you want
to run many agents across many larger data sets and bigger
tasks, you're going to burn through lots of tokens and spend
a lot. And finance is constraining
that. And the principle here from this
book, which as I said, I land in a bit of a mixed feeling here,
is just to burn as many tokens as humanly possible, not get
more headcount. And if according to Y
Combinator, if that doesn't make the CFOA little bit
uncomfortable, they're probably not pushing it far enough.
Now, I do think this encourages the wrong behaviours and you
need to be teaching people how to be efficient with token spend
and context usage when using AI. But if you're trying to get the
team to really start adopting this, it can be a good place to
start just to get people widely using it and then teach them how
to be more efficient. So as an action, maybe whole the
last three months of AI tool spend across all the different
subscriptions, use core Co work to paste it alongside your
headcount and ask it to calculate current spend per
person per month on AI and then judge whether that's high
enough. Take that into the next finance
conversation and reframe it as maybe not increasing overhead of
new people, but actually increasing spend.
The goal really here is simple. It's not about cutting headcount
here in my view, it's about getting people to stop asking
permission to use AI and just to start using it.
Principle number six is the idea of software factories.
So most teams today still work in the same way as they did in
2015. A ticket arrives, a person picks
it up. So in your project management
tool or in Jira or whatever it might be, an engineer or a team
member picks it up. The write code or they do the
task, they put it in review state to wait for somebody to
look at it, and then it ships. AI is, you know, in a sidebar
helping with certain parts of that, but the process is broadly
unchanged. Now, what Hugh described is
something very different. A-Team that does not write code
at all, that does not perform the tasks themselves at all.
Mindset's been like this for quite a long time.
Almost no code is really written by humans anymore.
We really care about decision making though, and planning and
thinking about what the AI produces, because otherwise
you're just vibe coding crap. So it's not about not caring
about the input or the output, but it's trying to no longer
constrain people to having to do the work themselves.
Now, Dan Shapiro built a taxonomy basically of AI
assistant coding, and the term comes from manufacturing.
So a facility where robots work in complete darkness because
they don't need to see. And a good example here is the
code compiles in the dark and humans just show up to maintain
the specification, verify the output and decide what comes
next. So if people think their job is
now writing the thing, coding the thing, this new thinking
tells them that their job definition is about telling
something what to do, making sure it makes the right
decisions, and verifying the output.
So precise specification is now a skill that's critical, and as
a result, therefore you need specifications that are
versioned and maintained like Coach used to be.
If the spec changes, you should be able to see the differential.
And again, this is exactly what Memex is solving for.
If someone amends a test scenario, there should be a
record of why. If the agent made a decision
that impacts the plan, it should have recorded why.
Principle 7. This is the intelligence layer
replaces the organizational chart.
So most people, when they hear middle management is going to
disappear, they think it's about cutting costs.
Well, it it just isn't. This principle is actually about
the specific job of a middle manager, which if you watch
carefully, is mostly rooting what a senior leader or leader
of a company wants to the right person, or aggregating statuses
from teams relaying contacts to, you know, people above them.
Passing the decisions back down in the right way, making sure
the left hand knows what the right hand is doing.
Basically them having the right judgement of what to do or what
to build when things go wrong. Well, that is now a much smaller
fraction of the role than the title actually implies.
Now what the intelligence layer replaces is the routing, not the
judgement. When every person in the company
can query the same set of information, see the same
decisions, understand the same context without a human having
to pass that information along well, therefore the layers that
exist only to pass information and just not important and
therefore the organizational chart now is no longer the same.
It was previously a workaround for the fact that information
couldn't really travel at scale. A good example here is now we
have MCP service for all of our primary systems, for sales
engineering, for product, for customer service, and every
single one of those accessed by every leader in the company.
You can get a scheduled daily report of everything that
happened automatically. So therefore, why would I go and
ask a middle management about what happened, about progress,
about performance? I don't need that.
As a result, the people who are now middle management are about
deciding what the most important actions are to take, aligning
the teams and their agents to take them, and making sure that
thing happens on time. So as a result, in many ways the
org chart flattens and I think leadership becomes about
supporting people and getting them to think about the right
ideas and the right decisions to make, not just passing
information along the process. 7 principles are extremely
concrete, really interesting by general partners who work with
all of the most exciting AI start-ups in the world.
And two months earlier, Jack Dorsey had run most of these at
his company block, and actually cut 40% of his workforce in the
process. So there are the seven
principles and I think it's it's a good time to conclude and I'm
going to conclude with a few different actions I think you
should do. You don't need to implement them
all at once, but I think you can start by a running three
questions to test the team. What is the minimum number of
people to keep this service running at full capacity?
What is the minimum to stay compliant and secure and what is
the minimum to grow and meet your commitments?
The first two give you the floor and the third gives you the
ceiling. For this stage, most leaders
will know how many people work in their company or teams, but
very few calculate the floor. This isn't supposed to be a
redundancy exercise. It's supposed to be an audit of
the structure moving forward and the number that comes back.
I think will tell you more about how the organization runs today
more than anything else you can do in a single week.
Second, set a visible AI budget and just remove the approval
friction. Pull what people spend at the
moment per person per month on AI tools.
Open clock Co work. Paste it in alongside the
headcount and ask it to benchmark against what the
leading companies are spending. Set a team budget higher than
your current spend, but then work with them to make sure
they're efficiently spending. Make sure that people just don't
ask permission #3 close a loop on one of the most important
repetitive tasks. Pick a task that someone on your
team does all the time in the same way and use cloud Co work
to design what a closed loop system looks like for that task.
What gets measured, where the output goes, what changes next
time, what the next agent process will read from.
So is it going to be connected to that same decision layer?
And then measure quality of outcomes from day one, not just,
you know, how fast it runs and #4 run a software factory
pattern on at least one internal process.
So something that touches no customers and no live system.
Just get a person to write the spec, One person writes the
criteria for success. And get core code or core Co
work or whatever it might be to just do the work.
Review the specification when the output is wrong, not just
the output itself. And then get it to the log its
decisions in a structured way, whether it's an MD file
structure, whether it's pushing it into a spreadsheet.
So yeah, there are the four things I think you need to start
now. This is a 6-7 week project, you
can really transform your team and organization as a result.
And really I think many of these principles, although quite scary
for the future of employment quite frankly, and the fact that
we really need to push for change for education and
opportunities, for apprenticeships and pre
employment training. But I think this is how
organisations are going to run in the future.
Anyway, I hope you find that interesting.
Thank you for listening and I'll see you next week.