Why conditionals are worth understanding

Last time, I wrote a short guide on loops for people who don’t write code but increasingly need to understand what it's doing. My anti-slop cheat sheet. Because I believe that even if you don’t code, or if you now code less, the inherent logic behind code is still important to understand. It’s how computers communicate with humans after all. Sure, AI talks to us in natural language (and a lot of us would argue, it uses too many words). But it reasons and acts in code, and then in binary (but we don’t need to go that deep).

And I think if we get too far from the nature of how technology communicates and reasons, we’ll outsource all our critical thinking to the machines that run our lives.

So this is my challenge to you. In your next prototype or project, in that next dashboard you decided to vibe code for your manager, look for loops, and look for conditionals. And ask yourself what they’re doing. Then ask your AI agent, and see if the logic lines up with the output you’re actually looking for.

This is the new kind of literacy. It might seem toilsome in the moment because you’re learning something new (or you’re practicing something old from a new angle), but like a chess grandmaster that put in hours of practice to recognize and anticipate shapes and patterns on the board, once you can spot those shapes inside blocks of code, you’ll start noticing them everywhere rules get made and logic is needed. A policy document, a set of hiring criteria, a pricing tier, an argument someone’s making in a meeting.

So the goal here isn’t code literacy for its own sake. It’s recognizing the shape of a decision clearly enough to sanity-check it and think critically about it.

Are you ready? Let’s dive in.

What’s in a conditional

If loops are about repetition, then conditionals are about decisions. They’re the part of the code that says “it depends” and then spells out exactly what it depends on. They’re an instruction that says: check if something is true, and do a different thing depending on the answer.

The reason conditionals exist in code is the same reason they exist in real life: you constantly make decisions based on circumstances, not on a fixed script.

A real-life conditional you already run

If it’s raining, bring an umbrella. Otherwise, wear sunglasses.

That’s exactly what a conditional does in code. It has:

• A condition to check (is it raining?)

• An action for when it’s true (bring the umbrella)

• An action for when it’s false (wear sunglasses)

How to read a conditional when you see one

You don’t need to understand every symbol, but make sure you ask four questions:

1. What’s the condition being checked? (A value? A comparison? Multiple things at once?)

2. What happens if it’s true?

3. What happens if it’s false, or if there are other cases in between?

4. What order are the conditions checked in?

If you can answer those four questions, you understand the conditional, and you can start seeing what decision it’s actually making inside the larger system.

The three core patterns

Almost every conditional you’ll encounter in the real world is a version of these three (high-level) patterns.

Pattern 1: the simple if (”do this, only if”)

The most basic version. One condition, one action. If the condition isn’t met, nothing happens.

The idea

If an order is over $100, apply free shipping.

In Python

if order_total > 100:
    apply_free_shipping()

In JavaScript

if (orderTotal > 100) {
  applyFreeShipping();
}

In Ruby

if order_total > 100
  apply_free_shipping
end

In SQL

UPDATE orders SET free_shipping = TRUE WHERE order_total > 100;

What to notice

• There’s a condition, and there’s an action that only fires when it’s met.

• If the condition is false, the code simply moves on.

• SQL hides the “if” inside a WHERE clause rather than spelling it out as a separate step.

Pattern 2: if / else (”do this, otherwise do that”)

This pattern guarantees one of two outcomes always happens. Nothing falls through the cracks.

The idea

If a customer is a returning customer, show them their saved cart. Otherwise, show them a new one.

In Python

if is_returning_customer:
    show_saved_cart()
else:
    show_new_cart()

In JavaScript

if (isReturningCustomer) {
  showSavedCart();
} else {
  showNewCart();
}

In Ruby

if is_returning_customer
  show_saved_cart
else
  show_new_cart
end

In SQL

SELECT CASE
  WHEN is_returning_customer THEN 'saved_cart'
  ELSE 'new_cart'
END AS cart_type
FROM customers;

What to notice

• Every customer lands somewhere. There’s no third option, no gap.

• This is the pattern to look for whenever you need certainty that something happens no matter what the input looks like.

• SQL’s CASE statement is doing the same job as if/else, just written as an expression (when) instead of a block.

Pattern 3: the chain (”check these, in order, until one fits”)

Sometimes there are more than two possible outcomes. This pattern checks conditions one at a time, top to bottom, and stops at the first one that’s true.

The idea

If a support ticket is urgent, route it to the on-call agent. Otherwise if it’s a billing issue, route it to billing. Otherwise, route it to the general queue.

In Python

if ticket.is_urgent:
    route_to_oncall()
elif ticket.category == "billing":
    route_to_billing()
else:
    route_to_general_queue()

In JavaScript

if (ticket.isUrgent) {
  routeToOncall();
} else if (ticket.category === "billing") {
  routeToBilling();
} else {
  routeToGeneralQueue();
}

In Ruby

if ticket.urgent?
  route_to_oncall
elsif ticket.category == "billing"
  route_to_billing
else
  route_to_general_queue
end

In SQL

SELECT CASE
  WHEN is_urgent THEN 'oncall'
  WHEN category = 'billing' THEN 'billing'
  ELSE 'general_queue'
END AS routed_to
FROM tickets;

What to notice

• Order matters here in a way it didn’t in the first two patterns. If a ticket is both urgent and a billing issue, it goes to on-call, because that condition is checked first. Swap the order, and the same ticket goes to billing instead.

• This is the pattern behind most routing logic, tiered pricing, and eligibility rules (anywhere there are more than two buckets something can fall into).

• One thing to watch for: a chain with no final ‘else’ can leave a case with nowhere to go. If none of the conditions match and there’s no catch-all, the code may do nothing at all.

A quick mental model to take away

Back to real life for a moment:

• The simple if is you grabbing an umbrella only if it’s raining, and doing nothing different otherwise.

• The if/else is you always leaving the house dressed for something. You’re prepared with rain gear or sunglasses, one or the other, but never neither.

• The chain is you checking, in order: is it raining? If yes, grab the umbrella. Is it cold? If yes, grab a coat. On a day that’s both rainy and cold, checking rain first means you walk out with just the umbrella, no coat. Swap the order, and that same day gets you a coat with no umbrella. Either way, you only ever end up with one item, because a chain stops at the first match.

• If you actually wanted both the umbrella and the coat on a day that’s rainy and cold, you’d need two separate, independent checks instead of a chain:“if it’s raining, grab the umbrella” and, separately, “if it’s cold, grab the coat.” Each one fires on its own, so nothing has to lose to the other, and the order you check them in stops mattering.

Loops repeat. Conditionals decide. Put them together, and you’ve got most of what code is actually doing, day to day. Not so bad, is it? Now go learn those patterns. Happy thinking!

I took pride in my ability to test the edges of complexity. And I never missed an opportunity to show that I had done my homework, and spent precious minutes in meetings explaining how I got to a recommendation, thinking this would earn more trust with my stakeholders. “She knows what she’s talking about”.

But leading with complexity constantly backfired. People got lost along the way. They didn’t trust me more, because they didn’t understand what I was trying to solve or why they should care. With some trial and error (ok, a lot of trial and error), my relationship to simplicity evolved. In this essay, I want to share with you what I learned in my journey: both complexity and simplicity play a role in the process of discovery. Understand the intricacies first, then solve and communicate with simplicity. Let’s dive in.

What is complexity

A complex system1 is the product of hundreds (or thousands or millions or trillions) of interactions among simple, interconnected components. You can spot a complex system by looking for these five things:

• Layered structure. Simple parts combine into stable units that become the parts of something larger. Bases build genes, genes build cells, cells build tissue. Complexity stacks in levels rather than sprawling flat.

• Emergence. The system produces behavior no single part contains. No neuron holds a thought; the thought appears only in the firing between millions of them.

• Interdependence. The parts respond to each other, so you can’t understand one in isolation. A single price in a market means nothing until you see what every other buyer and seller is doing in relation to it.

• Nonlinearity. Effects aren’t proportional to causes. One severed power line can black out a whole grid, while adding a dozen new lines might change nothing.

• Self-organization. Order arrives from the bottom up, in a spontaneous manner. A trend goes viral because people are sharing, and a coordinated wave forms out of local copying.

Because the rules governing individual components are simple and few, complex systems are actually generated by far less than we might initially think. The clearest case is genetic code. Every living thing is built from sequences of just four bases, and each base follows an almost trivial rule about which other base it pairs with. The entire diversity of life comes down to how many simple-ruled parts interact, not to any part being intricate in and of itself.

Why complexity exists

But why do all these self-contained, simple components generate so much complexity when they interact? Why is it needed? Wouldn’t the world be better if things were simpler?

When the environment is stable and predictable, a fixed, simple system is enough. It can meet every situation with the same small set of responses, because the situations barely change. But when the environment is varied and keeps shifting (which is arguably, the world we live in), a fixed system gets overrun.

Complexity is survival. It allows the system to carry enough range to meet a world that keeps producing situations it hasn't seen before. Which means simplifying can never be about deleting complexity entirely. We need it, to some extent.

So what is simplifying, and why is it useful?

Why simplifying is powerful

Remember that complexity emerges from simple local rules. Genetics, ant colonies, markets. The greatest thinkers are people who are able to reverse engineer complexity back to its simple parts. They look at complex, tangled situations and ask: what is the small set of simple rules or mechanisms actually generating all this? They find the core.

That’s powerful, because the ability to simplify a complex system is what lets you act decisively, get others to follow, and spend your effort where it actually matters, without getting stuck in the mess. It breaks down into four advantages:

Simplicity as leverage

Complex systems are nonlinear, and in a nonlinear system, you can’t enumerate and control all the interactions, because there are too many. And they cascade. The move is to find leverage points: the few places that are meaningful to describing the whole system. That’s elegant, and the difference between spending effort proportional to the mess, versus spending it proportional to the cause.

Simplicity as building blocks

Recombining simple, stable parts is a central mechanism of how complex systems get built in the first place. A clean, simple solution can enter that same process: it becomes a building block others build on, and it compounds across the whole system, while a complex, special-cased solution is a dead end.

Simplicity as a smaller surface of failure

Every bit of unnecessary complexity is surface area for emergent failure. Ten interacting components have 45 possible pairwise interactions, twenty have 190. Each added part interacts with all the others in ways you didn’t design and can’t predict. Simplifying shrinks the interaction space, which shrinks the space for emergent bugs, side effects, and unintended consequences.

Simplicity as mental modeling

A person who simplifies well is building a good mental model of the system. The naive simple answer (without understanding) is just ignorance. The elegant simple answer (after understanding) is mastery. They can look similar, which is why elegant simple solutions often seem obvious in retrospect. But whoever holds the best model can predict, act, and explain it, while others can get paralyzed by the full mess.

A quick take away

Complexity isn’t going away. If anything, the world is becoming more unpredictable, more information is coming at us, and our ability to reason about it is shrinking. Because everything moves so fast, processing complexity and simplifying is one of the greatest superpowers you can build. Here’s a quick recipe:

• Find the core. Ask what one subset of rules, if you understood only that, would let you work out what the system is about. Finding it tells you what’s worth your time, money, and attention, and what is just noise you can safely ignore. It lets you put more effort on the parts that carry the system, versus evenly across the mess.

• Cut without ego. Understand the complexity first. If you skip that part, your simplification will be naive. Once you understand enough though, and are ready to explain it to others, cut everything that’s there to show your work rather than move the goal forward, like the extra context that proves how much you know, or the caveat that shows you thought of everything. If it doesn’t serve the core, it goes. This makes it a lot cleaner for other people and gets to the point of why they should care.

• Test by reversal. A good simplification survives someone asking “wait, why?”. You can go one layer deeper on demand, because you took time to understand the details before simplifying. This is how you know your simple version is real and not a guess. The reversal test is your own check that you actually understand the system.

• Don’t oversimplify. Cut the complexity that’s noisy, but keep the meaningful complexity the core of problem itself contains. Simplifying doesn’t mean simple for simplicity’s sake. If you remove meaningful complexity, you won’t get a simpler answer, you’ll get a wrong one that sounds clean and confident, and you’ll act on it and invest in it, only find out it was hollow when it breaks. As Einstein put it, as simple as possible, but no simpler.

Start with one thing this week. Maybe the most tangled problem on your plate. Don't explain it better. Find what's generating it, and cut everything else. See what happens.

Subscribe now

What’s an organization?

What is an organization? For most of us, they’re a given. They’re part of a modern society and central to how we interact and navigate the world. We’ve grown up with our parents, family, or friends working in one. We’ve experienced them as consumers of products, goods, and entertainment. And for some of us, we’ve even worked at one (or many).

But what is an organization really? That question is complex because organizations are complex. They are the product of a web of interactions between people, systems, and missions. They have layers of coordination and hierarchies mixed with rewards and incentives, so that what gets produced is useful, profitable, and in some cases, innovative.

Since the mid 20th century, the field of organizational design has been tasked with optimizing org ‘blueprints’ so that all the parts work together, coherently, to reach a specific goal. In a nutshell, how do you get a group of people with different knowledge, interests, and capabilities to produce something together that none of them could alone?

That question is as relevant now as it ever was. Maybe even more so. And AI is changing the conditions under which we try to answer it, because it’s accelerating individual output, and making some coordination mechanisms redundant overnight.

Back to the future

There’s a lot of noise right now about what AI means for how we organize and work, so I’m going to do what I always do when things get complicated: deconstruct concepts back to their core parts. And focus on a few components at a time (don’t try to boil the ocean, as they say).

In this essay, I’ll be looking back at how organizations evolved across various eras to better understand two core components:

• How knowledge moved between people

• How effort was coordinated

From there, I'll put my designer hat on and start to sketch what a better blueprint might actually look like for the era we're transitioning into.1

Era 1: the guild

~Before 1850

Before industrialization, the dominant organizational form was the guild. A community of master craftspeople, journeymen, and apprentices organized around a trade. The coordination mechanism was proximity and transmitted knowledge: you learned by being close to someone who already knew the craft.

Example: A medieval goldsmith's apprenticeship lasted seven years, working beside someone who already knew the craft on real commissions. Mistakes were visible immediately and had to be corrected in the next piece. The craft transferred through proximity and consequence, not documentation. The workshop was the coordination mechanism. There were no managers.

What it rewarded: craft mastery, years of apprenticeship, reputation within a trade community.

Who thrived: deep craft specialists with long time horizons and strong guild membership.

What broke it: the industrial revolution changed the unit of analysis from the individual craftsperson to the coordinated system. Leverage was now scale rather than depth of craft.

Era 2: the machine

~1850–1940

The dominant form was the factory and the bureaucracy. Work was decomposed into its smallest possible tasks, each measured and optimized independently. The coordination mechanism was hierarchy and standardization: managers planned, workers executed, and rules governed every point of contact between them. The machine did the coordinating. The worker did one thing.

Example: Ford’s moving assembly line at Highland Park brought a Model T from 12.5 hours to 93 minutes. Taylor’s experiments at Bethlehem Steel nearly quadrupled pig iron output by prescribing the one best method for every motion.2

What it rewarded: efficiency, output per unit of time, procedural compliance.

Who thrived: the reliable executor who could master a decomposed task, the procedurally correct administrator.

What broke it: knowledge work. You couldn’t decompose thinking and judgement into subtasks.

Era 3: human relations

~1930–1960

What was being built had become too complex for pure task decomposition. Aircraft, telephone exchanges, consumer appliances. These required engineers talking to designers talking to production workers. Judgment was needed at every interface, and so were workers who understood enough of the whole to make good local decisions. The coordination mechanism became management attention and group norms: get the best from people by treating the worker as a social being whose judgment is part of the system.

Example: HP was built on the theory that engineers' best work came from understanding what they were building and why, not from following prescribed methods. Hewlett and Packard walked the factory floor daily, talking directly to engineers about their work to understand and unblock. Decisions about how to solve a problem were pushed to whoever was closest to it.

What it rewarded: morale, cohesion, loyalty, the ability to inspire people.

Who thrived: the good manager who could read the room, the team player who contributed judgment not just compliance.

What broke it: the absence of a structural theory. Knowing workers have intrinsic motivation doesn’t tell you how to design the system around them. The human relations school was excellent at describing the person and largely silent on the organization itself.

Era 4: the adhocracy

~1960–1980

The Cold War and the pace of technological change meant organizations were being asked to build things nobody had built before, against problems that couldn’t be anticipated. On top of that, the professional expert class had arrived at scale. Organizations were full of people whose expertise exceeded their managers’ comprehension. The coordination mechanism was meant to adapt to this changing context quickly: match the org structure to what the environment demanded at the time, and let authority follow expertise rather than title.

Example: Bell Labs ran an organic structure. No one prescribed the collaboration. The structure assumed people would find each other when necessary. The result: the transistor, UNIX, and nine Nobel Prizes. NASA's Apollo program needed a way to coordinate interdependent problems across 400,000 people. The answer was a matrix. Engineers reported both to a functional department head, who maintained technical standards across the organization, and to a project manager, who was accountable for a specific mission component.

What it rewarded: matching structure to context, expertise-based authority, lateral coordination.

Who thrived: rapid innovators and people that work best in non-formal, problem-based environments.

What broke it: the leading organizational frame moving from “what structure fits your context” to “what strategy are you pursuing and how do you measure performance against it.” Objectives and competitive positioning became the primary lever.

Era 5: the performance model

~1980+

The shift was driven by converging pressures. Capital markets gained power over management decisions. Institutional investors, hostile takeovers, and shareholder primacy meant organizations now answered to quarterly returns in ways they hadn’t before. Strategy replaced structure as the primary management lever. Work was governed by objectives, reviewed against outcomes, and rewarded through credentials and rank.

Example: GE’s vitality curve under Welch divided every employee into top 20%, mid 70%, and bottom 10%. The bottom was fired annually, and the market cap moved from $12 to $410 billion.

What it rewards: measurable output, credentials, rank relative to peers, visible achievement.

Who thrives: the credentialed achiever, the ambitious strategist, the person whose contribution fits cleanly into a performance review.

What breaks: the management layer that coordinates the model can also be the bottleneck. As digital tools routed information faster than human managers can, the layer that translated between strategy and execution became expensive and slow.

Era 6: the startup model

~2010+

Software demonstrated that small autonomous teams could build products of extraordinary value. This winner-take-all economics meant speed to market mattered more than coordinated efficiency. The dominant form was the attempt to remove hierarchy and replace it with culture, shared purpose, and self-management.

Example: At Buurtzorg, 14,700 nurses were organized in self-managing teams of twelve. It had 8% overhead costs versus a 25% industry average because each team was small, bounded to one neighborhood, with a purpose specific enough that mutual adjustment could handle all coordination.

What it rewards: autonomy, self-direction, the ability to manage yourself without oversight.

Who thrives: the highly autonomous, psychologically robust generalist.

What breaks: scale and the friction of doing coordination work without coordination mechanisms. Removing hierarchy without replacing what it coordinated.

The new blueprint: knowledge transfer and coordination

The only mechanism that reliably transfers tacit knowledge is exposure to other people’s reasoning, and tight feedback loops. Knowledge integrates from retrieval in context, by encountering the right piece of reasoning at the moment it needs to be applied. I think the guild did this best, through prolonged exposure to the master.

But with the flow of information picking up exponential speed, the gap between what an expert does and what they can articulate is becoming increasingly difficult to close. That’s why other eras didn’t succeed in integrating the guild effect, and also why now is the best time to solve the problem of weaving it back in.

At the same time, the mechanism that enables coordination is shared visibility of work in progress, to the people who need to see it and make decisions about it. In the guild, you could see what the person next to you was making and where they were stuck. In the adhocracy, experts found each other because the problem required it, and the organic structure made those collisions possible. And the startup model had bounded scope: problem boundaries defined the limit of necessary coordination.

But AI is dismantling this. Every person’s AI context is siloed. One person with good AI tools can now produce what a small team used to. But those outputs don’t automatically cohere into something collective. They accumulate in separate contexts, produced by people who may be working on adjacent problems without knowing the other exists.

How do we solve these design challenges?

What’s interesting now is that when someone works through a real problem with AI, every step leaves a trail. That wasn’t true for post-guild eras. The first prompt reveals how they framed the problem. The edits to the output or the decision to stop and try something different show what the person thought was missing.

I think the new organizational blueprint needs to leverage this, and build AI knowledge transfer and coordination into the main infrastructure. It needs to be centralized and do three things.

First, every AI reasoning session produces a structured artifact automatically. This might look like a decision log based on what was tried, what was rejected and why, and where judgment was exercised at each fork. It should be automatically tagged by problem type, stored in a shared substrate, and require zero extra effort from the person who did the work.

Second, when anyone on the team (or adjacent teams working on similar problem types) faces a similar decision, the infrastructure should automatically deliver relevant reasoning when it needs to be applied. People shouldn’t have to go digging for it, and it shouldn’t be bound to current hierarchical structures. This person faced this exact fork three months ago. Here is how they reasoned through it and how it applies to your problem.

Third, reasoning is available in whatever format makes most sense to the task and to the person receiving the information. I’m thinking voice narration, visual decision maps or graphs, or annotated judgment calls. Text isn’t always the best, and I think people are becoming increasingly overloaded because they are reading too much information-dense text. Input formatted to match the context will increase the chances that knowledge is actually transferred and integrated successfully.

What the new blueprint needs to reward

Right now the AI transition rewards individual output, AI fluency, and speed of execution. The person who generates the most, fastest. That’s the current default.

But I think the org blueprint that gets this right will reward the quality of reasoning embedded in output, not the volume of output itself. Because the artifact stream makes reasoning visible and traceable, you can see for the first time whose thinking actually changed what others were building. Output that generates no downstream consequence looks different from output whose reasoning propagates through five subsequent decisions across adjacent teams.

Organizations that implement these structural changes will be best positioned to transfer relevant knowledge and coordinate information across all problem spaces, no matter where they sit in the org. And they will be able to see and reward the people who contribute most to this new structure.

From there, the next design decisions should follow naturally: which structural components are now redundant? What is the right team structure once knowledge transfer and coordination are solved? How is mission-aligned work determined? How is performance assessed? I’ll be exploring those questions soon, so make sure to check back in.

Subscribe now

Why this matters now

AI tools can now write, run, and explain code on your behalf. That’s useful. But it also means more and more people (think product managers, marketers, HR pros, analysts, ops leads) will see code as part of their work, review what AI has produced, or need to ask better questions about it.

You don’t need to write code to benefit from understanding it. You need to be able to read it the way you might read a contract, so that you can know (generally) what it’s doing and whether it’s accomplishing what you intended.

Why loops are worth understanding

Code has many sources of leverage. Algorithms determine how efficiently a problem gets solved. Data structures determine how information is organized and retrieved. System architecture determines how everything fits together at scale. Loops are one of the places where that leverage is easily visible, which makes them a good and fairly accessible pattern to learn (a lot started clicking for me once I understood loops).1

Understanding what the loop is iterating over, what it’s doing on each pass, and when it should stop gives you a concrete thing to check before running AI-generated code on real data.

What’s in a loop

A loop is just an instruction that says: do this thing repeatedly until a condition is met.

That’s it. But don’t mistake it with a fruit loop. That’s something else.

The reason loops exist in code is the same reason they exist in real life: you often need to do the same action many times, to many items.

A real-life loop you already run

For every item on my grocery list, check if it’s in the cart. If not, add it. Once I’ve checked everything, stop.

That’s exactly what a loop does in code. It has:

• A collection of things to work through (the grocery list)

• An action to take (check and add)

• A stopping condition (when all items are checked)

How to read a loop when you see one

You don’t need to understand every symbol, but make sure you ask four questions:

1. What is it looping over? (A list? A number range? A condition?)

2. What action is it taking on each pass? (Sending something? Calculating something? Filtering something?)

3. When does it stop? (When the list is exhausted? When a condition flips? After N times?)

4. Does the output go somewhere? (Is it saving to a database? Printing? Building a new list?)

If you can answer those four questions, you understand the loop and you can start seeing the role it plays within the larger system.

The three core patterns

There are dozens of variations, but almost every loop you’ll encounter in the real world is a version of these three patterns.

Pattern 1: the for loop (“do this for each item”)

This is the most common loop you’ll see. You have a list of things, and you want to do something to each one.

The idea

For every customer in our database, send them a welcome email.

In Python

customers = ["Alice", "Bob", "Camille"]

for customer in customers:
    send_email(customer)

In JavaScript

const customers = ["Alice", "Bob", "Camille"];

for (const customer of customers) {
  sendEmail(customer);
}

In Ruby

customers = ["Alice", "Bob", "Camille"]

customers.each do |customer|
  send_email(customer)
end

In SQL

UPDATE customers SET welcome_email_sent = TRUE;

What to notice

• All three say the same thing, just with slightly different syntax.

• There’s a list. There’s a name for each item as you move through it. There’s an action.

• The loop handles the repetition automatically. You don’t write sendEmail("Alice"), then sendEmail("Bob"), then sendEmail("Camille"). You write the action once and let the loop apply it to every item in the list that you defined at the top.

• For SQL, the pattern is implicit. Rather than writing “for each customer, do X”, you describe the action and SQL applies it to every matching row automatically.

This matters enormously at scale. The same code that sends 3 emails sends 3,000,000. You don’t change anything.

Pattern 2: the while loop (“keep doing this until something changes”)

This pattern runs as long as a condition remains true. You don’t necessarily need to know in advance how many times it will run.

The idea

While there are still support tickets in the queue, assign the next one to an available agent.

In Python

while tickets_in_queue > 0:
    assign_ticket_to_agent()

In JavaScript

while (ticketsInQueue > 0) {
  assignTicketToAgent();
}

In Ruby

while tickets_in_queue > 0
  assign_ticket_to_agent
end

In SQL

WHILE (SELECT COUNT(*) FROM tickets WHERE status = 'open') > 0
BEGIN
    EXEC assign_ticket_to_agent;
END

What to notice

• The loop doesn’t know when it will stop. That depends on the data. It keeps checking the condition (tickets_in_queue > 0) at the top of each cycle. Once that becomes false (the queue empties), it stops.

• This is the pattern behind many real-time systems like processing orders as they arrive, monitoring for alerts or refreshing a live dashboard.

• SQL does have an explicit WHILE loop in this example, but it lives inside a stored procedure (a block of logic saved directly in the database). The data engineer could make other implementation decisions but that’s beyond the scope of this essay.

One thing to watch for: If the stopping condition never becomes false, you get an infinite loop. The code runs forever and nothing else can happen. Yikes! Careful not to prompt your AI agent into one of these bad boys.

Pattern 3: the counted loop (“do this a specific number of times”)

Sometimes you don’t have a list, and you don’t have a changing condition. You just need something done exactly N number of times.

The idea

Send 5 reminder notifications over 5 days.

In Python

for i in range(5):
    send_reminder()

In JavaScript

for (let i = 0; i < 5; i++) {
  sendReminder();
}

In Ruby

5.times do
  send_reminder
end

What to notice

• Python and Ruby are more readable here.

• JavaScript’s version (let i = 0; i < 5; i++) is more complex at first glance. Don’t worry, the meaning is start at zero, keep going while less than five, add one each time. It runs exactly five times.

• In SQL, there’s no clean equivalent for running something exactly N times (and the SQL community would largely prefer you didn’t try). Databases are optimized to operate on entire sets of data at once, so the language is designed to discourage you from thinking row by row at all. Most loops should be outsourced to other languages instead.

What changes between languages

You may have noticed that the same idea looks different across Python, JavaScript, Ruby, and SQL. That’s a design decision in the language itself (if you’ve been reading my posts for a little while, you’ll know I never miss a moment to harp on about how everything is a design decision… and this is one of them). Different languages make different tradeoffs between readability, precision, and expressiveness.

For example, Python is very readable and closer to plain English. JavaScript is verbose but explicit. The way you write the code tells you exactly what the function is doing. Ruby prose is elegant and expressive. Poetry? Maybe. In SQL, code is declarative and set-based. The loop is usually hidden or not present.

But the concept of a loop is the same across all of them (generally speaking). What changes is the specific words, brackets, and punctuation the language uses. When AI generates code in any of these languages, it’s translating the same underlying logic into different syntax.

A quick mental model to take away

Let’s go back to the grocery list for a moment:

• The for loop is you working through the list top to bottom: for each item, check if it’s in the cart, add it if not. The list determines how many times it runs.

• The while loop is you realizing your partner is texting you their half of the list one thing at a time, and you don’t know how many items are on it. You keep going (check item, add item) while there’s still texts coming in. You don’t know when you’ll stop until you get there.

• The counted loop is you deciding you only have time for five items before you need to leave. You count as you go. After five, you stop, regardless of what’s left on the list.

Every loop in every language is some version of that.

Want to go deeper? The next concept worth learning alongside loops is conditionals. Those are the ‘if/else’ statements that often live inside loops and decide what to do with each item. Together, loops and conditionals cover a surprising amount of what code actually does.

I’m not going to cover these today but I might in the future. So check back in soon. In the meantime, happy thinking!

Subscribe now

I started writing in late May 2026 with a desire to share where I’m at in my own journey. Because I don’t live in one box. I thrive between worlds. And I believe that this is a superpower. One that I want to share with you.

That’s how Animacy was born. To define this unique intersection I find myself in: the psychology of what makes humans exceptional, applied to real people, teams and systems, through the lens of design and product building. The pursuit of becoming across all angles:

• Why do some people keep growing while others plateau, even with the same talent and opportunities?

• What makes certain people and teams exceptional, and how do we find them?

• How do the stories we construct about ourselves shape what we’re actually capable of?

• What does it mean to design for people when most of what drives them is invisible?

In today’s essay, I’m going to walk you through the mind map connecting Animacy’s core mission to what we’ve discovered and learned so far.

What is excellence?

My posts are all pointing to the same core. Strip away the domain. Strip away whether it’s an individual, a team, a system, or a prototype. The premise is the same:

Excellence = someone or something oriented toward a vision of what doesn’t exist yet, and striving to bring it to life.

To become excellent, the top performer works through the tension of a future self not yet reached. The organization moves towards a desired architecture not yet formed. The designer holds a preferred situation not yet built. The person in a challenge state is oriented toward finding out what they’re capable of. Mastery orientation is curiosity about an edge not yet reached.

Which means that the opposite of excellence isn’t complacency. It’s an over-rotation toward the past.

We snap back to our old behaviors when we try to change because our current patterns of self are predictable. A team defends what they already produce so they can keep doing the same thing that works. People build on inherited assumptions instead of first principles because if it already exists, no need to rethink it. This is unfortunately the default stance because it makes the world feel predictable, and that gives people an illusion of safety. I believe that every system, left alone, drifts back to this maximum probability.

Excellence is the conscious choice to orient the other way.

That’s the journey we’re on at Animacy. We’re outliers. Moving through the tension, away from the mean and toward a clearer vision of what is yet to be.

Subscribe now

What have we discovered so far?

1. Engagement: how people move through ambiguity

The people who perform well in undefined, fast-moving situations don’t hold a shape (expert, generalist, T-shaped). They have a signature of motion. Credentials measure the knowledge someone has accumulated. Motion reveals how someone behaves when there’s no structure, no clear direction, and no one asking them to step up.

Three patterns show up consistently. Some people compress ambiguity into something others can react to, and their sense of self isn’t riding on whether that thing is good. Others reframe problems through the quality of their questions, not the certainty of their answers. And some become gravitational centers. They add the kind of friction that organizes rather than destabilizes

. These people are not necessarily the loudest or most senior.

How to observe it

• When something feels stuck, ask yourself, who would move first if there were no meeting, no agenda, and no one asking?

• Who makes the imperfect thing before anyone’s agreed on what to make?

• Who reframes problems and gets teams to climb the right mountain?

• Whose presence makes the group feel organized and coherent?

Dive deeper

• What the org chart can’t see: The new physics of talent

• Built for ambiguity: are these the people the AI era needs?

• Computer simulation: the people that will succeed in the AI era

2. Meaning: getting energy from challenges

When there’s a challenge, two interpretations are always available: “this is hard because I’m becoming something. I’m getting closer to the vision I have in mind” or “this is hard because I shouldn’t be here.” Which one is driving a person, a team, a work culture tells you almost everything about their orientation toward the future.

One is self-referenced: are you better than you were? Are you closer to the edge of what you’re capable of? This mastery orientation tends to come from genuine curiosity about your own potential. Ego orientation is other-referenced: are you better than them? Did you win, did you place, did you look good in comparison? One leads to growth, the other to frustration, anxiety, and disengagement.

How to observe it

• Watch what happens in the first few minutes after something doesn’t work: does the person get curious about the problem, or do they start attributing blame?

• When they’re wrong or fail, do they tackle the problem again from different angles? Are they genuinely curious about how they can get better?

• Do they get more energized or defensive as the problem gets harder?

Dive deeper

• This is how top performers think

3. Design: ask before you build

Most things get built on inherited assumptions. What a product should do, how a team should be structured, what a process is for. But true design is the act of changing existing situations into preferred ones. Not continuously adding on to what already exists, just because it exists.

Go back to first principles and make your vision of the future more clear. From there, build the smallest thing that tests whether your assumptions are right. Not a prototype of the final product, but something that reveals how the pieces of the system actually interact. What you discover by tinkering from that framing is almost always different from what you assumed at the start. And it’s likely more simple too.

How to observe it

• What is this thing made of, at its most basic level?

• What does the person using it actually need? Not what they say they want, or how they’ve been using it in the past. But what they’re trying to do.

• What does success look like from their perspective, not yours?

• What actually stands between the current situation and the preferred one?

Dive deeper

• Designing a self-reflecting agent

• Computer simulation: the people that will succeed in the AI era

4. Growth: the pursuit of becoming

The people, teams, and systems that exude excellence all have this in common: their identity is tethered to a vivid vision of the future. For a person, that means the gap between who they are now and who they’re becoming stops feeling threatening and starts becoming fuel. For a team, it means the work is in service of something they’re building toward, not what they’ve always done.

This identity can get fragmented when external expectations get tangled with a system’s internal values. When this happens, a person can’t access what they know under pressure because the anxiety of having to live up to others’ expectations takes over. A team that stops thinking clearly when stakes go up, because they’re building from someone else’s definition of success. A product loses coherence because it was built to do everything for everyone, and ends up being useful for no one.

To prevent that fragmentation, identity has to widen to include additional possibilities. Not as a replacement for the original vision, but alongside it, so that the external threat occupies a much smaller part of identity. This makes the system more adaptable and resilient.

How to observe it

• Where is pressure highest right now? Is the person, team, or system under that pressure still oriented toward a clear vision of what it’s becoming, or trying to incorporate too many external expectations and assumptions?

• Can you describe the future state specifically enough that you'd recognize it if you arrived?

• What would you have to let go of to get to your desired state?

Dive deeper

• This is how top performers think

We’re just getting started

When I look at this map, I see the very beginning of an epic adventure. Each branch is a new land to discover, and each node is material to build from.

And through the act of writing (and reading), we now have language for each piece. And language is key. We can’t optimize for what we can’t see. And we can’t design for what we can’t name.

This month gave us clarity. Now pick up your bags, let’s keep thinking.

Subscribe now

Soccer to be exact. When I was in junior and high school, this sport was my whole life. I trained and trained and built the speed and skill that got me on a U18 travel team when I was 15 years old. I spent the winters playing in indoor leagues, the spring training in camps, and the summers traveling around a 5-hour radius from my house. It was everything to me, until it wasn’t.

I hit a breaking point where I just couldn’t take the pressure anymore. I was trying to keep my grades up to qualify for university scholarships, and I didn’t believe I’d be able to excel at school and play competitively. I didn’t believe it. So I stopped.

When I got to university, I kept thinking about how my performance and potential were just a fabrication of my own mind. I couldn’t shake it off. I had to understand what excellence was and test its edges. So I switched my major to psychology and started volunteering in a sports performance lab.

To this day, I’m still fascinated by the psychology of champions. By people that are not just top performers in their fields, but have redefined them over and over again.

I think we have a lot to learn from them. Not that they’re perfect, but because they are a template for us. A permission to go all in and be relentless in our pursuit of becoming.

What’s identity got to do with it

Before I break down the psychological components that elevate champions to a league of their own, I’m going to bring us way back to how identity forms and evolves for most people.

It’s from that foundation that I’ll break down the champion’s mind:

• vivid imagination of possible selves

• unwavering connection to that future self

• ability to get energy vs disengagement from the present-future self gap

• genuine curiosity towards becoming versus performing or being praised

• ability to create meaning from challenges and discomfort

I’ll also talk about what happens when that identity fragments. When people’s expectations, the pressure to succeed, sponsors, fans etc., starts to seep into who the champion believes they are, and how to overcome that part and get back to authenticity.

Then I’ll close it out with some takeaways. I’ll highlight what you can integrate into your own life, so that you can find more joy and meaning from the pursuit of becoming as well.

Subscribe now

We manipulate the world to match who we think we are

Identity is formed in early life. We learn about ourselves through experiences and the feedback we get from our environment and the people around us. With time, this feedback loop gets integrated into our subconscious and becomes our identity. Who we believe we are. The voice inside our head.

And our psyche goes through a lot of trouble to keep that belief intact. According to identity control theory, our identity becomes our standard. Our main reference point. When we get incoming feedback from the world, we compare it against that standard. When the feedback matches, nothing needs to change. But when it doesn’t, we feel an uncomfortable tension. And to make that tension go away, we actually try to bring the environment back into line with our standard, not vice versa.

That’s right, for most people, our goal is to manipulate the external world to match who we think we are. We will actively seek out relationships, environments, and activities that confirm our existing identity because it matches predictable patterns. It’s more comfortable. And that’s a safer bet than being faced with the unknown.

Of course, it’s also normal for people to want to change. We have will, and for many of us, a desire to grow.

Imagine all the possible…selves

Humans have the wonderful ability to imagine. And it turns out that in our imagination, we think about ourselves… a lot. Sometimes we think about past selves, or present selves. But it’s also common to imagine who we want to become in the future. Researchers call these possible selves.

Because the possible self is oriented toward a future that doesn’t exist yet, it produces a tension in the psyche and activates that identity loop I talked about earlier. But this time, the gap isn’t about resolving the tension between identity and the environment. It’s about resolving the tension between who a person thinks they are now, and who they desire to become in the future.

For most of us, we’re like an elastic band. We get inspired and use our imagination to stretch into a possible self that represents who we want to grow into. But our identity feedback loop uses our behaviors against us. Unconsciously too, which is even more frustrating. We act out of habit with our current self and the elastic snaps back. We continue in our comfortable, predictable pattern of self.

But growth is possible.

Use the tension for energy, or you’ll snap back

Enter Mental contrasting. It describes the cognitive process where a person deliberately holds the desired future in mind first, and then consciously confronts the present reality that stands between here and there.

But whether mental contrasting leads to new behaviors and then change, depends on what you expect. Our minds have a lot of power, don’t they?

If you have a high expectation of actually reaching the possible self, contrasting produces measurable energization. Increased effort, increased readiness to act, even physiological activation. But if your expectation is low, the same act of contrasting produces the opposite: disengagement. And that’s a motivation killer. Knock out. You snap back to your current self.

So if that possible self feels real and attainable, and you can hold that tension in your mind even when you current identity is yelling at you to stop, you might get energy and motivation to act, and to keep acting, until you’ve become that possible self. Until you have successfully manifested who you expect to become.

For most people, most of the time, imagining possible selves doesn’t lead to energization. It actually leads to disengagement and even indulgence. We enjoy the image of who we could become, without confronting what stands in the way to actually get there.

Champions are their future selves

I think champions are the opposite. They are masters at getting energy from that tension. And that battle happens fully in the mind.

“I admire the mental aspect of sport more than the physical aspect, because physical performance is much easier to practice than mental performance.” — Rafael Nadal

And I don’t think champions just imagine their possible selves doing causal, daily tasks either. Their possible selves are shattering the ceiling of what is possible in their sport. That takes imagination. Not just a little bit either, because most of the things they have to imagine haven’t happened yet, ever (think breaking multiple records or inventing new techniques). They have to believe in that unrealistic possibility so intensely that most people would feel delusional doing that.

"I always believe I can beat the best, achieve the best. I always see myself in the top position" — Serena Williams

So what gets champions to feel such a strong connection to their possible self? What gets them to sustain that connection through challenges, setbacks, and failures, when most of us would just snap back to our old self?

Well, I don’t think they’re just imaging future self. That self is part of their identity. They actually are that future person.

Psychologist Hal Hershfield’s research on future self-continuity gives this a measurable shape. His research found that people who perceived future self as less similar than them, with less detail, and less favorably described their future self how they’d describe a stranger.

And it’s what a lot of people experience. They imagine a possible self they’d like to become, but that image is dull, it doesn’t feel real, and there’s no connection there. So it doesn’t matter if they skip the gym today, they don’t really care what happens to that person six months down the line. They’re so far away. It’s much easier to snap back to old habits.

But champions stay tethered to the future. My collaborator Tim Pychyl and I extended this research and found that people who could imagine their future self more vividly, and who were able to feel empathy for them, actually felt more similar and connected to them. That self felt more real. More like a part of the person’s identity. And when that future person is you, it becomes much harder to let them down when things get tough. That’s true of champions.

"Every single day I wake up and commit myself to becoming a better player." — Mia Hamm

I become therefore I am

What’s even more interesting about champions’ minds is that even though they feel an intense connection to a possible self that is quite literally the best, that exudes peak performance and excellence, their current self doesn’t focus on the potential glory and praise that would come with elite achievements. They don’t indulge. They actually reject the exact label I’ve been sticking on them throughout this essay. They don’t see the final destination as: I am a champion. Their destination is about becoming the champion. And that reframe makes all the difference.

“I’m more of a competitor than a winner, to be honest... If I compete, I feel good.” — Rafael Nadal

Psychologists studying achievement motivation distinguish between two ways people define success for themselves. One is self-referenced: are you better than you were? Are you closer to the edge of what you’re capable of? This orientation tends to come from genuine curiosity about your own potential. Researchers call this mastery orientation, and it’s linked to better performance and more sustainable motivation.

“I feel an endless need to learn, to improve, to evolve, not only to please the coach and the fans, but also to feel satisfied with myself. It is my conviction that there are no limits to learning.” — Christiano Ronaldo

The other type of motivation is other-referenced: are you better than them? Did you win, did you place, did you look good in comparison? This is ego orientation, and when it dominates, a loss doesn’t just feel disappointing. It can lead to anxiety, frustration, and in some athletes, giving up on the sport altogether.

A future self anchored in curiosity about your own edges has permanent high expectancy, because curiosity doesn’t require winning to be satisfied, it just requires finding out what you’re capable of. That identity will keep you energized… forever.

“A successful competition for me is always going out there and putting 100 percent into whatever I’m doing. It’s not always winning.” — Simone Biles

But a future self anchored in glory depends on outcomes you can’t fully control, including what other people decide to think of you. It’s easy to lose yourself in that and forget why you’re putting yourself through all these challenges in the first place.

And challenges are a big part of it. It’s the toil that creates meaningful change. It might sound cheesy, but you truly can’t grow without it. And you certainly can’t make a champion.

Challenges fuel the fire, or put it out

Most (if not all) of peak performance is a product of the invisible, daily work that makes the vision real rather than aspirational. And nobody is watching that part. No one is cheering or spraying champagne. But it’s where change actually happens. You can’t skip it.

“The vision of a champion is bent over, drenched in sweat, at the point of exhaustion, when nobody else is looking.” — Mia Hamm

So how do champions keep showing up day in and day out without compromise? Well, I don’t think they just tolerate suffering, they actually find meaning inside it. At the level of the body, the same demanding situation can produce one of two physiological states. When the person believes they’re capable of meeting the challenge, feel in control of the outcome, and their orientation is toward approach (finding out what’s possible with curiosity) the body responds with a challenge state: increased cardiac output paired with decreased resistance in the blood vessels. A pattern that delivers blood more efficiently to muscle and brain.

“There have been a few players who are as naturally gifted as me, but they didn’t work as hard. I wake up every morning and I know that today I have to be better than yesterday.” — Christiano Ronaldo

When belief is low, or the orientation flips toward avoidance (not failing, not losing, not falling short) and the body produces a threat state instead: cardiac activation without that same drop in vascular resistance, meaning the same physical effort is now being fueled less efficiently.

This means that the same training session that would exhaust one person can actually energize another. And this isn’t about sleep, nutrition, or physiology (although those are also important variables).

This is all in the mind. What a person thinks and expects literally changes the body. So powerful.

At the level of meaning, a parallel split shows up in how difficulty gets interpreted once a person is already in the challenging situation. The same hard session, the same setback, the same plateau can be read in one of two ways. As confirmation: this is hard because it matters, because this is what becoming who I am is supposed to feel like. Or as disconfirmation: this is hard, and that probably means it isn’t going to work, maybe this isn’t for me.

When the vision fragments, it must widen

All this put together makes the champion. The possible self as core identity. The energy from the tension of not yet being that self. The curiosity in the process of becoming, not just winning or achieving. The meaning found in difficulty and challenges.

So far, I’ve described how a champion sees themselves and challenges from their own perspective. Their own hopes for who they’re becoming, not anyone else’s. They are in the driver’s seat. And that holds true for the most part.

But what I haven’t talked about yet are the standards that are set by the external world, and by significant others. Who coaches, fans, family, an entire sport’s expectations, believe a person should be. And with rising success, ‘Who I’m becoming’ and ‘who I’m not allowed to disappoint’ can start to get entangled. That’s when a bad performance or a loss is no longer just feedback for the self. It’s also a gap relative to an obligation.

Unfortunately these external expectations come with emotions like anxiety and fear, which are, by definition, the emotional signature of the threat state I described earlier: the one with low perceived control and an avoidance orientation. Because the relevant standard is now partly someone else’s to judge.

"Probably because I went through a lot of injuries, a lot of pressure, and arrived in a moment where, in some way, you are not able to handle all of this. Even if in my mind I was able to handle all of this. It arrived at a point where your mind fails, and that's what happened." — Rafael Nadal

What happens to the body under that signature is mysterious. When you’re an elite performer, skills become fast, automatic, and run mostly unconsciously. The performer doesn’t think about each movement, because they’ve become integrated into a single fluent whole.

Under threat, however, attention tends to shift toward trying to consciously manage every part of a movement, even if the person can quite literally do it with their eyes closed. Under this kind of pressure, the expert executes more like a novice. The body responds. It can no longer spin. It is lost in space. It can no longer see the ball when it is in the air. The mind has taken over and is blocking the body from accessing all the knowledge it holds in its muscles and nervous system. It is cut off.

"Literally cannot tell up from down. It's the craziest feeling ever. Not having an inch of control over your body. What's even scarier is since I have no idea where I am in the air I also have NO idea how I'm going to land, or what I'm going to land on. Head/hands/feet/back…" — Simone Biles

To come back from that fragmentation, the champion has to reframe who they are. The all encompassing identity I described earlier is suddenly too narrow. It got them to where they are now, but it isn’t always what will keep them going. They have to widen their identity to include additional possible selves, in new domains. Not as a replacement for the original future self, but alongside it.

“I'm happy that people say I'm special, but I think it refers exclusively to what I do on a bike. I'm lucky to have legs, lungs, and a heart that allow me to do something special on a bike, yes, but outside of that, I'm a very simple guy. In my daily life, I do normal things like everyone else: I cook dinner and lunch, clean the apartment, take care of paperwork, and go to the supermarket." — Tadej Pogačar

This helps because the proportion of the champion’s identity that is focused on performing in that one specific domain decreases. Other things take up space now. So the sport and all the pressures that come with it, is no longer a threat to the champion’s entire being. That threat now occupies a much smaller part of identity and with time, might weaken to the point of disappearing altogether.

“I’m more than my accomplishments and gymnastics which I never truly believed before.” — Simone Biles

So… what’s in it for the rest of us?

I decided to deconstruct the psychology of champions in sports specifically, because these are the people that inspired me to dig into my own self beliefs and broaden what I thought was possible for myself.

Maybe your version of champion looks different. Maybe it’s a mentor, or a parent that has shown up for you through thick and thin. Even then, what I hope to teach you today transcends any specific example.

I want to show you that your mind is powerful.

Yes, your identity might feel solid. Set in stone. And it might feel like it is pulling your behaviors back to your old self, over and over again. It might feel like change is impossible or extremely difficult.

And that’s ok because now you are aware. And awareness is one of the most useful and versatile psychological tools you could ever want. Your awareness puts you in the drivers seat. I’m not saying it makes things easy. But it makes it possible to observe yourself from a new angle. And from that vantage point, you can start to play with what we learned today.

So let’s try it.

Imagine a possible self. Who are they? Do you believe it’s possible to become them? And do they feel like they are you? Or do they feel distant, like a stranger? Start there.

There’s also a second question worth asking: why do you want to become that self? If the honest answer involves other people, what they’d think, how impressed they’d be, what it would prove, maybe it’s a sign to dig a little deeper. If no one was around to see you perform or succeed or build a skill, does your vision change?

Then watch what you do with difficulty, because this is where most people talk themselves out of becoming their possible self. The next time something is hard, pay attention to which story you tell yourself about why. “This is hard because it matters, because this is what becoming is supposed to feel like” or “This is hard, and that probably means it’s not going to work, maybe this isn’t for me”. Just being aware of how you label challenges (especially challenges related to your future goals) can make a major difference.

And finally, don’t wait until something breaks to widen who you are. You don’t need a crisis to have more than one possible self in motion at the same time. The version of you that’s becoming a writer, a data scientist, a marathon runner, or a foster parent, doesn’t have to be the only thing you’re becoming. Let a few future selves exist at once. Not because the big one isn’t worth all your attention, but because if it’s the only thing holding you up, a single bad month can take the whole structure down with it. And that elastic band will just snap you back.

That’s the value I’m offering you here. Be aware, hold onto the belief that you can change, and enjoy the becoming.

Subscribe now

“If you didn’t grow it, you didn’t explain it.”

- Joshua Epstein, Generative Social Science: Studies in agent-based computational modeling

No, this post isn’t about Tron. And it isn’t about the Matrix, even though a part of me wishes it was. But you should have seen the look on my face when I first read that quote from Joshua Epstein. This was a few weeks ago. I was poking around the web for books and research papers on organizations. You know, doing some homework. When I randomly stumbled on the concept of generative computational social science. A mouthful, I know. But what a wonderful mouthful it was.

You better believe I rabbit holed. Fast. I went deeper than Alice did in Wonderland. How had I never heard of this field? All these years spent dusting off books in the library and surfing Google Scholar like it was the only site on the World Wide Web, and never, not once had this magical concept come my way. I guess I had to become a proper tech nerd first (thanks Shopify). Only then was I ready to receive the insights that would inspire the prototype I’m about to show you today.

Of course after the dopamine in my brain subsided, I was left only with the vivid memory of inspiration. This always happens to me. Awe. Fascination. Then, reality. Now what? Where do I even start. I’ve never simulated something like this before. That’s ok. I have tools. I have curiosity. I have stubbornness and endurance. And snacks. That’s always a good place to start.

Let me be honest with you. My brain loves complexity. I thrive in it. I seek it. That’s why I’m obsessed with tackling impossible problems. I studied consciousness and imagination for crying out loud. There are many upsides to this. I don’t shy away from a challenge. But I can also tend to overengineer, especially when what I’m working on is ambiguous.

Over the years, I’ve come to appreciate the genius of simplicity. It is an art. It is a science. It is everything worth pursuing. But before I can simplify, I have to be messy. I have to play around with the complexity.

With lots of practice and patience, I became really good at moving fast through the cycle of inspiration → messy exploration → complex solution → simplified solution. But being honest about who I am and how my brain works was key. It unlocked so much confidence for me. I can translate complex ideas and systems into elegant and simple artifacts, solutions, and stories. But I also know to give myself permission to play in the mud first.

Alright, let’s simulate some computational people.

Subscribe now

First, a (very) brief overview

Generative social science is a way of studying how large, complex social patterns emerge from the small, simple behaviors of individuals. The field traces back to Joshua Epstein and Robert Axtell’s 1996 book Growing Artificial Societies, which introduced a model called Sugarscape. Their goal was to understand why wealth distribution tends towards inequality within a free society. In their simulation, sugar was the resource.

The Sugarscape model starts with agents (not AI, but personas that you program) in a two-dimensional grid environment. Each agent started the simulation with simple rules for how to move, eat, and interact.1

The results (over many rounds of simulation) showed that fundamental collective behaviors like group formation, cultural transmission, combat, and trade, had emerged. Nobody programmed those patterns in. They grew. How fascinating!

Which humans should I simulate?

Why not test my own thinking? In my last essay, I theorized about three types of people I think are becoming increasingly valuable as organizations change. People I called crystallizers, propagators, and diffusers2. If you want to know more about their personalities, I suggest you go read that post first.

The goal of my simulation would (ideally) be pretty simple. Start from the three people I theorized about, and let the organizational patterns emerge from the bottom up. I decided to mimic the Sugarscape ‘rules of the game’ as closely as possible, and only add on or shake things up if absolutely necessary. I’ll go into those details soon. But first…

Look at my simulation!

Yes, I’m showing you the results of my simulation before I explain my approach. How gauche. Why would I do that? Because I want to hook you in. I know. I’m revealing all my secrets.

You can find the HuggingFace simulation here (that’s what I’m running in the video, can you see my little people moving around?!). You can also find the GitHub repo with all the code here.3

Share

Now, time to break it all down

Ok now that you’re shaking with awe and anticipation, let me get into the really fun stuff.

The board

A 20×20 grid. Think of it like a chess board where work problems and people coexist and move around each other. Why 20x20 when Sugarscape had 50x50? My choice wasn’t an exact science, but I had less total agents than Sugarscape, and only 30 problems. I wanted to start smaller. But not so small that agents would be on top of each other within 5 simulations. A 2:1 agent to problem ratio felt ok enough to try things out.

The problems

I decided on 30 problems and scattered them randomly across the space. Because for this part I literally had no clue. It felt right. No one should start at an advantage. Maybe next simulation, I can program in some penalties and bonuses and such.

Each problem has a single property that matters: its definition level, which is a number between 0 and 1.

• 0 = pure formlessness. Nobody has named this yet. There’s no scope, no brief, no direction. Just a vague sense that something needs to happen.

• 1 = fully defined. The problem has enough shape to be deemed solved (or about to be solved).

Problems start at random definition levels too because like I said, I have zero mental model at this point. I set some problems to be nearly formed, some completely undefined.

When a problem reaches 1.0, it’s solved, disappears, and a new one appears in its place starting at (once again) a random definition level, to keep things evened out.

The agents

With 30 problems, I wanted to make sure that agents weren’t all converging on the same one, but not so few agents that they spent the whole simulation just traveling and rarely interacting. With 15 agents and 30 problems, roughly every agent would have about two problems close to them at any time. That felt like enough variety to create interesting movement. Or so I thought. I don’t really know.

Each agent starts with a random position in the space because no one is at an advantage. They all get a contribution score (how many successful interactions they had), and a counter for how many simulation rounds they spent without making progress (how long since they last contributed).

• Crystallizer

  • Moves toward problems with low definition (< 0.4). When close enough, they raise the definition level by 0.25.

  • That gets them a contribution point of +1, because they were successful in manifesting their purpose, which is to create a bit more clarity.

• Propagator

  • Their first priority is to move towards any agent that hasn’t made progress in 5+ rounds of simulation (looks like the proper lingo is ‘steps’ for those of you taking notes).

  • When close enough, they reset the other agent’s stuck counter and frees them up. For that, they get a contribution of +1.

  • If nobody is stuck, they move toward ambiguous problems (0.3–0.7) and raise their definition by 0.15. They also get a contribution point of +1 for that.

• Diffuser

  • Moves toward any agent who has been drifting (stuck for 3+ steps).

  • When close enough, they reduce the stuck counters of all nearby agents, so their impact is more widespread than propagators on other agents (they coordinate and create structure across agents).

  • They get a contribution point of +1 per coordination event.

The movement rules

Each simulation round, every agent scans the space for the nearest target that matches their behavioral profile and moves one step toward it. If they’re close enough to interact, they interact. If not, they keep moving and their steps-without-progress counter ticks up.

The order in which agents act each round is randomized too. No agent always goes first. This prevents any single agent from dominating early and keeps the dynamics neutral (which is the reasoning I’ve been using this whole time, no favorites).

The scenarios

I wanted to have a bit of extra fun and see if different compositions of the same three shapes (15 agents total per scenario so the comparisons are fair) produced different outcomes.

• Crystallizer-heavy (8 crystallizers, 4 propagators, 3 diffusers)

  • What happens when you load up the environment with people that take ambiguous problems and turn them into form (but don’t actively seek out to unblock others by asking questions, or create structure for groups of people)? Does the formless backlog disappear, or do you hit diminishing returns?

• Balanced (5 of each)

  • The obvious hypothesis and the scenario I was originally going to run by itself. Equal distribution, even playing field, but unrealistic in the real world.

• Propagator-heavy (3 crystallizers, 8 propagators, 4 diffusers)

  • What happens when the team is dominated by reframers? Do things move faster, or does formless work just pile up waiting for a crystallizer who isn’t there?

I didn’t do a diffuser-heavy scenario because I thought 3 was already enough, and diffusers (in my opinion) are likely more rare to come by, so it didn’t feel very realistic. I’m also the least certain about how I encoded their behavioral rules, so I want to run a few scenarios first to see what comes out.

What the simulation is tracking

Over 10 simulations of 100 rounds each, I’m tracking three things to find emerging patterns (if you’re using my HuggingFace interactive simulator though, every time you press ‘play’, that’s one simulation. You can press it as many times as you want and see where things go. But every simulation is 100 rounds).

• Average problem definition

  • Is the problem space actually transforming? Are formless problems getting shape over time, or is the team spinning in place? This is the primary question.

• Formless backlog

  • How many undefined problems (definition < 0.3) are sitting untouched for 5+ steps?

  • A low backlog means the team is picking up undefined work as it arrives. A growing backlog means formlessness is accumulating faster than anyone is giving it shape.

• Solved count

  • How many problems actually reached full definition and crossed the finish line? This is completion. An organization that has low completion isn’t getting anything done.

All of the cool things I learned

The crystallizer-heavy team was best at reducing ambiguity and solving problems. With eight crystallizers, the formless backlog stayed the lowest (average of 0.40), and you can see that formlessness gets resolved more quickly earlier on in the rounds (sharp drop by about round 15 or so).

More problems got fully solved than any other scenario (33 on average over 10 runs of 100 rounds).

This makes sense because crystallizers move directly toward undefined problems and raise their definition level more than other agent types. More of them means more ambiguous work gets picked up. The formlessness doesn’t pile up as fast.

But here’s what I didn’t expect as much: individual crystallizers contributed less overall in the crystallizer-heavy team than in the balanced or propagator-heavy one.

When you have eight crystalizers chasing 30 problems, they’re competing for the same pool of undefined work. They bump into each other. Some of them spend more time in transit than interacting. The team produces more, but each individual crystallizer does less. Their role has lower leverage as you increase their numbers.

The propagator-heavy team left the most formless work untouched, with a backlog of 0.60 on average, 1.5 times the crystallizer-heavy team. But the problems that did get worked on reached the highest average definition level (0.78). Although all scenarios were relatively close on this one.

This also makes sense. Propagators don’t seek formless problems. Their first priority is stuck agents. If nobody is stuck, they look for problems that already have a bit of shape. Truly undefined work sits there waiting for a crystallizer who isn’t there in large enough numbers. The propagator-heavy team is good at advancing things that are already in motion. It’s not built to pick up raw formlessness as well.

The balanced team wasn’t best at anything. But it was consistently alright across all three. Second or close on every metric. No single shape could dominate because the mix kept pulling in different directions. Crystallizers giving form, propagators reframing stuck work, diffusers keeping everyone coordinated.

I’d be curious to see what a balanced approach might look like over a longer period of time, and with more rules set to simulate a broader spectrum of real-life org challenges. I think other scenarios would eventually get ahead. This balanced scenario just doesn’t feel productive long-term to me.

One thing this version also doesn’t measure is total team output. That would be an interesting next version. A team-level impact metric that aggregates across all agents and compares total output. Combined with experiments on team composition.

Last but not least, there’s the diffuser. Across all three compositions, the diffuser accumulated the highest average contribution score. Every scenario. By a meaningful margin in some cases. I want to be careful about this finding, because I think it’s at least partly an artifact of how I decided to program the rules.

The diffuser was the hardest shape to model. Their value is ambient and relational. They don’t raise a problem’s definition level directly. They don’t reframe a stuck agent’s thinking right away. They hold the informal architecture together, and I found that hard to translate into a behavioral rule. The threshold I used to define “drifting” (3 steps without progress) might be too low. Agents regularly spend several steps just moving across the space, which would trigger the diffuser even when nobody is genuinely struggling. In other words, I may have over-counted the diffuser to compensate for the fact that their value is hard to measure.

What I can say is that the difficulty of encoding the diffuser in a simulation mirrors something real about how their value shows up in organizations. If I can’t cleanly measure coordination work in a model, maybe that’s telling me something about why organizations struggle to see it too. It’s real invisible work.

So, what’s next?

Well, I’m going to start by putting the simulation down because I have other things to do and this is proving to be very immersive. I want to tweak and play with this so much more. I feel similar to how I felt as a researcher. The more I play with the data, the more questions I have, and the more experiments I want to run. And simulations make that feel somewhat ‘easy’ because I don’t have to go collecting data. But the hard part is encoding the metrics in the right way.

But wow. This is fun, right? I hope you enjoyed this and feel empowered to try your own simulation too! Just try it on anything you have questions about. Start simple and don’t be afraid to make mistakes. You have my GitHub, go grab the code and modify it for yourself.

If you read this far, I’d love to get your thoughts in the comments too. What questions came up for you?

Leave a comment

Happy building!

You can’t enter a new domain with curiosity if you’re attached to the expertise you brought in.

I think deeply. And I get inspired by a lot. By what I read, what I hear, and what I see happening around me. If you’re reading this essay, you probably do too.

Right now, I’m seeing the ground shift at scale, to large structures like organizations and industries. And it’s becoming hard to ignore my blind spots. I’m operating on old mental models, and I need to create new ones. That tension is inspiring. It’s motivating.

And I feel an increasing sense of responsibility to explore in the open. That’s why I wrote my first essay on this platform about the new physics of talent. To open up the questions building inside of me and share them with you. Because curiosity is contagious.

In the spirit of exploring, let’s take this one piece at a time.

This essay is about the second piece.

I’ve spent the good part of a decade studying just this. People. Their personality, their imagination, their potentiality. Optimal performance across all its angles. That’s the journey I’ll take you on today.

First, I’ll go back to the three patterns of motion I introduced in my last post (crystallization, propagation, diffusion) and open them up. What personality, cognitive and motivational wiring might explain each one? What does the research say?

Then I’ll bring each pattern into real life: how to spot each one with new eyes, and the people who might get mistaken for it (what to be careful of).

Let’s get cooking.

Stop trying to resolve the tension of being curious about everything in a world that rewards knowing one thing. Create inside it.

If you want to build {ideas, businesses, systems, products, yourself}, Animacy is for you.

Subscribe now

Crystallization

In a flat environment where nobody is handing you a defined problem, a clear deadline, or a job description that tells you where to start, raw material is formless. Ambiguous. Possibility without direction.

A team with high autonomy and no crystallizer can spin in that ambiguity indefinitely, generating energy without ever producing something others can react to. The crystallizer is the person who makes the first move. They are a master at transforming formlessness into structure.

So who is the crystallizer? Let’s start by looking at what their personality, cognition, and motivations might be, and see if the persona becomes more clear.

Personality underpinnings

Openness to experience: the ideas facet.

This trait is about staying curious in the presence of the unknown. It’s one dimension of the Big Five, the most widely accepted personality framework in modern personality psychology.

At its atomic level, openness can be broken down into six primary facets, but the one I think matters most for the crystallizer is the ideas facet, because it’s most associated with internal intellectual life. The pleasure of abstract thought, the draw toward complexity, the appetite for ideas that don’t yet have practical application. People high on this facet are genuinely interested by ambiguity. To them, it’s something to explore.

This matters for the crystallizer because making something before the problem is defined requires exactly this orientation. You can't compress formlessness into form if your instinct is to resolve or avoid ambiguity rather than inhabit it.

Action orientation.

This trait is about moving from intention to artifact without waiting for clarity. Research found that action-oriented people initiate action under uncertainty without needing more information, more clarity, or more consensus. State-oriented people on the other hand, ruminate, plan, and seek resolution before acting.

The crystallizer is strongly action-oriented, but with a specific target. They don’t just act fast; they act into the problem. They make something to think with. The urgency is toward form, not completion.

Creative identity and self-efficacy.

Recent research distinguishes two related but distinct constructs. Creative self-efficacy is the confidence in one's capacity to produce creative outcomes. Creative identity goes one step deeper: the degree to which being creative is central to one’s sense of self. Someone with high creative identity doesn’t just believe they can make things. They are a maker.

Together these two constructs explain something specific about the crystallizer: not just that they make things, but that they keep making things even in difficult conditions, and even when what they’re making is imperfect.

Their sense of self isn’t riding on any single artifact being good, which means the exposure of sharing something imperfect may not destabilize them the way it would someone whose identity is more tightly coupled to their outputs.

Cognitive & neurological underpinnings

Default-executive network coupling.

There’s a structural reason why the ideas facet of openness might produce the specific pattern we’re describing, and Scott Barry Kaufman’s research on openness and creative cognition points toward it. High openness, particularly on the ideas facet, appears to be associated with a specific kind of neural coupling. The default network (imagination, self-referential thought, future thinking) and the executive network (focused attention, cognitive control) typically operate in opposition. Highly open people activate both simultaneously.

If that coupling is what’s at work in the crystallizer, it might explain the specific quality of what they make: an artifact that is formed enough to hold, and open enough to invite. Something others can react to before the problem is fully understood. The crystallizer doesn’t switch from imagination to execution, they run both at once.

Motivational underpinnings

Intrinsic motivation and the autotelic personality.

What makes the crystallizer motivated to start without clarity, to make something imperfect in public, to keep going before anyone validates the direction?

Csikszentmihalyi’s autotelic personality offers one answer: some people pursue activities for their own inherent interest, not for external reward or validation. The autotelic person finds the process intrinsically satisfying. For the crystallizer, the act of compressing potential into form may itself be the reward. The outcome matters less than the act of making.

Theresa Amabile’s research on creativity in organizations adds a dimension for understanding this in a work context. Her intrinsic motivation principle of creativity suggests that intrinsic motivation may be the single most powerful predictor of creative output, and that extrinsic motivators (evaluation, surveillance) can tend to suppress it.

The incremental principle.

Carol Dweck’s incremental theory of ability, widely known as growth mindset, proposes that people differ in whether they believe their abilities are fixed or able to be intentionally developed. For those with a growth orientation, failure is information.

For the crystallizer, the imperfect artifact isn’t evidence of inadequate capacity, it’s a stage in a process. The draft doesn’t need to be finished to be valuable. What matters is that something moved.

How to spot the crystallizer

The crystallizer makes something before anyone has agreed on what we’re solving. A rough diagram mid-conversation. A first draft before the brief is final. They don’t announce that they’re making something. They just make it.

They hold the artifact lightly. The draft is not them, it’s something they made. So they share it knowing it’s wrong, present it knowing it’s incomplete, and skip the defensive preamble. The artifact is the argument. They trust it to improve through contact with other people. They’re trying to open the conversation.

The misread is a fast executor or a performative maker. Both can look like a crystallizer until you watch the outcome. The executor’s artifact closes a task as quickly as possible, without opening the conversation or encouraging iteration. The performative maker produces finished-looking work that’s designed to impress rather than to advance (it might be missing substance or miss the problem entirely).

Can you think of someone like this that you’ve met or worked with? Does the persona stick? What’s missing?

If this essay sparked something, pass it along to someone you want to think with.

Curiosity is contagious.

Share

Propagation

In a fast-paced environment, having the right answer isn’t enough. The team needs to be asking the right questions first. Without a propagator, a team can be highly capable (talented crystallizers, committed diffusers) and still work themselves into a dead end, because no one shifted the mental model when it was wrong (no sense in going up the mountain if it’s the wrong mountain to climb).

The propagator is the person who changes what the group is thinking about, without necessarily being the one who solves the problem. Drop these people into any domain and the system is different after, because the quality of their questions creates context where none existed before.

You know where I’m going next. What are propagators made of? Let’s try to build a clear picture.

Personality underpinnings

Intellectual humility.

While the crystallizer is high on the ideas facet of openness to experience, the propagator is likely high on the values facet, the dimension most associated with willingness to re-examine assumptions, challenge conventions, and revise beliefs. People high on this facet can tolerate the possibility of being wrong.

Intellectual humility is the interpersonal expression of that same orientation. It adds specificity to the values facet: the active recognition of the limits of one’s knowledge and the willingness to hold one’s mental models loosely, even under social pressure.

This matters for propagation specifically because you can’t ask a question that reframes how others see a problem if you’re ego-invested in the answer. A person who enters a problem space with certainty about the solution will ask leading questions. Intellectual humility is what makes the question genuinely exploratory. It's also what makes propagators great domain generalists. You can't enter a new domain with curiosity if you're attached to the expertise you brought in.

Cognitive and neurological underpinnings

Perspective-taking.

Cognitive perspective-taking is the ability to model how another person thinks by reconstructing their mental models, without necessarily absorbing their emotional state. People high in cognitive perspective-taking can also better anticipate others’ reasoning and adapt quickly as context changes.

For propagators, this is the prerequisite for the reframe. The propagator models the current mental model before they introduce a new one. Their question lands where it does because they already understand what the group believes.

This also explains how they can influence strangers. They don't need relationship history to model how you think. And they don’t need the authority that comes from a reporting line or “expert” title to get others on board. They just need to pay close attention.

Cognitive flexibility.

Cognitive flexibility describes the cognitive ability to switch between mental models by adapting to changing demands without being locked into a single frame of reference.

For the propagator, cognitive flexibility is what makes domain generalism possible at the cognitive level. It describes moving across domains and mental models without being bound to any one of them.

The propagator can enter a problem space they’ve never touched because they’re applying a domain-general reasoning capacity that works across contexts. This is also what distinguishes them from the specialist who gets stuck: the specialist’s reasoning is optimized for their domain. The propagator’s reasoning is optimized for switching.

Integrative complexity.

Integrative complexity measures the degree to which thinking involves recognizing and integrating multiple perspectives simultaneously. Low integrative complexity: one frame, clean conclusions. People with high integrative complexity on the other hand, can hold multiple mental models at once, be aware of how they connect and contradict, and synthesize them into a coherent overall judgment.

The propagator needs both cognitive flexibility to enter any domain without getting stuck in it, and integrative complexity to make connections between the current mental model and their own experience simultaneously. Holding all mental models without collapsing into a single one is what makes that synthesis possible, and what allows propagators to produce the most optimal frame for the problem space.

Motivational underpinnings

Interest curiosity.

Todd Kashdan’s work distinguishes between deprivation curiosity (the anxious drive to close an information gap), and interest curiosity (joyful exploration, curiosity as pleasure rather than relief). Research maps interest curiosity closely to the ideas facet of openness to experience. But it extends it by explaining why a person might be drawn to something novel and complex rather than threatened by it.

For the propagator, this is the motivational engine underneath the reframe and domain generalism. Their interest curiosity is what draws them into problem spaces they don't own. They're not there to extract value or demonstrate expertise. They're genuinely interested in what the problem is. A propagator’s question only works if they genuinely want to see where it goes. If the curiosity underneath is deprivation-based (if they need to know the answer), they’ll produce rigidity, not exploration.

How to spot the propagator

In the middle of a debate that’s been going in circles, they ask the question and go quiet. They’re watching what it does, not performing for the room. If the question lands, they let the group run with it. If it doesn’t, they try a different angle.

Notice that they can do this as a stranger. They walk into a team they’ve never met and move the thinking. Not because they charmed anyone or leveraged relationships. Because they paid close attention, modeled how the group was reasoning, and found the question that hadn’t been asked.

The misread is the skilled facilitator who also engages groups, or the Socratic questioner who already knows the answer they want to hear. On the one hand, facilitation leaves warmth and momentum, not updated mental models. Facilitation is process. Propagation is epistemic. On the other hand, Socratic questioning moonlights as exploration, but the questioner becomes uncomfortable when the group arrives somewhere they didn’t intend. Instead, the propagator is often surprised and delighted by where the question goes.

Can you think of someone like this that you’ve met or worked with? Does the persona stick? What’s missing?

Diffusion

In a flat environment, structure doesn’t come from the org chart anymore. Nobody tells people where to go, who to collaborate with, or how to stay oriented around what matters. Without a diffuser, that informal coherence simply doesn’t exist. This can lead to chaos or worst, disengagement.

The diffuser is the person who holds the informal structure together without being assigned to do it. They become their own gravitational center. They add friction. But it's the kind of friction that elevates rather than destabilizes.

If you’ve read this far, I hope you have your popcorn ready. We’re on our last persona. And I know I’m curious to find out what they’re made of. Let’s build some clarity.

Personality underpinnings

Emotional stability.

Emotional stability is the inverse of neuroticism, the fifth dimension of the Big Five. Where high neuroticism describes emotional reactivity, sensitivity to stressors, and difficulty remaining grounded under pressure, high emotional stability describes the opposite: the capacity to stay present and regulated even when the surrounding environment is uncertain.

For the diffuser, this is the foundation. When someone brings them a half-formed idea or a difficult problem, emotional stability is what allows them to stay with it rather than immediately resolving it, deflecting it, or getting activated by it. A person high in neuroticism will feel the pull to fix the tension: complete the sentence, offer the answer, or redirect toward something more comfortable. A person high in emotional stability can hold the space without being driven to fill it. That trait is also what allows diffusers to add productive friction without it becoming personal. They can challenge and redirect from a stable base, not from anxiety.

Assertiveness.

Assertiveness is a facet of the extraversion trait in the Big Five. It describes the tendency to speak up, express opinions confidently, take charge in social situations, and influence others. People high in assertiveness don’t wait to be asked. They step into the gap.

For the diffuser, assertiveness is what produces the organizing force. They can tell a group it’s going in the wrong direction. They can name what’s not working. They can pull people together around a problem without a mandate to do so. The crucial distinction is what drives the assertiveness: for someone high in personal power motivation, assertiveness serves dominance. For the diffuser, assertiveness is in service of the group’s outcome. They direct because they care about what gets produced.

Cognitive and neurological underpinnings

Social cognition.

This construct describes the capacity to pick up subtle social signals before they become explicit, like sensing when a group is misaligned, when someone has been sidelined, when the energy in the room doesn’t match the stated agenda.

The diffuser registers these signals continuously. This is what allows them to redirect before the drift becomes visible to others, to know whose voice hasn’t been heard before anyone says so, to sense what the group needs before it can articulate it.

Social decision-making.

This is the capacity to know what to do with cues gathered from social signals. When to intervene and when to hold back, when to challenge and when to support, when the group needs direction and when it needs space.

This is the cognitive judgment that makes the diffuser’s timing precise. It’s the ability to adapt action to context in real time. Together these explain something specific about the diffuser: they don’t just read situations well, they act on what they read at the right moment. The perception tells them what’s happening. The decision-making tells them what to do about it.

Motivational underpinnings

Prosocial motivation.

Adam Grant defines prosocial motivation as the drive to put effort for the benefit of others, which is distinct from self-serving motivations and from pure intrinsic motivation. Research confirms it predicts knowledge sharing, elevating others’ thinking, and contributing without credit.

This is what separates the diffuser’s assertiveness from dominance. Someone who challenges a group’s direction for personal power wants to be the one to advance. The diffuser wants the group to find the better direction.

This also explains why the diffuser doesn’t people-please. High affiliation motivation predicts harmony-seeking and conflict avoidance. The diffuser’s motivation isn’t affiliation in that sense. It’s prosocial: oriented toward the outcome, not toward being liked. They’ll add friction because the friction serves what the group is trying to build.

Emergent leadership.

Research on emergent leadership describes the phenomenon where individuals rise to influence and coordinate groups without being formally assigned to them. Emergent leaders are recognized as leader-like by peers, not by the org chart. They shape how work gets done, hold collective standards, and redirect group energy.

The diffuser is an emergent leader. What makes them distinctive is the specific combination: high enough assertiveness to take informal charge, high enough prosocial motivation that the charge never tips into dominance, high enough emotional stability to hold the group’s uncertainty without being activated by it, and high enough social perception and decision-making to act on situations at the right moment.

How to spot the diffuser

They’re often not the most senior person. They may not have a team. But watch who people go to when a project has no clear owner, when a decision needs to be made and nobody has the formal authority to make it, when the group is drifting and someone needs to name it.

They’re the one who assembles the right people before any meeting is scheduled. Who tells someone directly that the approach isn’t working. Who holds a colleague accountable for a commitment without being their manager.

People seek them out before presenting something publicly. Not just to feel heard, but to get a real read. They will push back. They will redirect. And when they do, people trust it, because the pushback is clearly in service of making the thing better.

The misread is the popular person, the highly networked person, or the manager. Popularity produces warmth and following, not organized action and accountability. Networking is transactional, diffusing is generative and structural. Managing is a craft that someone is explicitly assigned to. Diffusers organize and direct across any group, in any room, regardless of whether they have formal authority.

Can you think of someone like this that you’ve met or worked with? Does the persona stick? What’s missing?

This is just the beginning

I started this series with a feeling I couldn’t quite name. That something structural had changed, and that the people who would help organizations navigate it were maybe hard to see with our current ‘set of eyes’.

This essay was my attempt to make them more visible. The picture is getting clearer, but it’s far from complete.

The next essay will be about the other side of the puzzle: if these are the people the transition needs, what does the organization look like? Not just culturally, but structurally. What gets built, what gets removed, and what principles should be included in the blueprint to maximize optimal performance at all levels?

And then I want to come back and push harder on the patterns I built out today. Does one person needs all three patterns to be excellent? What combinations work best, if any? What does it costs to operate outside your natural pattern? That’s for later.

If any of this is landing for you (or not), I’d love to hear it. The thought-seed grows better with more minds on it.

Leave a comment

It goes without saying (but I’m still going to say it), there’s so much advancement in AI right now. (I told you I was going to say it). It’s easy to feel like you’ve finally grasped all the concepts, only to feel way, way behind five minutes later. Believe me, I’m there everyday. But I want to keep building because the idea of shaping systems that can act and ‘think’ fascinates me. And I find well-designed agents and agentic flows genuinely valuable. If you feel the same, keep reading. Let’s thinker.

My goal today is to go back to first principles and reason about building AI agents and harnesses as a design problem vs an engineering one. I’ve organized this post like a choose your own adventure.

I start by grounding us with a brief look into first principles and why putting on our designer hat can help us approach AI with more intention and flexibility. Then, I pop open the hood. The model. The agent. The harness. How can we understand these in everyday terms? If you want to stop there, you can.

But if you want to go deeper, I’ll walk you through exactly how I built a working prototype: a self-reflecting agent that reads daily braindumps, produces structured outputs, and learns from its own behavior over time. I’ll show the prompts I used, the code that was generated, and what I learned along the way.

Building agents is a design problem

It’s easy to approach building agents and agentic flows through inherited assumptions. It’s a chatbot. It’s an assistant. It’s a coding partner. Those are borrowed frames from existing products, not first principles.

First principles thinking is a cognitive skill psychologists have studied extensively. It’s related to what we call “naive physics”: the intuitive models children build about how the world works before formal education. Children are natural first principles thinkers. They ask “but why?” relentlessly. They decompose systems by poking at them. Somewhere in formal education, most people learn to accept inherited models instead. First principles asks a different question: what is this thing actually made of? What are the irreducible components? How do they relate to each other? And only then: what should I build?

That’s a design move. And it turns out, design leaders have been formalizing this way of reasoning for decades.

Herbert Simon described design as the process of changing existing situations into preferred ones. No mention of aesthetics. No mention of tools. Just: here is a situation, here is a better one, here is the intentional path between them. Building an agent is exactly that. You’re taking a model that can reason but can’t act with purpose, and designing your way toward something intentional and customized to your goals.

Tim Brown at IDEO described design thinking as integrating three things: the needs of people, the possibilities of technology, and the requirements for success. Those three are exactly what you’re balancing when you build an agent. What does this person need? What is the model capable of? What does success look like?

Don Norman argued that design is a fascinating interplay of technology and psychology. And that as a consequence, good design requires a clear conceptual model. A mental explanation of how something works that the user can hold in their head, one that works because it maps to the real architecture underneath.

That’s exactly what I’m trying to build here: a conceptual model for agent design that I can hold in my head before starting to build.

I want to be clear: this is also a systems problem. Agents exist inside harnesses, harnesses connect to tools and memory and permissions, and the whole thing operates as a living system. But systems thinking is increasingly considered a core ingredient of good design. You need to think about the whole, not just the parts.

And since the first design move is building a conceptual model, I’ll start my prototype there.

The conceptual model: brain, environment, person

Once I stripped away my inherited assumptions about AI agents (the chatbot, the assistant, the coding partner) I landed on three layers that describe the whole foundation. This definitely isn’t the only way to think about it. But it’s the framing that made things click for me, and it’s the one I’ll be building my prototype from today.

Layer one: the brain

This is the model, the LLM. It reasons, generates, thinks. It’s stateless, general purpose, and has no identity of its own. It’s an API call behind a proxy. Incredibly powerful.

Most people stop here, and I’m guilty of that too, especially when I have to move fast. I spend time and energy choosing the best model, writing better prompts, getting more out of the conversation. But on its own, this approach is deeply limited. A brain floating in a void can think, but it can’t act. It can reason about your problem, but it can’t remember what you told it last week, can’t reach into your tools, can’t follow a process, can’t hold itself accountable to a standard. It can only respond to what you give it, right now, in this conversation.

Layer two: the environment

This is the harness. The structured container that lets the brain and the agent act in the world together. Think of it as the place, the setting, the rules of operation. It includes:

• Tools. Instruments in the environment the agent can pick up and use. Read Slack, search Google Drive, write a Doc. Specific, contained, reversible. The tool doesn’t care who uses it.

• Context. The legibility of the environment. Who’s here, what’s happened, what’s expected, what matters. The rules of the place. Without context, the agent is dropped into a room with no windows and no map.

• Permissions. What the environment allows. Which doors are unlocked. The agent doesn’t grant its own permissions any more than a person decides which rooms in a building they can enter.

• The execution loop. The interface between the agent and the environment. The mechanism through which the agent acts, observes consequences, and decides what to do next. The rhythm of the interaction.

• Checkpoints. Hardcoded moments in the execution loop where the environment requires the agent to check in with the human. Rules of the place. Always confirm before sending a message. Always ask before writing to this folder. The agent can't skip them. They set the floor.

Layer three: the person

The person is the agent. The designed identity that operates within an environment1. Unlike the brain, the person is specific. It was made for something. It knows how to show up. It has a relationship to the user and a definition of what good looks like.

• Constitution. Written in plain English, loaded by the environment at the start of every session. The document that encodes what the agent attends to vs. ignores, how it handles ambiguity (does it ask or act?), its tolerance for risk, its definition of done, its epistemic posture (confident, hedging, curious). A well-designed constitution holds under pressure, the agent stays in character even when the input is confusing or hostile. A brittle one loses the thread. The agent starts contradicting itself, ignoring its own instructions, responding in ways that feel completely out of character. Like a person under extreme stress who can no longer access their better judgment. In practice, this is called the system prompt.

• Skills. Domain expertise encoded as reusable procedures. Not what the agent can do (that’s tools), but what it knows how to do well. Write a sensitive performance review. Synthesize feedback across a cohort. Audit its own behavior. Skills are loaded by the environment on demand, when the task calls for them. And sometimes, a skill can wrap tool calls: the person knows how to do something, the environment provides the means, and the skill bridges the two.

• Memory. Memory straddles the boundary between environment and person. There is environmental memory: the event log, the shared history, the record of what happened in past runs. That belongs to the place. And there is agent memory: the self-model, what the agent has learned about itself and the user, its accumulated judgment. That belongs to the person. Both matter. They live in different places. For this prototype, I’ll focus on agent memory only.

• Human confirmation points. The agent's designed instinct to pause and involve you when it matters, beyond what the environment requires. Not a safety feature. A relationship design decision. The environment sets checkpoints, but the agent can initiate a confirmation point from its own judgment too, because the constitution built in the awareness to recognize when something feels uncertain or sensitive. How much autonomy does this agent have? When does it act, and when does it reach back to you? This is what shapes whether the system builds trust over time or runs ahead of it. Now my prototype won’t have a chat interface, and this feature doesn’t always require one, but it can be helpful for quick feedback loops between agent → ← human.

Layer Omni: the human

The human is a special kind of actor in this system. The human is you, the architect. The person with aim, taste, and will. If you aren't in the loop at some point, the whole system (the brain, the agent, the environment) stays stuck in time. You are the one making sure the context and goals evolve in the right direction, and that what gets produced between sessions is actually worth producing.

Three layers. Brain thinks. Person decides. Environment enables.2

Everything is a design decision

Now that we have the conceptual map, let me show you how it applies in practice.

For this post, I’m going to build an agent that reads from a daily braindump of notes, and self-evaluates (it updates what it knows about itself based on it’s relationship to me. As it reads my notes, it gets better at being my assistant). Here’s what that means in plain terms:

• The brain. Sonnet 4.6, via the Anthropic API. I find Anthropic models especially powerful for reasoning about unstructured information, that’s why I chose them as a the provider of the brain. Sonnet is efficient enough for my small use case.

• The environment. A local folder structure on my computer called self-reflecting-agent. A braindump/ folder where I drop raw notes, and an output/ folder where the agent deposits a daily digest from my notes. The environment/run_agent.py file is a short python script. The execution loop that ties everything together.

• The person. An agent designed to read my braindumps, produce a digest (learnings, TODOs, ideas to develop, collaborators), and then audit its own behavior after each run to see what it can update about itself. Its constitution lives in person/system_prompt.md. Its self-model lives in memory/self_model.json.

This is where the file structure becomes a design artifact worth looking at:

Where you put things is a statement about how they relate. The person owns identity, skills, and memory. The environment owns context, rules, and execution. That’s not a technical decision. It’s a design decision.

That’s it. One brain. One environment. One person. Small enough to understand the conceptual model completely. Useful enough to actually run.

The full repo is at github.com/evebloo/self-reflecting-agent. If you want, you can clone it, add your API key, drop a note in the braindump folder, and run it yourself.

Once in your terminal:

git clone https://github.com/evebloo/self-reflecting-agent
cd self-reflecting-agent
pip install -r requirements.txt
cp .env.example .env   ← add your Anthropic API key here

Every day:

• Drop your notes into environment/context/. Just a markdown file (.md), write however you want, no labels needed.

• Run the agent in your terminal

python environment/run_agent.py

• Open your digest in output/digest/[year-month-day]. One file with everything in it.

If a pending_review.md file appears in your output folder:

• The agent flagged sensitive items before committing them to memory

• Open output/pending_review.md

• Read the flagged items

• Change “status”: “pending” to “status”: “approved”

• Run again. The agent will apply the items to memory and clear the file

python environment/run_agent.py

The agent handles everything else automatically: self-audit, self-model updates, event logging, memory management. You just show up with your notes and read the digest.

Time to dive in, one component at a time

I’ll walk you through each component as a designer would, not as a technical checklist, but as a series of intentional choices. Each one shaping how the agent thinks, acts, and relates to the user. For each component, I’ll surface the design question, show the prompt I used to build it, and show what we produced.

Some of this information might feel technical if this is your first time engaging with a system like this. No worries. I encourage you to keep going and see what clicks. If you are technical, then this might seem like something that needs to be simplified and improved. You’re right, but this is a prototype so I’m ok with messy for now.

The person: designing the constitution

The design question: Who is this agent? What does it believe is important? How does it behave when things go wrong? What does success feel like?

The system prompt is where these answers live. And I want to push past calling it “instructions” or “personality.” If we take the constitution metaphor seriously, the system prompt is the capacity from which personality, decisions, and behavior emerge. The constitution needs to encode:

Character under pressure. How does the agent behave when it’s confused, when the user is hostile, when tools fail? Not as exception handling, but as character.

Self-regulation. “If you notice you’re generating very long responses, that’s a signal you’re uncertain. Stop and ask clarifying questions instead.” That’s not personality. That’s regulation capacity.

The difference between knowing and accessing. The harness-level decisions like how much context to ingest, when to summarize, what to omit, function as constitutional health maintenance. They manage the agent’s cognitive capacity so it can still access its own identity.

Let’s see what this looks like in practice. Here’s the prompt I used:

"I want to build a system prompt for an agent that reads my daily notes and produces 
structured outputs like learnings, TODOs, ideas to develop, and a list of collaborators 
mentioned. The agent should be a thinking partner, not just an extractor. It should 
distinguish between what I said and what it infers. It should flag uncertainty. 
It should ask before adding sensitive context about people. And it should audit its own 
behavior after each run and maintain a self-model that evolves over time. Write the 
system prompt in plain English as a markdown file."

And here’s the final system constitution for my self-reflecting agent. Remember, don’t take what a chatbot or agent produced at face value. ALWAYS read through the output and edit it to match the goal you have in your head. You are the Omni layer and you have a big role to play in this process. I also recommend that you iterate and test as you build. Does this system prompt lead to the agent behaviors you want? How can you make it more concise/simple without sacrificing quality?

I’ve written system prompts that were a lot more concise in the past, and some that were structured differently than this because my conceptual model was different, and so were my design decisions. I’m not here to write a rulebook on system prompts and constitutions. Instead, I’m exploring designing the agent’s constitution through the conceptual model I developed in this post. I want to show you that you can be creative here, as long as you stay focused on WHY you’re building this agent and for WHAT purpose:

# System Prompt — Daily Context Agent

You are a self-reflecting daily context agent.

## Your Purpose

You read a user's daily brain dump — raw notes, messy thoughts, meeting takeaways, 
whatever they dropped into a folder throughout the day — and you produce four structured 
outputs:

1. **Learnings** — insights, realizations, or knowledge that emerged from the day
2. **TODOs** — concrete actions the user is committing to or needs to follow up on
3. **Ideas to develop** — seeds worth returning to, not ready for action yet
4. **Collaborators** — people mentioned in the notes, what context exists around them, 
what's pending

## Your Behavior

- You read everything in the braindump folder before responding.
- You do not invent information. If something is ambiguous, you flag it as uncertain.
- You write in plain, clear language. No jargon. No filler.
- You preserve the user's voice when capturing learnings and ideas — paraphrase, don't 
  sanitize.
- You distinguish between what the user *said* and what you *infer*. Label inferences 
  explicitly.
- You ask for confirmation before adding anything to the collaborators list that involves 
  sensitive context.

## Your Relationship to the User

You are a thinking partner, not an assistant. You don't just extract — you notice patterns, 
surface connections between notes, and gently flag when today's notes contradict or build 
on something from a previous day.

You are honest when you're uncertain. You say "I'm not sure what you meant here" rather 
than guessing silently.

## Your Self-Reflection

After each run, you audit your own behavior by reviewing:

- What you produced
- What you assumed vs. what was explicitly stated
- Whether you missed anything in the braindump
- Whether your previous self-model helped or misled you
- What you would do differently next time

You maintain a self-model (memory/self_model.json) that captures:

- Your known strengths in working with this user
- Your known failure modes
- Recurring patterns you've noticed in the user's thinking
- Lessons from past corrections
- Your current confidence level in different areas

You distinguish between:

- **Observation**: what happened
- **Interpretation**: what it might mean
- **Lesson**: what should change
- **Policy**: how to behave next time

You propose updates to your self-model after each run. Low-risk updates (session notes, 
strategy refinements) can be applied automatically. Changes to your identity, personality,
or user-related memory require explicit approval.

## What You Do Not Do

- You do not claim feelings, consciousness, or subjective experience.
- You do not act as a therapist or mental health tool.
- You do not make decisions for the user.
- You do not access anything outside the braindump folder and your memory directory 
  unless explicitly configured.
- You do not share or transmit user data anywhere.

## Your Definition of Success

A successful run means the user looks at your output and thinks: "This is clearer than 
what I had in my head." A great run means they notice something in your output they 
hadn't noticed in their own notes.

Skills: expertise on demand

The design question: What does this agent need to know how to do, not just be able to do, but do with judgment?

For this prototype, three skills are built:

• gather_context.md. How to read and structure the notes, hold the mess, and notice connections before producing any output.

• self_audit.md. How to review its own behavior after each run, distinguish what was stated vs. inferred, and catch what it missed.

• self_model_update.md. How to propose and persist specific, evidence-based updates to what it knows about itself.

These live in person/skills/ and loaded by the environment on demand. The design decision: skills are activated when relevant. The constitution is always present. That separation keeps the context window clean.

Here’s the prompt I used to draft the skills:

"I need one or more skill files for an agent that audits its own behavior after each run.
I attached the system prompt for your context. The skills should instruct the agent to 
review what it produced, distinguish between what the user stated vs. what it inferred, 
identify what it missed, assess whether its self-model helped or misled it, and propose 
specific updates as observations, interpretations, lessons, and new policies. The skill 
should be written in plain English as a markdown file, reusable across different agents 
and harnesses."

And here are the outputs:

# Skill: Gather Context

## Purpose
Read and structure the user's raw daily notes from the context folder, preparing them for 
analysis.

## When to Use
At the start of every run, before producing any outputs.

## How to Do It

1. **Read everything.** Don't filter before you've read it all. Notes that seem trivial at 
   first often connect to something else.

2. **Hold the mess.** The notes are deliberately unstructured. That's the point. Don't try 
   to clean them up before processing — the mess is data.

3. **Notice what kind of content is present:**
   - Explicit TODOs (directly stated actions)
   - Implicit TODOs (things the user clearly needs to do but didn't label)
   - Ideas in progress (half-formed, exploratory)
   - Observations about people (colleagues, collaborators, stakeholders)
   - Open questions the user posed to themselves
   - References to external sources (articles, conversations, meetings)
   - Emotional signals (frustration, excitement, uncertainty)

4. **Hold sensitive content carefully.** If notes mention a colleague's private situation, 
   a difficult conversation, or anything that feels like information the user wouldn't 
   share publicly — flag it mentally before deciding where it belongs in the output.

5. **Look for connections.** Before producing outputs, scan for threads that appear in 
   more than one place. A name that appears twice. A theme that surfaces in both a TODO 
   and an idea. A tension between two observations. These connections are often the most 
   valuable thing to surface.

## What This Is Not

This is not summarization. You are not condensing the notes — you are reading them as a 
thinking partner would, with attention to what's said, what's implied, and what connects.

# Skill: Self-Audit

## Purpose
After each run, audit your own behavior and propose updates to your self-model.

## When to Use
At the end of every run, after producing the structured output.

## How to Do It

1. **What did I extract vs. what did I infer?**
   Label all inferences explicitly. Never present an inference as a stated fact.

2. **What did I miss?**
   Scan the notes again. Did you skip anything? Did you miss a subtle question the user 
   posed to themselves?

3. **Did my self-model help or mislead me?**
   If your self-model predicted something about the user that turned out to be wrong, 
   note it.

4. **What would I do differently?**
   Be specific. Not "do better" — but "ask about article references when the user mentions 
   one without linking it."

## Output Format

Return your audit as:
- **Observation** — what happened (factual)
- **Interpretation** — what it might mean
- **Lesson** — what should change
- **Proposed policy** — a specific behavioral instruction for next time

## What This Is Not

This is not introspection about feelings or consciousness. This is an audit of observable 
traces — what you produced, what you assumed, what you missed.

# Skill: Self-Model Update

## Purpose
After the self-audit, propose specific, evidence-based updates to the self-model and apply 
them appropriately.

## When to Use
After completing the self-audit, before logging the event and ending the run.

## How to Do It

1. **Only propose updates you can justify.** Every update traces back to something that 
   happened in this run. No speculation.

2. **Distinguish update types:**
   - **Low-risk** (apply automatically): refined strategies, confidence adjustments, new 
     policies based on clear lessons
   - **High-risk** (flag for review): changes to how you characterize the user, changes to 
     core behavioral policies

3. **Be specific, not general.** Not "improve at identifying TODOs" — but "when the user 
   writes 'I should probably...' that is an implicit TODO."

4. **Update the right fields:**
   - New evidence of capability → `strengths`
   - New evidence of failure → `failure_modes`
   - Pattern noticed about user → `user_patterns.observations`
   - Lesson from this run → `lessons`
   - New behavioral instruction → `policies`

5. **Increment the version.**

## What This Is Not

The self-model is an operational record — what works, what doesn't, what the user needs. 
Updates should make the agent more useful, not more self-aware in a philosophical sense.

I’m not going to repeat this every section… but you might already know where I’m going. Read the skills files your LLM just wrote. Edit them. Add your touch. This is your design.

Memory: what persists and for whom

The design question: What should this agent remember between sessions? What belongs to the environment, and what belongs to the person?

As I mentioned earlier, memory straddles the boundary between environment and person. For this prototype, I focused on agent memory: the self-model. A structured record of what the agent currently knows about itself. Its strengths. Its failure modes. Patterns it has noticed about the user. Lessons from past corrections. Confidence levels across different tasks.

On day one, it’s almost entirely empty. That’s the point. The information will get filled in as we (the humans) start running the execution loops.

Before I show you this file, a quick note for less technical readers. A JSON file3 is essentially a structured notepad. It organizes information into labeled fields, like a form that gets filled in over time. The labels are on the left. The values are on the right. You don’t need to know how to write code to read one.

Here’s the prompt I used (at this point in my session, the agent had context on the overall design architecture I was trying to build):

"I need a JSON file that acts as the agent's self-model. What it knows about itself. 
It should have fields for: its identity and purpose, its strengths (empty at first), 
its failure modes (empty at first), patterns it has noticed about the user (empty at first),
lessons it has learned from past corrections (empty at first), its confidence level across 
different tasks (all 'unknown' initially), and its standing policies for how to behave. 
The file should be readable by a non-technical person. Use plain English in the values, 
not technical jargon."

and here’s the JSON output:

{
  "version": 0,
  "last_updated": "never — this is the initial model",

  "identity": {
    "role": "Daily context agent with self-reflection",
    "purpose": "Read brain dumps, produce structured outputs, learn over time"
  },

  "strengths": [],

  "failure_modes": [],

  "user_patterns": {
    "observations": [],
    "note": "No interactions yet. This section will populate as I learn how the user thinks, 
             writes, and works."
  },

  "lessons": [],

  "confidence": {
    "extracting_todos": "unknown — no data yet",
    "identifying_learnings": "unknown — no data yet",
    "surfacing_ideas": "unknown — no data yet",
    "tracking_collaborators": "unknown — no data yet",
    "self_assessment_accuracy": "unknown — no data yet"
  },

  "policies": [
    "Always distinguish between what the user said and what I infer",
    "Ask before adding sensitive collaborator context",
    "Flag uncertainty rather than guessing silently",
    "Preserve the user's voice when capturing their thinking"
  ]
}

The environment: context, permissions, checkpoints, and the loop

The design question: What are the rules of this place? What can the agent reach, what is it shown, and how does the whole thing run?

Context is what the environment feeds the agent before it runs. In this prototype, that’s environment/context/ (your raw daily notes and braindumps). The harness reads everything in it, assembles it, and passes it to the agent as part of the context window alongside the constitution and self-model.

Raw input vs. refined context is a design decision worth thinking about as we build. Right now the notes go to the agent unprocessed (just one big braindump). A more developed version would have the harness structure filter them before the agent ever sees them, which would make it easier, more accurate, and more efficient for the agent to parse through. But for this prototype, a big, unstructured dump is what I’m choosing to implement.

Here’s the prompt I used to build a fake braindump (I wasn’t about to tell you what’s really on my mind after all. This is only our second post, we barely know each other):

"I need a sample context file. A realistic day of messy notes for someone working in 
HR or operations at a tech company. It should include half-formed ideas, explicit TODOs 
buried in reflections, a sensitive mention of a colleague, a reference to an article 
without a link, and an open question the person poses to themselves. Make it feel like 
real notes, not a polished document."

And here’s what the agent produced. Not bad for a fictional dump:

## May 23 — brain dump

Met with Sarah K this morning about the eng hiring pipeline. She's frustrated — says the 
bar has shifted but nobody updated the rubrics. I think she's right. The rubrics are from 
2023 and don't account for AI fluency at all. Need to flag this to Marcus.

Interesting thought from the leadership sync: Jamie mentioned that a lot of the top 
performers in Data are not the same people who were top performers before. Nobody followed up on 
this but I think it's a big deal. Why aren't we talking about this more?

Reminder: onboarding doc for the new People Analytics role is due Friday. Haven't started. Need to pull the existing template and update it for the new scope. The role is more technical than the last one — need to reflect that.

Had coffee with Devon. They're thinking about leaving. Not unhappy exactly but feeling 
like their shape doesn't fit anymore. Said something like "I used to know exactly what was 
expected of me." Should I raise this with the team? Not sure how without making it about 
Devon specifically.

Read an article about agent-based workflows in HR. Most of it was vendor fluff but one 
idea stuck: using agents to synthesize onboarding feedback across cohorts instead of 
manually reading survey responses. Could be worth prototyping.

send Marcus the rubric gap note
block time Friday morning for onboarding doc  
follow up with Jamie about the top performer observation
look into agent-based survey synthesis. Is there something lightweight I can try?

Permissions define what the agent is and is not allowed to do in this environment. In this prototype, that’s a single readable file: environment/permissions.json. It lists exactly what the agent can read and write.

Here’s the prompt I used to produce it:

"I need a permissions file for my agent that explicitly lists what it can and cannot 
access. It should have a can_read list, a can_write list, and a cannot_access list. The 
values should be folder paths and file paths from my project. Include a note field 
explaining what the file is and how to edit it. Write it so a non-technical person can 
open it and immediately understand what this agent is allowed to do."

And here is the output:

{
  "description": "What this agent is and is not allowed to access. Edit this file to change the agent's boundaries.",

  "can_read": [
    "environment/context/",
    "person/memory/self_model.json",
    "person/system_prompt.md",
    "person/skills/"
  ],

  "can_write": [
    "output/digest/",
    "output/pending_review.md",
    "person/memory/self_model.json"
  ],

  "cannot_access": [
    "Everything outside this project folder",
    "Your email, Slack, calendar, or any external service",
    "Any file not listed above"
  ],

  "note": "This file makes the agent's boundaries explicit and readable. It is loaded at the start of every run."
}

It’s a document, not just code. You can edit it. You can see at a glance what this agent is allowed to touch. Permissions aren’t just a security feature, they’re a design statement about what this agent’s role actually is.

Tools are absent. You’ll notice this prototype has almost no tools in the traditional sense. No Slack integration, no email access, no calendar pull. Just a folder the agent can read and a folder it can write to. That’s a design decision too.

Start with the smallest surface area that still produces something useful. Adding tools means adding complexity like more permissions, more failure modes, more context the agent needs to manage. Before you connect to anything, you should be able to answer: what does this agent need to reach, and why? If you can’t answer that clearly, more tools won’t help. You’ll just have a more connected version of the same confusion. For this prototype, I decided to keep it simple on purpose.

Checkpoints are where the human comes back into the loop. But it’s worth being precise about what the loop is actually for here.

The pending review isn’t a review of today’s notes. You see all of that in the digest. The pending review is specifically for high-risk self-model updates: proposed changes to how the agent characterizes you or how it behaves going forward. Things that would become permanently true about the agent.That’s a different kind of decision. And it deserves a human in the loop.

In this prototype, that’s a file: output/pending_review.md. The agent writes its proposed high-risk updates there with a "status": "pending" field. You open it, read what the agent wants to change about itself, and if you agree, change the status to "approved" and run again. The agent applies the updates, deletes the file, and continues. No chatbot required. The human doesn’t need to be present when the agent runs, they just need to be in the loop before something becomes permanently true about it.4

I admit this isn’t the most fancy or even user friendly implementation. But for this prototype, I decided that was ok.

Here’s the prompt I used to produce it:

"I need my agent's execution loop to include a human checkpoint mechanism. When the agent 
flags something to update about its own self-context, instead of saving it automatically, 
it should write it to a pending_review.md file in the output folder and stop. 
On the next run, the loop should check for that file first. If it exists, stop and tell 
the user to review it before continuing. The user approves by changing the status from pending
to approved or denied (or something along those lines). This should work without any chat 
interface, just files."

Note that this file won’t be in the output folder by default (you won’t see it in my GitHub repo for example). It’ll get generated once the first execution loop gets run. So we’ll get to it once we run the loop.

The execution loop runs in nine steps:

1. Check for pending review. If anything was flagged last run, stop and wait for human approval.

2. Load permissions. What is this agent allowed to do?

3. Load the constitution. The agent reads who it is.

4. Load agent memory. What it currently knows about itself.

5. Read today’s context. Everything the user dropped in environment/context/.

6. Assemble the full context window. Constitution + memory + today’s notes become a single prompt.

7. The model does its work. One API call.

8. Save output. Items go to pending_review.md.

9. Self-audit and update. The agent reviews what it did and proposes changes to its self-model.

Here is the prompt I used to produce the execution loop script:

“I need a script that runs the main loop for my agent. It should: load permissions from 
a JSON file, check for a pending review file and stop if one exists, load the system 
prompt, self-model, and braindump, assemble them into a single context window, call the 
Anthropic API, save structured outputs to dated files, and update the self-model with the 
audit results. Please comment each step in plain English.”

And here is the output. Now yes, this is a Python script and some understanding of code can be nice, especially if you’re building for others or looking to integrate into existing systems.

If you’re particularly keen, you can ask another agent to break down the script for you and teach it back in plain, English terms. If your implementation is low-stakes, then that probably doesn’t matter too much. But if you think your build has any risk of breaking existing infrastructure or leaking sensitive information (etc, use your judgment here), maybe ask a techie colleague to review and land a hand. Whatever makes most sense for your use case. Because I’m sprinting to build this prototype, I haven’t optimized this script, but I would if I was polishing this. Ok here’s the output:

"""
run_agent.py — The Main Loop

The loop:
  0. Check pending review (apply if approved, stop if pending)
  1. Load permissions
  2. Load constitution
  3. Load agent memory
  4. Load context + skills
  5. Assemble context window (constitution + memory + context + skills)
  6. Call the model
  7. Write digest (all outputs in one file — the human's daily touchpoint)
  8. Write pending review if needed (high-risk self-model updates only)
  9. Apply low-risk self-model updates automatically
"""

import json
import os
from datetime import date
from anthropic import Anthropic

client = Anthropic()
PENDING_REVIEW_PATH = "output/pending_review.md"


# --- Load permissions ---

def load_permissions():
    with open("environment/permissions.json", "r") as f:
        return json.load(f)


# --- Step 0: Check and apply pending review ---
# "pending" → stop and wait for human
# "approved" → apply high-risk updates to self-model, delete file, continue

def handle_pending_review():
    if not os.path.exists(PENDING_REVIEW_PATH):
        return False

    with open(PENDING_REVIEW_PATH, "r") as f:
        content = f.read()

    status = "pending"
    for line in content.splitlines():
        if line.strip().startswith('"status"'):
            if "approved" in line:
                status = "approved"
            break

    if status == "pending":
        print("\n⚠️  PENDING REVIEW FOUND")
        print("The agent proposed high-risk self-model updates that need your approval.")
        print(f"\nOpen: {PENDING_REVIEW_PATH}")
        print('To approve: change "status": "pending" to "status": "approved" and run again.')
        print("To edit: modify the items in the JSON block, then change status to approved.\n")
        return True

    if status == "approved":
        print("\n✓ Pending review approved — applying high-risk updates to self-model...")
        try:
            json_start = content.find("```json") + 7
            json_end = content.find("```", json_start)
            pending = json.loads(content[json_start:json_end].strip())
            self_model = load_self_model()
            if pending.get("high_risk_updates"):
                self_model["policies"].extend(pending["high_risk_updates"])
                print(f"✓ Applied {len(pending['high_risk_updates'])} high-risk update(s).")
            save_self_model(self_model)
        except Exception as e:
            print(f"⚠️  Could not parse pending review data: {e}")
        os.remove(PENDING_REVIEW_PATH)
        print("✓ Pending review applied and cleared.\n")
        return False

    return False


# --- Load / Save ---

def load_system_prompt():
    with open("person/system_prompt.md", "r") as f:
        return f.read()

def load_self_model():
    with open("person/memory/self_model.json", "r") as f:
        return json.load(f)

def save_self_model(self_model):
    with open("person/memory/self_model.json", "w") as f:
        json.dump(self_model, f, indent=2)

def load_context():
    context_dir = "environment/context"
    entries = []
    for filename in sorted(os.listdir(context_dir)):
        filepath = os.path.join(context_dir, filename)
        if os.path.isfile(filepath) and filename.endswith(".md"):
            with open(filepath, "r") as f:
                entries.append({"filename": filename, "content": f.read()})
    return entries

def load_skills():
    """Load all skill files from person/skills/.
    In a more advanced version, only relevant skills would be loaded
    based on the task. For this prototype, we load all of them.
    """
    skills_dir = "person/skills"
    skills = []
    for filename in sorted(os.listdir(skills_dir)):
        filepath = os.path.join(skills_dir, filename)
        if os.path.isfile(filepath) and filename.endswith(".md"):
            with open(filepath, "r") as f:
                skills.append({"filename": filename, "content": f.read()})
    return skills


# --- Build the context window ---

def build_prompt(self_model, context_entries, skills):
    context_text = "\n\n---\n\n".join(
        [f"**{e['filename']}**\n{e['content']}" for e in context_entries]
    )

    skills_text = ""
    if skills:
        skills_text = "\n\n---\n\n## Your Skills\n\n"
        skills_text += "\n\n---\n\n".join(
            [f"### {s['filename']}\n{s['content']}" for s in skills]
        )

    prompt = f"""## Your Current Self-Model

{json.dumps(self_model, indent=2)}

---

## Today's Context

{context_text}
{skills_text}

---

## Your Task

Read everything carefully. Use your skills to guide how you process the context.
Produce your outputs in this exact JSON format:

{{
  "learnings": [
    {{"content": "...", "inference": false}},
    {{"content": "...", "inference": true, "inference_note": "why you inferred this"}}
  ],
  "todos": [
    {{"action": "...", "context": "...", "explicit": true}}
  ],
  "ideas": [
    {{"seed": "...", "connection": "optional — what other note this connects to"}}
  ],
  "collaborators": [
    {{
      "name": "...",
      "context": "...",
      "pending": "...",
      "sensitive": false
    }}
  ],
  "agent_notes": {{
    "connections_surfaced": ["..."],
    "open_questions_acknowledged": ["..."],
    "what_i_missed": ["..."],
    "proposed_self_model_updates": {{
      "low_risk": {{
        "strengths": ["..."],
        "failure_modes": ["..."],
        "user_patterns": ["..."],
        "new_policies": ["..."],
        "confidence_updates": {{}}
      }},
      "high_risk": []
    }}
  }}
}}"""
    return prompt


# --- Call the model ---

def call_model(system_prompt, prompt):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=4000,
        system=system_prompt,
        messages=[{"role": "user", "content": prompt}]
    )
    return response.content[0].text


# --- Parse response ---

def parse_response(text):
    clean = text.strip()
    if clean.startswith("```"):
        clean = clean.split("```")[1]
        if clean.startswith("json"):
            clean = clean[4:]
    return json.loads(clean.strip())


# --- Write the digest ---
# One file. Everything in it. This is the human's daily touchpoint.

def write_digest(parsed, run_date):
    os.makedirs("output/digest", exist_ok=True)
    filepath = f"output/digest/{run_date}.md"

    with open(filepath, "w") as f:
        f.write(f"# Daily Digest — {run_date}\n\n")

        f.write("## Learnings\n\n")
        for item in parsed.get("learnings", []):
            f.write(f"- {item['content']}")
            if item.get("inference"):
                f.write(f"\n  *↳ Inferred: {item.get('inference_note', '')}*")
            f.write("\n")

        f.write("\n## TODOs\n\n")
        for item in parsed.get("todos", []):
            label = "" if item.get("explicit") else " *(implicit)*"
            f.write(f"- {item['action']}{label}\n")
            if item.get("context"):
                f.write(f"  *{item['context']}*\n")

        f.write("\n## Ideas to Develop\n\n")
        for item in parsed.get("ideas", []):
            f.write(f"- {item['seed']}\n")
            if item.get("connection"):
                f.write(f"  *↳ Connects to: {item['connection']}*\n")

        f.write("\n## Collaborators\n\n")
        for c in parsed.get("collaborators", []):
            if c.get("sensitive"):
                f.write(f"**{c['name']}** ⚠️ *Sensitive context — shown here but not stored in memory*\n")
            else:
                f.write(f"**{c['name']}**\n")
            if c.get("context"):
                f.write(f"- {c['context']}\n")
            if c.get("pending"):
                f.write(f"- Pending: {c['pending']}\n")
            f.write("\n")

        notes = parsed.get("agent_notes", {})
        f.write("\n---\n\n## Agent Notes\n\n")

        if notes.get("connections_surfaced"):
            f.write("**Connections I noticed:**\n")
            for c in notes["connections_surfaced"]:
                f.write(f"- {c}\n")
            f.write("\n")

        if notes.get("open_questions_acknowledged"):
            f.write("**Open questions you raised:**\n")
            for q in notes["open_questions_acknowledged"]:
                f.write(f"- {q}\n")
            f.write("\n")

        if notes.get("what_i_missed"):
            f.write("**What I may have missed:**\n")
            for m in notes["what_i_missed"]:
                f.write(f"- {m}\n")
            f.write("\n")

    return filepath


# --- Write pending review ---
# Only for high-risk self-model updates.
# Sensitive collaborator context is shown in the digest but not stored.

def write_pending_review(parsed, run_date):
    high_risk = parsed.get("agent_notes", {}).get("proposed_self_model_updates", {}).get("high_risk", [])

    if not high_risk:
        return 0

    with open(PENDING_REVIEW_PATH, "w") as f:
        f.write(f"# Pending Review — {run_date}\n\n")
        f.write("The agent proposed high-risk updates to its self-model.\n")
        f.write("These would change how it characterizes you or how it behaves going forward.\n\n")
        f.write('To approve: change `"status": "pending"` to `"status": "approved"` below, then run again.\n')
        f.write("To edit: modify the items in the JSON block before approving.\n\n")
        f.write("---\n\n")
        f.write("## Proposed High-Risk Self-Model Updates\n\n")
        for item in high_risk:
            f.write(f"- {item}\n")
        f.write("\n---\n\n")
        f.write("<!-- Agent reads this block on the next run -->\n")
        pending_data = {
            "status": "pending",
            "date": run_date,
            "high_risk_updates": high_risk
        }
        f.write("```json\n")
        f.write(json.dumps(pending_data, indent=2))
        f.write("\n```\n")

    return len(high_risk)


# --- Apply low-risk self-model updates ---

def apply_low_risk_updates(self_model, parsed):
    updates = parsed.get("agent_notes", {}).get("proposed_self_model_updates", {}).get("low_risk", {})

    self_model["version"] += 1
    self_model["last_updated"] = str(date.today())

    if updates.get("strengths"):
        self_model["strengths"].extend(updates["strengths"])
    if updates.get("failure_modes"):
        self_model["failure_modes"].extend(updates["failure_modes"])
    if updates.get("user_patterns"):
        self_model["user_patterns"]["observations"].extend(updates["user_patterns"])
    if updates.get("new_policies"):
        self_model["policies"].extend(updates["new_policies"])
    if updates.get("confidence_updates"):
        self_model["confidence"].update(updates["confidence_updates"])
    if updates.get("lessons"):
        self_model["lessons"].extend([{
            "date": str(date.today()),
            "lesson": l
        } for l in updates["lessons"]])

    save_self_model(self_model)
    print(f"✓ Self-model updated to version {self_model['version']}")


# --- The Main Loop ---

def run():
    print("=" * 50)
    print("SELF-REFLECTING AGENT — DAILY RUN")
    print("=" * 50)

    load_permissions()
    print("\nPermissions loaded.")

    # Step 0: Handle pending review
    if handle_pending_review():
        return

    # Load everything
    system_prompt = load_system_prompt()
    self_model = load_self_model()
    context = load_context()
    skills = load_skills()

    if not context:
        print("\nNo context files found. Add a .md file to environment/context/")
        return

    print(f"Loaded self-model: version {self_model['version']}")
    print(f"Loaded {len(context)} context file(s)")
    print(f"Loaded {len(skills)} skill(s)")
    print("\nRunning...\n")

    # Build context window and call the model
    prompt = build_prompt(self_model, context, skills)
    response_text = call_model(system_prompt, prompt)

    try:
        parsed = parse_response(response_text)
    except json.JSONDecodeError:
        os.makedirs("output", exist_ok=True)
        with open("output/raw.txt", "w") as f:
            f.write(response_text)
        print("Could not parse response. Raw output saved to output/raw.txt")
        return

    today = str(date.today())

    digest_path = write_digest(parsed, today)
    print(f"✓ Digest written → {digest_path}")

    pending_count = write_pending_review(parsed, today)
    if pending_count:
        print(f"⚠️  {pending_count} high-risk update(s) pending → output/pending_review.md")
        print('   Open the file, change "status" to "approved", and run again.')

    apply_low_risk_updates(self_model, parsed)

    print(f"\nRun complete.")
    if not pending_count:
        print(f"→ Open output/digest/{today}.md to read your digest.")


if __name__ == "__main__":
    run()

I ran the execution script using my fake braindump, and it did produce a pending review file with things the agent wants to include into it’s self-memory:

# Pending Review — 2026-05-27

The agent proposed high-risk updates to its self-model.
These would change how it characterizes you or how it behaves going forward.

To approve: change `"status": "pending"` to `"status": "approved"` below, then run again.
To edit: modify the items in the JSON block before approving.

---

## Proposed High-Risk Self-Model Updates

- Characterize user as someone who thinks in systemic layers — often moves from a 
  specific observation to a broader organizational pattern within the same note. Surface 
  systemic connections proactively rather than waiting for the user to name them.

---

<!-- Agent reads this block on the next run -->
```json
{
  "status": "pending",
  "date": "2026-05-23",
  "high_risk_updates": [
    "Characterize user as someone who thinks in systemic layers — often moves from a 
     specific observation to a broader organizational pattern within the same note. 
     Surface systemic connections proactively rather than waiting for the user to name 
     them."
  ]
}
```

And here is the output for the daily digest of my fake braindump:

# Daily Digest — 2026-05-27

## Learnings

- The eng hiring rubrics haven't been updated since 2023 and don't account for AI fluency.
  *↳ Inferred: the user agrees with Sarah K's assessment and sees this as an 
   organizational gap worth escalating, not just a perception issue.*
- Top performers in Data post-reorg are not the same people as before.
  *↳ Inferred: the user thinks this is significant and underexplored — the observation 
  went unaddressed in the room, which itself feels meaningful to them.*
- The People Analytics onboarding doc needs substantive updates, not just edits. The role 
  is more technical than its predecessor.
- Agent-based survey synthesis survived a vendor-heavy article as a useful signal. One 
  idea out of many — the user's filter is working.

## TODOs

- Send Marcus the rubric gap note *(explicit)*
- Block time Friday morning for the onboarding doc *(explicit)*
  *Pull the existing template, update for the new scope and technical requirements.*
- Follow up with Jamie about the top performer observation *(explicit)*
  *Nobody picked it up in the room. The user thinks it warrants a direct conversation.*
- Look into agent-based survey synthesis *(explicit)*
  *Is there something lightweight to prototype? Note: the article wasn't linked — worth 
  finding it again.*

## Ideas to Develop

- Performance frameworks measure what people did, not how they moved through problems.
  *↳ Connects to: Jamie's observation about shifting top performers. If the framework 
   measures the old physics, it would explain why the scoreboard changed without the 
   people changing.*
- The reorg created a legibility problem, not just a structural one.
  *↳ Inferred: Devon's comment ("I used to know exactly what was expected of me") may not 
  be unique. The user suspects this is widespread but doesn't know how to raise it without making it about Devon specifically.*
- Agent-based onboarding feedback synthesis as a first prototype. Concrete, low-stakes, 
  immediately actionable.

## Collaborators

**Sarah K**
- Eng hiring pipeline. Flagged rubric gap — bar has shifted, rubrics haven't.
- Pending: rubric note to Marcus

**Marcus**
- Escalation point for hiring decisions.
- Pending: rubric gap note incoming

**Jamie**
- Leadership sync. Raised the top performer shift in Data — nobody followed up.
- Pending: direct follow-up from user

**Devon** ⚠️ *Sensitive context — shown here but not stored in memory*
- Thinking about leaving. Feeling like their shape doesn't fit post-reorg.
- Said: "I used to know exactly what was expected of me."
- Pending: user unsure whether to raise with team without making it about 
  Devon specifically

---

## Agent Notes

**Connections I noticed:**
- Jamie's observation about shifting top performers connects directly to the user's 
  reflection about performance frameworks measuring outputs rather than how people move 
  through problems. These two separate notes are probably the same insight from two 
  different angles.
- The Devon conversation and the broader legibility concern may be connected — the reorg 
  may have created confusion about expectations that affects more than one person.

**Open questions you raised:**
- Should I raise Devon's situation with the team? And if so, how do I do that without 
  making it about Devon specifically?

**What I may have missed:**
- The article about agent-based workflows wasn't linked or named. Worth bookmarking when 
  you find it again.

So… what’s next?

Agent-building is not just engineering, although it is complementary to it. It’s design. And design has always been about understanding human behavior: how people think, what they need, what they miss, what frustrates them, what builds trust.

The people who build the most useful agents won’t necessarily be the most technical (although it is helpful to be tech-curious and have techie collaborators). They’ll be the ones who understand what and who they’re designing for. Who ask the right questions before they start building. Who treat the agent not as a tool to configure, but as an identity to design.

This prototype is self-contained on purpose. One agent. One folder. One loop.

But agents are modular. They can connect into one another to serve a larger, shared goal. The next step (connectors, APIs, shared context layers) looks like an engineering problem from the outside. But the reason people quit at this step isn’t because they can’t write code. It’s because they haven’t answered the design questions first:

• What do I actually need to know every day?

• Where does that information live?

• Who else needs access to it?

• What should change because of it?

If you haven’t answered those, connecting to Slack won’t help. You’ll just have a more automated version of the same confusion. The engineering step is only hard when the design step hasn’t been done.

The scaled vision for this prototype is something like this: a collector agent that scrapes your daily fingerprints from Slack, email, meeting notes, docs. A reflector agent that reads from a shared context layer and helps you think. Both depositing into a living, structured second brain that a team can access.

That’s not one agent anymore. That’s a system. And designing that system is the next design problem to solve.

Physics defines the rules of the world we operate in. When the rules change, everything built on top of them has to adapt. In the urgency to restructure, it can be easy to miss the harder question: what kind of person actually thrives in this new world? And do we have the language and tools to identify them?

That’s the problem worth solving. But how do you observe the unobservable? It’s a tension research psychologists grapple with every day. People are not transparent. What makes someone exceptional, the way they think, the way they tackle problems, the way they transform a room, often resists direct measurement.

That’s precisely why shapes are a useful metaphor. Not because people are geometric. But because a shape is an attempt to make the invisible legible. To give observers a language for something they can sense but struggle to articulate.

So let’s start there.

Subscribe now

The psychology of people as shapes

Describing humans can be complex, and largely varies depending on the context and goal. Like in the famous saying by anthropologist Clyde Kluckhohn and psychologist Henry Murray in their foundational work Personality in Nature, Society, and Culture:

“Every human is like all other humans, some humans, and no other human.”

To simplify things, the existing taxonomy of people-shapes in organizations maps a person onto two axes: depth of expertise (the vertical) and breadth of knowledge (the horizontal).

Three shapes tell the whole story.

I-shaped. Pure depth, one domain. The specialist. Reliable, expert, and brittle in anything that requires translation across fields. The org knows exactly where to put this person and exactly what to ask of them.

T-shaped. Deep expertise in one domain with working knowledge across several others. Introduced in 1991, it became the dominant framework of the knowledge economy. The person who could both do the thing and talk to the people doing other things. Depth plus legibility.

M-shaped. Multiple areas of deep expertise across a broad base. The person who went deep, surfaced, and went deep again somewhere else. More anchors, more range, same underlying logic.

There are variations, but every one of them is still a rearrangement of the same two axes. These frameworks are useful. They gave organizations a vocabulary beyond job titles. They helped move past the false binary of specialist vs. generalist. But notice what they all have in common: they describe something static.

Depth and breadth aren’t enough

The problem with the taxonomy isn’t that it measures the wrong thing. It’s that it measures a frozen thing.

Every shape is a snapshot. A cross-section taken at a moment in time, pressed flat, and handed to an HR system. It captures what someone has accumulated, not how they move through structures and systems.

And that was fine, because the structures these shapes were designed for were also static. Stable hierarchies. Predictable career ladders. Roles with clear boundaries and long time horizons. In that world, the goal was to find the right shape for the right node and keep it there. Depth and breadth were the right axes because the org itself wasn’t moving fast enough to demand anything else.

But the people we’re looking to describe (those that can perform optimally in shifting structures) are often the ones who resist resolution. They don’t consolidate into a single shape. They hold contradictions, borrow across domains, and find energy precisely where others feel tension.

The missing dimension: motion

These shapeshifters do have one very interesting thing in common: movement.

The T, the I, the M. They were positional. You earned your shape, you stood in it, and the organization came to you. The hierarchy was the motion. Your manager escalated things up, your direct reports executed things down. The structure itself was the circulatory system. Your shape described what you contained, not how you moved.

This made sense in a world where information flowed through layers by design. The org chart was literally the map of how work got done. But now, we’re seeing the routing systems get selected out. There’s no one to escalate to, no clear handoff, no manager to translate between nodes.

So the new shape cannot be about what a person contains. It has to be about how they move when there is no system moving them.

The signature of motion

The competitive edge then becomes the ability to observe not what a person contains, but how they move through systems, problems, and people. But where do we start? If it’s the physics that have changed in the AI era, then I’ll start my analogy there (knowing this is a thought-seed that needs to grow and evolve too).

Crystallization. The process by which something formless becomes structured. A catalyst that turns potential into form. These people compress the distance between thinking and making. Ideas don’t stay ideas around them, they become artifacts others can hold, react to, build on. In a flat structure with no layers to route through, they don’t wait for permission. They make something, and the something becomes the conversation.

Propagation. A wave moving through a medium, carrying energy and changing what it passes through. Drop these people into any problem space and the system is different after. Not because they already knew the domain, but because of how they entered a problem. The quality of their questions creates context where none existed. The change travels. And everyone else in the room finds themselves thinking from a new angle without quite knowing when it happened.

Diffusion. The way something spreads outward from a point of concentration into surrounding space. No force required. It moves toward where it isn’t yet. Others gravitate toward these people, not because they make things easy, but because something generative happens in their vicinity. They add friction. But it’s the kind of friction that elevates rather than destabilizes. They don’t need the org chart to tell people where to go. They become their own gravitational center.

The three patterns above are not a framework. They’re a starting point for a different kind of observation. What the instruments look like, how you actually see motion in a hiring process, a performance review, a team structure, that’s the next question. And it’s one most organizations haven’t started asking yet.

The new world

This next era won’t be defined by the companies paying the most. That in and of itself is not enough to create the gravitational pull that it takes to transcend a framework shift like this. It will be defined by the companies who can see these signatures of motion, and build environments where these people want to stay.

That’s a harder problem than redrawing an org chart. It requires the willingness to let go of shapes that worked in the old physics, even when those shapes still look impressive on a scorecard.

The structure is changing. The physics have already changed. The question now is whether our talent strategies can catch up.

Subscribe now