The Genie Tax

AI can increase what you can produce before it increases what you can judge

People can make something work before they can tell whether they built the right thing, what deserves trust, which rabbit hole matters, or how the system will survive another person's use.

There are a few layers here. The appearance of "something working" is not 1:1 guaranteed to be what you think of "actually working." And AI agents excel at bullshiting you.

These tools are little gremlins that cut corners, make an assumption you never would and take the path of least resistance when that path is intuitively the wrong way to go.

If you treat your AI like a classic Genie in a Lamp, something that is bound to serve you but you know you should not trust, it all starts to click into place.

This in part due to the fundamental way LLMs work (look up reward hacking if you want to learn more), but practically that doesn't matter, the feeling of "oh this is super powerful I can do so much more but its hard to trust it" does.

Some real quotes from office hours that are representative:

• “I can build it, but I cannot tell if I built it correctly.”
• “It kind of escapes our understanding.”
• “I do not want a house of cards.”
• “Where did we actually move the needle?”

Repeatedly, we are forced to choose between moving fast and understanding what you built.

Production capacity can outrun the ability to tell:

• whether this is the right thing to build
• whether it is being built the right way
• whether an unseen technical or business constraint changes the answer
• which rabbit hole deserves attention
• whether the impressive result is becoming a house of cards

As murky as a problem it may seem, upon reflection it makes sense. Everyone is at the edge of their understanding. And this technology is brand new. Like 3 years is nothing.

The internet itself is decades old at this point and you could very easily make an argument that we are still figuring out how to make it work (do we really want it causing all this polarization?). It is going to take many more years to figure this stuff out.

If you are the edge of your understanding, learning by doing and using a new technology that inherently allows you to create more than you're able to effectively judge, what else could we possibly expect to happen?

The Genie Tax + Productive Doomscrolling creates a really weird overall experience; and the term that comes to mind here is FOMO.

The Genie Tax + Productive Doomscrolling = Technical FOMO

Fear of missing out is the lie of optionality. The lie of optionality is why the bottomless social feed sucks, why my single friends tell me about how awful endless dating apps feel, why when you're at a restaurant with too many menu options creates paralysis.

Analysis by paralysis + perfectionism. The idea that there could be something just around the corner, without any real basis for that being the case.

How does this apply to creating using AI?

Technical FOMO: the overall worry that there is a better way to build this thing that I don't know about.

AI lets do build beyond what I know, so what does it let me do that I just don't know what to ask it? Or what else should I be building that I'm not doing. Or what new AI framework, or tooling or whatever that is currently hot on twitter should immediately drop everything to do go test out because "trust me bro this is the one that'll solve all your problems for you."

Not a grounded known, better model or architecture competing with the current build, but the ephemeral fear that some unknown better way of doing this exists just outside your view.

*The feeling is: I could be doing this better, but I do not know how, or even what “better” would be. There is no concrete alternative to evaluate. The imagined possibility is more vivid than the evidence available from the real system in front of you.

This creates a double bind: the we're all looking for enough certainty to know that an unseen superior path is not being missed, but that certainty is unavailable in advance.

It is like being in a massive pitch black room with just a tiny weak flashlight. You can only see so far in front of you and you keep bumping into walls, staircases and hallways that loop back on themselves.

All the while, some voice on a loudspeaker periodically says "dude if you try this new flashlight you can see so much farther" but when you get said new flashlight its effectively the same as the one you had before, maybe a little brighter or maybe even worse but often times just differently shaped.

Over time the new flashlights you get do get better, but you realize that just makes you see how truly massive the room is and how little you've explored.

But ultimately you still need to build and ship. Both for yourself, for your end business impact, you need to bump around the room and learn to actually figure out how to navigate out of that dark room.

So how do you find the right balance between building to achieve that end business outcome or just get the thing done and learn how to do something better?

Alleviating Technical FOMO

How to Effectively Pay the Genie Tax

Rule Number One: Do everything you can to keep the Genie Honest.

A good context System both keep the Genie honest and make sure it understands exactly what you want to happen and what good looks like.

Keeping the Genie honest and on track can use audit chains, interlinking logic systems (those knowledge graphs that you are starting to see everywhere), version snapshots and more. Full chart:

The real technical tactics and frameworks I use their matching human capabilities:

These practices do not guarantee that the system is right. They make it possible to inspect, trust selectively, catch errors, and correct the system without losing the thread. That is the real source of peace of mind.

How to Address Productive Doomscrolling

Number One Rule: The less context switching the better. Focus.

Instead of running multiple agents across different, unrelated projects, run multiple agents on different parts of a single project.

Never create a situation where an agent can demand your attention. Don't turn on notifications when an agent finishes work. It isn't a person, it has no time to waste, it will not get upset, it can just sit there until you get to it.

Spend more time planning up front so it can run autonomously for longer. Clarity of thought and how well you communicate what you want and why is the the bottleneck.

Give it tools to verify its own work:

• Deterministic code: Test-driven-development, smoke testing, UI testing via computer use
• Subjective content/context: hand-curated example of what good looks like

You can grow your ability to context switch like a muscle, it just costs attention span. Purposefully find ways to train your attention span to switch between rapid context switching and deep focused attention.

Literally playing Minecraft or another low context switching video game, or a movie, or similar way to spend your time counts.

Do not add actual doomscrolling when you are waiting for agents to finish. Find a different way to fill that intermediate time if you are going to context switch. Productive doomscrolling and actual doomscrolling just fries your attention and brain (I am speaking from experience here trust me).

It is better to just stop when you are too tired to keep working.

How to Alleviate the Emotional Side of Technical FOMO

Number One rule: Put it into perspective.

Step back and remember you don't need to know it all.

You will not and cannot know it all and try every single possible path. There has been more knowledge than we could effectively action basically since the printing press.

To put this problem into perspective, in the 1940's Vannevar Bush, who was like if you combined Steve Jobs and Oppenheimer into one person, wrote about this problem. (Bush was a titan a legendary technological visionary - you should go read about him since that description is only partially accurate)

He literally wrote an open call to American scientists immediately after WWII saying basically "hey now that the war is over we should focus on this problem, since its probably the biggest one that we could solve to benefit all of science."

And now that problem has gone stratospheric, it is orders of magnitude greater than when he wrote that article. And technical FOMO, just like regular FOMO, is largely an emotional affliction.

Accept you cannot possibly become an expert in every single topic/technique/whatever.

The first half of the solution here is accepting that you are limited and making peace with it.

But the limitation means what you do choose to study, experiment and work with are meaningful differentiators. It also means you get to stop hurrying around from each new shiny AI release to the next, allowing you to slow down and focus on the actual problems in front of you.

Perfect is the enemy of great and done. Judgment develops by finishing, using, inspecting, and maintaining a concrete systems, and by comparing judgment with other practitioners, not by eliminating every hypothetical unknown.

The second half is remembering you don't need to know it all to get practical benefits.

The same way you don't need to know exactly how the engine in your car works to drive it, you don't need to know every single detail of the underlying AI systems and systems we build using them to use them to create value with them.

Abstraction, knowing how to operate a steering wheel but to drive a car but not needing to be a mechanic, is what makes powerful technology usable.

The Context Steering Wheel

Accepting that you cannot see the whole room does not mean stumbling around blindly. It changes what I need from the system.

You do not need a Context OS that can prove I found the best possible model, architecture, or workflow. That is just technical FOMO sneaking back in through the side door.

*You need a system that makes the next decision inspectable. What are you actually trying to accomplish?

What context is directing the work? Why does the system believe what it believes? What changed? How will you recognize when I am wrong, and can you recover without starting over**

That is what I mean by making AI steerable. I've landed this approach from years of building and heavy borrowing from Epistemology (which just means studying what you can and cannot actually "know"). This is also how we pay the Genie tax. And just like you pay real taxes every year, you gotta keep the Genie tax paid or bad things start to happen.

A good context system does not eliminate uncertainty. It stops uncertainty from remaining ambient. You convert ambient uncertainty into statements that can be falsified, traced and retrieved.

This is where the epistemology comes in. A whole lot of the study knowledge is about whether or not a statement can even be evaluated, can we even get to a true or false? It is very useful.

That is what it means when something is falsifiable or unfalsifiable, an unfalsifiable statement is as good as saying nothing, or even worse since it is confusing.

For example, “the coin will land on heads” is falsifiable. Flip it and you will find out.

“The coin will land however fate intends” is not. Heads or tails, the claim survives.

An unfalsifiable claim gives you no result that would prove it wrong, so you cannot use it to detect failure or correct course.

A more specific GTM x AI example would be "the system used the current ICP in this file to exclude companies with fewer than 50 employees” is falsifiable. You can inspect the source, its version, and the resulting output."

“The system understands our strategy” is not. What evidence would prove that statement wrong? If every good output confirms that the system understands you, while every bad output gets blamed on the prompt, the model, or the user, the claim can survive any result.

If we apply this sort of thinking to a full context system, the more falsifiable the claims in a system the better. It is like a chain, if even just one claim in a chain of claims is off, the chain collapses. A chain is only as strong as its weakest link.

This is how we keep the Genie honest.

We strengthen and reinforce our chain by turning unverified claims and implicit tribal knowledge into visible context:

• each backed by evidence
• with the reasoning behind decisions
• snapshot into explicit versions
• with defined owners

And a feedback learning loop.

In practice, that means doing three things:

• bounding the use case so I can act on the problem in front of me instead of every hypothetical possibility;
• preserving the trail from evidence to judgment to output so the system can change without losing what it has learned;
• making ownership, review, and dependencies explicit when another person begins changing or relying on the system.

The first helps me decide where to point the system. The second helps me keep it pointed there as the world changes. The third lets other people use it without silently breaking the judgment that made it valuable.

A system that works for you can still fail when another person enters it

Single player context systems are far easier to build and maintain than ones built for multiple users.

Personalized software means making it better for persons' preferences, often at the expense of general usability. You made it fit how you think, not how others do. This is the Personalization Bargain.

I have personally experienced this multiple times. And standing over the shoulder of users during client work has made it painfully obvious.

A context system that is not architected for multiple users can go from being was tremendously useful in the first user's hands to unwieldy and unreliable with people updating certain parts with others fall out of date.

It can be very hard to hard to hand somebody your system without losing power, decaying, or breaking since it is so tailored to your needs.

This problem is becoming more obvious, and painful, as more companies adopt AI. As AI spreads across your company, shared context becomes the constraint.

One team updates the ideal customer profile while another uses an old version.

Buyer language stays trapped in calls. Product decisions lose the evidence and reasoning behind them that makes the decision making process self-evident and reusable later.

But more often than not, these learnings are trapped with the person or team that earned them. Sharing learnings is 1:1, ad hoc and time consuming. This is the Alignment Tax.

Ideally, every campaign, customer call, product decision, and workflow teaches your company something, and a well architected context system can capture and compound learnings making one teams output another's starting point. A compounding learning loop.

The Alignment Tax has Always Existed when People worked together

Remember the first time you learned how to use a file system? Like save a word doc somewhere?

For me, it was in Mr. Barker's elementary-school computer lab. We spent an entire class learning how to save a Word document to the E-drive - the network drive connecting every computer in the room.

Each student had a folder. If you clicked in and out enough times, there was no real-time refresh on Windows Vista, you could watch the other folders appear.

You had your own folder, and every other student had one as well. There was a simple set of rules that Mr. Barker taught us (ex: don't edit someone else's folder without their permission) along with a standard centralized naming convention and permissioning.

A multi-user context system is a lot like the E drive. They're both made up of files, and when you add more people to it you realize you need to think about how can edit what, why and what process should we use to work together effectively.

Let's say that some students want to work together on a study guide in the E drive, how can we create some simple rules for them so it is easy for them to work together? So simple even 5th graders can use it.

Let's think it through:

• William is the owner of the study guide. Lets say this is a study guide for their Spanish class.
• Jacob can submit a version of the study guide, adding a section on how to conjugate irregular verbs.
• William can see the new section in the doc as a proposed change. He reviews it to make sure it actually makes sense.
• William is satisfied with the change so he approves the change and the full document, with that new version is released. It is a release.

Owners review versions to cut releases. Four steps.

Centralized standards and permissions enables decentralized collaboration and learning.

The more formal name for this is Federation (like how the United States is a Federal Republic, there is one federal government and each state can manage its own local business)

A personal context system can rely on decisions that remain inside its builder's head. The moment another person depends on it, those invisible decisions become questions of ownership, permissions, trust, and maintenance.

That is the core multiplayer problem. I unpack the complete architecture—from files and permissions through Git, releases, and knowledge dependencies—in the longer E-drive article.

This sort of explicit context lifecycle management is how we get compound learning, both at the single user and multi player levels. More context does not automatically create compounding learning.

The system will not automatically learn on its own, it will make it easier for you to learn. It is up to you to decide what is worth learning or not.

Why do these Mechanics Work?

Have you ever seen a Studio Ghibli movie? They are singular in their ability to make magical worlds feel real. Hayao Miyazaki purposefully lingers in small moments, contrasting against huge moments of action. These contrasts make the action more believable, since they are grounded against something.

Miyazaki also does this purposefully when showing technology in his films. Writing in 1996, Miyazaki framed the problem more bluntly:

“In Japan today, animated TV shows filled with all kinds of fancy robot-like mechanical creations are all the rage. I have certainly drawn lots of mecha—or mechanical things—myself, but the general theme of currently popular shows seems to be that the protagonist jumps into a giant machine he couldn’t possibly have created on his own, battles the enemy in it, and then boasts about winning. I frankly hate these kinds of shows.

“[…] For me, in a truly successful mecha show, the protagonist should struggle to build his own machine. He should fix it when it breaks down, and he should have to operate it himself.

“In modern society, humans have become slaves to machines—so much so that machines currently hold the keys to our collective fate. […]

“Even if only one person operates a specific machine, that machine presumably required multiple designers and mechanics to reach the point of being operational. In the world of fiction, I believe that we should have to depict this background to give the machines an air of reality.”

Miyazaki’s point is not that machines should be less powerful. It is that the human being should remain the protagonist - and that showing the building, maintenance, and collective effort behind the machine is what makes its power believable.

This makes it believable because this how technology actually works. We know this intuitively, but since much of it is out of sight out of mind, we forget.

Miyazaki uses this thinking to create convincing illusions to tell fantastical stories.

We can embrace this principle not to create an illusion, but remind ourselves that the way we engage with the technology of our day is still up for us to decide.

If you want to technology to work for you, you must dedicate time and energy to learn how to wield it with intention to serve your purpose.

Do we abdicate our right to agency? Or do we use AI as the miraculous tool that it is to extend our agency, amplify our insight and create?

Not everyone needs to build context systems nor will they, just how many don't know how exactly how the engine in their cars works, but there will always be a need for the mechanics who do.

You need to tell it where to go. The clarity of your thought process and how well you communicate as explicit technical context directly determines how well the AI works for you.

Maintenance is not simply a boring tax around the miracle. It is what makes the miracle belong to you.

Context Cohorts: Learn how to Build Production Context Systems Together

It is such an exciting time to be building. There are big problems to solve to make sure AI truly serves our needs.

Context Cohorts is for the mechanics who do.

And I want to build more with others. I am grateful for my service clients, partners and other practitioners who I get to share learnings and build friendships with. But it can still get lonely, and hard to know when you're wasting your time building off a cliff because of the Genie Tax or you're onto something.

This is the inspiration for Context Cohorts. A hands on learning workshop for Applied AI and GTM engineering practitioners who are excited about context who are actively building and want to level up and learn with other's who are just as excited as you are.

Production systems are multi-user systems and these systems, using the system to mean include both the technical system on the screen and the people the system serves, have emergent behavior you cannot mock.

I can publish the best practices I’ve learned building these systems. What I cannot do alone is simulate a multiplayer context system that you can participate in. There is no better learning than learning by doing.

First. I'll teach you the best practices I learned building these systems, how to architect them, how to maintain them and what really matters for using them to drive end business outcomes.

Then together, we’ll build and operate a shared Context OS around our best work: contributing, reviewing, assigning ownership, cutting releases, and seeing what happens when other capable people begin depending on what we create.

By building and working in a multiplayer context system you'll learn how these things actually feel in a way that copy pasting a template will never give you.

I expect it to be very fun. I also expect to learn a lot myself! That's like 50% why I want to do this haha

This is for you if you've already built your own context system, or maybe just tried building one, and are now asking questions like:

• How do I share this and work on it with the rest of my team? my clients? 
• How do I maintain this thing? When do I need to clean it up?
• What makes a good skill? How do I know when something should be a skill, an app or automation I build or just a regular markdown file?
• If I do work on this with others, who gets access to what and why? How can we collaborate easily?

That is what we will practice in this workshop. The workshop is therefore a live test:

• each participant improves one personal Context OS use case;
• participants enter a seeded shared repository immediately after Session 1;
• after Session 2, they begin contributing, reviewing, and learning from one another;
• the cohort experiences the ownership, drift, permissions, review, release, and dependency problems rather than merely hearing about them;
• the final sessions turn the experience into adoption and continued practice.

I will be dedicating real bandwidth to make sure this is a success and charging for it. Spots will be limited and I'll be curating tightly so everyone gets the best possible experience.

Learn more and apply to join Context Cohorts.