The Oldest Trade in the World Is Coming for Compute

Thanks to Makoto Eyre I’ve been reading The World for Sale, the Javier Blas and Jack Farchy book about the commodity trading houses. It confirms one of my core beliefs: the most reliable way to make money is inequality of information.

Think about how traders actually make their money. I know something about the wheat harvest in the Americas that you do not, because I did more research, or I bought better satellite imagery, or I have people on the ground. So I buy or sell the futures and take the spread between what I know and what the market knows. Oil was the giant version of this: a huge boom in demand layered over massive inequality in supply, demand, market access, and even basic knowledge of who had what kind of crude where. The traders who closed those information gaps, one contract at a time, made billions doing it.

Here is the thing though. My drive in understanding this is not to recreate the commodity traders’ billions. Technically, I wouldn’t turn that down, but okay, whatever. My drive is the opposite trade: find where the inefficiencies of the market are, because if you can balance the inequality of information, if more people can see what only the traders used to see, the frictional cost that gets skimmed off every transaction shrinks. And when the friction disappears, the end product gets cheaper. That is the whole arc: equal information leads to efficient markets leads to cheaper everything. The traders monetize the gap, and the consumers pay.

The newest inefficient market

Hold that principle and look at AI.

The demand explosion is not one market, it is a whole stack of them: compute itself, the chips that produce it, the racks and components that fill the data centers, the data centers themselves, the interconnect that ties them together, and the power that feeds all of it. Every layer of that stack is running hot with demand, and every layer is full of exactly the kind of information inequality the commodity traders would recognize from a hundred yards away. Who has capacity, who needs it, what an H100 hour actually clears at today versus what you are quoted: that spread is where the friction lives.

So the natural question becomes: does this stack get commoditized, and who builds the market?

It’s already happening

That question walked straight into an episode of the Moonshots podcast I was listening to (episode 278), which features Kush Bavaria, the 23-year-old co-founder and CEO of a company called Ornn. What Ornn is building is the infrastructure to trade AI compute as a commodity: live price indices across the GPU rental market, tracking what an hour of H100 or B200 actually costs, and the financial plumbing on top.

It is live today, in an early form. You can already take positions on GPU compute prices on Kalshi against Ornn’s index, though honestly the market there is thin: you can bet where the price of GPU compute lands at the end of a month, but there is no real futures market yet, no serious hedging instrument. That is coming. Ornn is working on cleared compute futures with Intercontinental Exchange, and Kalshi’s own CEO is now calling compute “the new oil” and racing to build the forward curve.

Sit with the shape of that for a second. The book on my nightstand is about the last century’s masters of information inequality. The podcast in my ears is about this decade’s attempt to build the exchange where compute trades like wheat. My brain went immediately to the space between them.

Steeper than oil

Here is the part that has my attention. Go look at oil’s actual price history. In 1970, a barrel went for about three dollars. The 1973 embargo quadrupled it to twelve in a matter of months, and the world treated that as a full-blown crisis. By 1980 it had touched the mid thirties, and $25 oil, a number that would have been unheard of a decade earlier, was suddenly the floor. Then in 2008 it spiked to $147, and has never looked back. This spring it spiked to $120, and today it trades near ninety: three and a half times that unheard-of number, and almost thirty times over what for years was “normal”. That is what it looks like when a demand curve outruns the market’s ability to organize supply.

My big takeaway: the demand curve for compute is accelerating faster than the demand for oil ever did. Oil demand grew with economies and new industries, a few percent a year, and still produced shocks. Compute demand compounds with the AI buildout itself. Every model generation, every data center, every agent deployment adds load, and the buildout is speeding up, not settling. By January we’ll be seeing a new model release every day. The price signal is already twitchy in a way oil took decades to become: an hour of B200 compute peaked at $6.11 at the end of May and traded at $4.22 three weeks later, a 31 percent move in under a month. Oil needed an embargo to move like that. Compute did it in a normal June.

A market with that demand curve, that volatility, and no futures curve yet is the purest information-inequality setup since the tanker traders of the seventies. The people with better information about capacity, load, and power are going to take trader profits out of it. Which is exactly why the equalizing infrastructure, the public price, the index, the forward curve, matters more here than it ever did for oil. The steeper the demand curve, the bigger the frictional cost of unequal information, and the bigger the payoff for everyone downstream when that information gets equalized.

I Asked for Yet Another Task List. I Got Called Out Instead.

I just got humbled by a system I built.

Some background. First, I needed to transition my recording, transcription, routing, filing, and dashboard system, the whole stack that caught everything I said and thought and put it somewhere useful. Second, I saw this post on X. So, in typical fashion, I started recreating my whole system. There had been some problems with the old version, but that’s something to learn from, right?

I have a running session with Claude Code where I built the thing (my new goto – I love the desktop app, I live in it now). Over the past two weeks I have steadily evolved it. Voice captures get transcribed, routed, and filed a few times a day. A daily note. A dashboard. A pipeline that tracks blog posts by status. I keep adding stuff to it, because that’s what I do. And there aren’t any guardrails to keep me from doing that.

Or so I thought.

The bedtime prompt

Last night I hit a wall. The ingestion engine kept balking every time I captured a todo for myself. Things like “follow up on that last call with a note about the pizza place in NYC,” or “reach out to a friend in three weeks once he decides between a job and contracting.” It had no place to categorize todo items. Projects were covered. Blog posts were covered. The little things I just need to do had nowhere to live.

So I did what I do now. Before going to bed, I wrote out a significant prompt: research the successes and failures of todo tools, go through my archive and look at the three different todo systems I have built over the past year that have all gone fallow and understand why they stopped getting used, think hard about what I have that is working, was working, or never worked, compare all of that with the external research, and build me a plan for capturing todos. Then I went to bed.

Yes, I was literally commissioning “yet another task list”. The fourth in a year. Keep that in mind.

The Sunday thing

When I got up and reviewed the plan over coffee, it was good. Real research, honest analysis of why my systems die. Claude’s finding: every todo system dies at one of three points, capture friction, gardening burden, or missing pressure. Nothing nags, so it rots.

But one line stopped me. In describing the scaffolding I already have, the plan mentioned my daily note and “Sunday synthesis” as the pressure that keeps the system alive.

My first thought: what is that Sunday thing? I never looked at that.

Sit with that for a second. The pressure mechanism of my system was a report I did not know existed.

So I went and found it. And the tone and accuracy of the synthesis blew me away. Like, for real. Here is how it opened:

“What you did this week was spec and scaffold. What you did not do was write a post. Every committed post still sits in seed or drafting, and by your own note on each card, each one is a single editing pass from shipped.”

Some of those points are already handled, it was Thursday after all, and I shipped by just doing the work. But wow. And here is the key point: I never defined this report. Claude created the entire Sunday synthesis, the schedule, the format, the tone, from our original spec discussion about what I was trying to build. I asked for a filing system. It decided I also needed a mirror.

The accountability buddy

This made me think. The real value of this system is not the notes, or the second brain, or the task lists, or the pipeline that goes from idea to spec to review to build to test to deploy. Those are all table stakes now. Any of us can vibe code that stack in a weekend.

The value of the system is the accountability buddy. The thing that reads everything I actually did, compares it against everything I said I would do, and asks the uncomfortable question on Sunday whether I am ready for it or not. That is a pressure I need. And it only works if I look at it. If I never open the report, I will never change, and the whole beautiful machine is just scaffolding around work that is not happening.

I am wallowing in the last question it asked me, and I will leave it here without comment, because it deserves the last word:

“You spent the week building things to hold the work instead of making that pass. What is the pass waiting for that the scaffolding is standing in for?”

This Would Be So Much Better, but I Didn’t Have the Time

I’ve been building an office golf pool with Claude Code. It’s called Pin High Duel, and the mechanics are simple: take the tournament field, split the golfers into groups, and everybody picks one golfer from each group. The pool creator gets to pick how many groups are in the pool.  Best combined finish wins.

The interesting engineering question is hiding in the middle of that sentence: how do you split a field of golfers, usually 156, into fair groups?

Claude Code was happily off building a model for it. Multiple modes, balancing logic, handling for every conceivable edge case. It worked. It was tested. It was more code than the problem deserved, and I could not have told you that yet, because I hadn’t really looked.

Then, as I was reviewing the PR, decades of pattern matching tapped me on the shoulder, and I typed one sentence: it should be field divided by picks with a max of 10 [golfers per group].

The reply came back instantly: “That’s a cleaner spec than what I built – and it actually simplifies the code into one formula instead of two modes.” Each group holds field divided by picks golfers, capped at 10, and the last group takes whatever’s left. One formula no matter how many groups your pool is set up for. The two modes and all of their edge cases just evaporated.

(The pool is real, by the way. You can play here: pinhighduel.com. Bring your bracket instincts, and until I get Stripe configured you can set up a pool and play for free!)

Recognizing simple is easy, finding it is hard

That exchange stuck with me, and not as a gotcha about AI. Claude did nothing wrong. It built exactly what I asked for, quickly and correctly. And notice what happened when I offered the simpler shape: it recognized it instantly, called it cleaner than its own work, and rewrote without a flinch. Recognizing simple is easy. Finding simple is the hard part.

Finding it is a skill that takes decades, and it did not come from coding. It is the skill of bringing the simple out of the complex, and it shows up everywhere: in math, in code, in org design, in test harnesses (in personal life!). The brute force version of each of those exists and mostly works. More terms, more branches, more boxes, more cases. The elegant version does the same job with less, and getting there is never the first draft.

It is not a common skill in people either, let’s be honest. But right now it looks like one of the telling differences between AI capability and human experience. The tools generate. Experience removes excess until the statue appears.

The shorter email

One of my mentors, Joe Austin, had a line I’ve used for years: “I would have written a shorter email, but I didn’t have the time.” (The joke is older than email, Pascal usually gets the credit, but Joe is the one who made it stick for me.)

I use it constantly because it names something true: short is not the lazy version, short is the expensive version. Getting a message, a design, or a function down to its core essential bits without losing the context takes thought, wisdom, experience, and time. The long version is what you produce on the way to understanding. The short version is what you produce after working through it.

Volume is now free

Here is why this matters more today than it did five years ago. With vibe coding and tools like Claude Code, GitHub Copilot, and Cursor, writing volumes of code has become incredibly easy. Volume is now free. Anyone can produce ten thousand working lines before lunch, and a lot of it will even be good.

Which means the scarce skill has flipped. It used to be hard to produce and easy to want less. Now it is easy to produce, and the rare, senior level move is the subtraction: the person who looks at the two modes and the balancing logic and says, quietly, it should be field divided by picks with a max of 10.

There is something amazing about the simplest solution that actually works. It is beautiful in a way that sprawling, technically correct code never is, closer to artwork than engineering. You know it when you see it, the same way Claude knew it when I typed it.

The tools will keep getting better, and honestly, I expect they will learn some of this. But today? Hold on to the people who can delete. They will write you a shorter function, if you give them the time.

The CIO, the CTO: Two Jobs That AI Rewrites

A short history of the two roles, and why the real story isn’t whether they merge. It’s how AI transforms both, pulling one toward the CFO and forcing the other to change its middle letter.

A couple of times a month, somebody asks me a version of the same question. With AI changing everything, should the CIO and the CTO become one job? Or should they split further apart?  In an AI Native world, do you still need both roles?

It is the wrong question. It argues about boxes on a chart when the thing actually moving is the work. The more interesting question is how AI transforms each role.

Where the CIO actually came from

Nobody set out to invent the CIO. The role backed into existence.

In the 1950s through the 1970s, a company that owned a computer (yes kids some companies had “a computer”) had a Data Processing Manager. That person ran the mainframe, made sure payroll and inventory came out the other end, and kept the machine in the cold room humming. It was a deeply technical and operational job. It wasn’t strategic, it was closer to running the boiler room than running the business.

As the systems sprawled, the title grew up into Management Information Systems Director. Same core job, wider scope. You were not just keeping the machine alive; you were implementing business applications and occasionally handing management a report they could not have produced themselves.

The term “Chief Information Officer” showed up in 1981 in a book by William Synnott and William Gruber. Their idea was radical for the time: that information itself was a corporate resource, on par with capital and people, and it deserved a seat next to the CFO and the COO. The CIO was the person who managed information as an asset.

Then four decades of forcing functions did the rest. ERP. Y2K. The internet. Email. Security becoming existential. Cloud. Every one of those moved the CIO further from the cold room toward the boardroom. “What great looks like” for a CIO went from “the batch job finished on time” to “the systems are reliable and secure and cost what they should” to eventually, “technology is making the business measurably better.” The job kept getting more strategic, but its core never changed: the CIO is accountable for the machine running. Reliable, secure, governed, affordable. Run the business.

Where the CTO came from, and why it was different

The CTO arrived later and from a different direction.

It grew up in the 1990s, mostly inside technology and product companies, and it started as the chief engineer or chief architect. The person who owned the technology vision and the R&D bet. In a software or tech hardware company, the CTO owned the thing you sold. They lived next to engineering and product, and their job was to be right about where technology was going.

When the CTO title migrated into ordinary enterprises (banks, retailers, manufacturers), it kept that outward, forward lean. In a bank, the CIO keeps the core banking systems stable and secure. The CTO is the one pushing the mobile app, the new platform, the AI bet. One is pointed inward at operations and employees. The other is pointed outward at products and customers.

That is the cleanest way to differentiate the two: the CIO runs the business, the CTO changes the business. Reliability versus reinvention. Operate versus explore. The drawer where the tools are organized, versus the workbench where the new thing gets built.

The reason these were two seats was never the titles; it was because the two motions pull against each other. One optimizes for “nothing breaks.” The other optimizes for “we break things to drive change.” Put both functions in one place with one budget and one set of incentives, and someone always loses. Usually invention loses, because the pager goes off for outages, not for missed opportunities.

What happens next

I’ve thought about this a lot; there are many ways to navigate what’s coming next, but the most effective model is:

  • The CIO focuses on run – operations at scale is critical, and that has to be their success metric. With almost all infrastructure available through cloud and AI providers, the CIO’s best partner is the CFO.
  • The CTO changes their “T” – they must understand technology, but their role is to lead the Transformation to AI Native.  The CTO has to pivot, their new best partner is the CPO, the Chief People Officer.  This isn’t about choosing a technology stack anymore, this is about your people transforming.
  • Everyone has to embrace the change to AI Native – you either lead the change or it happens to you.

Start with the CIO, because the easy mistake is to read “shrinking footprint” as “shrinking importance.” Cloud did not make the CIO less important, it made the role more manageable. Those are different words. The surface area shrank, but importance held. When the machine is something you rent rather than something you build, the hard questions become consumption and cost: what are we paying, what are we actually using, are the vendors earning what we’re paying them. That is why the CIO’s center of gravity drifts toward the CFO. Run becomes a financial discipline.

The CTO is the opposite shape. It was always the forward-looking seat, and here is the part we never said out loud: a lot of what made that work was that change used to be slow. You could see a trend coming, and you had the time to aim at it. The great CTOs aimed a little faster, and made high value bets. You could be early, be a little wrong, and reposition before it cost you. Vision paid off because the future arrived at a walking pace. The CTO got to be the person who saw it first and had time to act.

That slack is gone. AI is not a new tool on the bench, it is a whole new workshop. It is an accelerant on the rate of change itself, and the rate is compounding. The future is no longer arriving at a walking pace; it is arriving faster every quarter, soon to be every month, then every week. In that world the value of the CTO stops being “pick the right technology” and becomes “build a company that can absorb a new future on repeat.” Vision stops being a telescope you look through occasionally and becomes flight controls you never take your hands off.

The best CTO today needs to see a little further down the road than everyone else and get the company ready for change. That is the whole job. Nobody sees past the event horizon. Anyone selling you a five-year AI roadmap right now is selling you snake oil, because we are wildly early. My first cell phone was a handset bolted to the console of my Chevy S-10 with a cord running into the dash, and I was sure I had arrived. We are at that phone-in-the-truck stage with AI, and the road past the next curve does not exist yet. So the job is not prophecy, it is keeping a fast-moving, low-visibility vehicle pointed in the right direction, and building an organization that can take the next turn without spinning out.

The CTO has to raise their view and widen their aperture. They have to walk fully out of the research lab they were born in. The job is no longer to own the technology, it is to own what the technology does to the company: not the resident expert on the new tech, but the person accountable for the whole organization metabolizing a new future on repeat, faster than it is comfortable doing it.

A different job needs a different partner. This is the tell that the role has changed, not just relabeled. The old CTO was wired into the technical core. In the enterprise that meant standing shoulder to shoulder with the CIO and engineering, vision next to operations and product. The CTO’s closest alliance was with other technologists.

Becoming AI Native is not a technology problem; it is an organizational one. The new alignment is CTO and CPO, vision next to organizational design. One side reads the road and decides where the company has to go. The other side rewires the org so it can get there, reshaping teams, retraining people, changing how the work is divided so the whole company can accelerate with AI. Org charts, span of control, promotions, incentives, budgets – it all has to change. You have to build a company that can absorb change at pace, and you build it through people. A transformation seat that stays glued to the CIO and the engineering org is solving the old problem, stuck in the past. The one that pairs with the CPO is solving the new one.

How both roles transform

So, back to the question: Merge or Split? Neither. That was always the wrong frame, because both options try to bolt AI onto the org you already have, keeping the boxes on the chart and adding “…with AI” to each one. AI is an “empty the cup” moment.

The CIO does not disappear, it tightens. Run becomes a sharper, smaller, more financial discipline that holds the guardrails and watches the meters, shoulder to shoulder with the CFO. The CTO does not disappear, but thrives when they walk out of the lab, partner with the CPO, and transform how the whole company works.

The companies that win the next decade will not be the ones that picked the cleverest org chart or the coolest technology today. They will be the ones that understood, early, that AI Native is not a tool you adopt but a change you lead. You either drive the change, or it happens to you.

Seven Clicks a Day, Forever

I built a three-skill pipeline so I’d never have to “Download transcript” again. The pipeline isn’t the point.

I record a meeting with myself every day.

It’s not a meeting. It’s me, at my desk (or in the car, or on a run), talking out loud to Teams for fifteen or twenty minutes about what I’m trying to do that day: the threads I’m pulling on, the half-finished decisions from yesterday, the things I’m worried about, the projects I need to start or finish, the things I’m excited about. I hit record, I talk, I hang up.

Then Teams transcribes it. And that transcript is gold. Because it isn’t notes I had to type. It’s me, thinking out loud at the speed of speech, in my own voice, with all the messy connective tissue that I never bother to write down. It is the single richest piece of context I can give to my agent for the rest of the day.

But to get it into the agent’s hands, I had to do this every time:

  1. Open Teams.
  2. Find the meeting in the chat.
  3. Click into the recap.
  4. Open the transcript pane.
  5. Click the three dots, click Download, pick .docx.
  6. Convert to txt so the agent can really consume it.
  7. Move the file from Downloads into the folder my agent watches.

Seven clicks. Every day. Forever.

That’s the kind of friction that kills a workflow before it has a chance to compound. I knew it. I felt it every morning. And every day I did those clicks anyway, because the payoff was worth it. Many days, more than once.

I’ve done this for months, and couldn’t build a way around it, until now.

The real point isn’t the meeting

I want to be honest about what this project actually was, because the surface description (“I automated Teams transcript downloads”) sells it short.

The point is not that downloading a Teams transcript is hard. It isn’t. It takes less than a minute.

The point is that a manual task done every single day, forever, is the single most expensive thing you can put in your workflow. Not because of the minute it takes. Because of the decision cost: the tiny moment every time where I have to remember to do it, choose to do it, and then mentally context-switch out of “I’m about to work” into “I’m doing data plumbing.” That decision cost is what kills the workflow. The transcript stops happening. The agent stops getting the context. The agent’s outputs get worse. I notice. I get frustrated.

The fix wasn’t a better agent. The fix was making the input arrive without me.

The constraint that shaped everything

The clean version of this is one Graph API call. GET /me/onlineMeetings/{id}/transcripts/{id}/content returns the .docx. It’s a one-liner.

It’s also blocked in my tenant. Admin consent on OnlineMeetingTranscript.Read.All is not happening. Nobody is going to grant that permission to one rando in a 200,000-person tenant. The answer was no, and the answer is going to stay no, and that’s fine; I’m not building a product, I’m building a workflow for me.

So the entire design had to assume that the only reliable way to get a transcript is to drive the Teams web UI like a human would. Playwright. Click the buttons. Wait for the download. Move the file.

Once you accept that constraint, the shape of the solution starts to come into focus.

Three skills, one pipeline

I broke the work into three pieces, each doing one thing, each independently useful.

Stage 1: /transcript-watcher polls my OneDrive Recordings folder every thirty minutes. Teams puts a new MP4 there every time a recorded meeting ends. When the watcher sees a new file whose name matches one of my watched series prefixes, it knows there’s a transcript to go get. It pings me in Teams (“I see a new recording for X, going to grab the transcript”) and invokes the next skill. The expensive thing (Playwright) only runs when there’s actual work.

Stage 2: /meeting-transcript is the Playwright driver. It opens Teams in a real browser, finds the meeting in the chat, opens the transcript pane, clicks Download, waits for the .docx, and saves it to a watched folder with a sensible filename. This is also the skill I can invoke directly when I want a transcript for a meeting that happened weeks ago.

Stage 3: /doc-watcher watches the folder. When a new .docx lands, it converts it to plain-text Markdown using Word COM (headless), pings me in Teams that it’s ready, and the original .docx never gets touched.

End to end: about thirty minutes typical, an hour worst case (the recording has to finish processing in OneDrive before stage 1 can see it). Zero clicks from me. If I want it right now (I usually do), I kick it off manually. Soup to nuts in three minutes.

The Markdown file lands in the same folder my agent reads at the start of every conversation. The agent sees this as ambient context. It knows what I was worried about. It knows what threads I’m pulling on. It knows what I’m trying to do that day. I didn’t have to tell it. I just had to talk.

The gotcha that confused me

One detail almost broke the whole thing.

The Recap picker in Teams shows the scheduled meeting time, not the actual recording start time. So my standing one-on-one with myself is scheduled at 18:45, but I actually hit record at 12:20, and the file the pipeline produced was named with 18:45. I do this more than once a day, so multiple files collided because they were all “scheduled at 18:45.”

The fix was to stop trusting the Recap picker and read the recording start time out of the chat thread instead. Three regex cases (English UI, localized variants, edge formatting) cover everything I’ve seen. The skill warns loudly if it falls back to the picker’s value, so I’ll notice if a fourth case shows up.

A workflow you can’t trust is a workflow you’ll abandon. Naming has to be right or none of the rest of it matters.

What this actually unlocked

The transcripts arrive. The agent reads them. I haven’t clicked “Download transcript” once.

What I didn’t expect was the second-order effect. Because the friction went to zero, I started recording more things: short voice memos between meetings, a five-minute postmortem after a hard call, a quick “here’s where I left this” before I close the laptop. All of it ends up as Markdown in the same folder. All of it becomes context.

The pipeline removed seven clicks. Removing those clicks made me record three times as often. The agent’s context window got an order of magnitude richer. Jevons’ paradox in action.

That’s the trade I want to keep making: find the daily friction, automate it down to zero, then watch the behavior on the other side of the friction explode.

The three skills are live

All three are published on SkillWorks if you want to lift them. They’re Clawpilot skills: install them with /install, configure your paths, and you’re running. They should work fine with GitHub Copilot, Copilot CoWork, or other systems with minor modifications. Ask your agent to adjust them.

  • Teams Transcript Pipeline: the full write-up (the why, the design, the dead ends)
  • /transcript-watcher: polls OneDrive for new recordings
  • /meeting-transcript: drives Playwright to pull the .docx
  • /doc-watcher: converts .docx to plain Markdown and pings you in Teams

Each one is independently useful. The doc-watcher in particular has nothing to do with Teams. Point it at any folder of Word documents and you’ve got a feed of plain-text copies that your agent can use.

Your turn

What’s your seven-clicks-a-day workflow? The one you’ve been doing forever because the payoff is worth it, but the decision cost is starting to fray?

Drop it in the comments. Half the time I see somebody else’s, I realize I have the same one and didn’t notice.

More of what I write lives at signalnotsentiment.com. Lessons from doing, not theorizing.

Phone in the Truck

Why I think we’re nowhere near as far along on the AI curve as it feels.

I’m old enough to remember the time before cell phones.

I had a phone on my desk at work. I had a phone at home, the one with the long curly cord, attached to an answering machine that I rewound by pressing a tiny tape down with my thumb. That was the communication stack. That was it.  Different numbers, different functions.

Then I got my first cell phone. And it wasn’t really a phone, not the way you’re picturing it. It was a handset bolted to the console of my Chevy S-10, right next to the gear shift. A cord ran from the back of it down into the dash for power. The buttons were on the back of the handset. You could pick it up and put it to your ear like a regular phone, or you could leave it cradled and hit speaker.

I thought I had arrived.

For the first time in my life, the dead hours of a commute became productive hours. Driving to a meeting, driving to a sporting event, driving home late, I could communicate. I told everyone I knew that this thing had changed my productivity forever.

It had. It just wasn’t what I thought it was.

Every stage looked like the peak from the inside

Then Nokia happened. The flip phone. The bar of soap phone. Auto-answer with a headset jack, which felt like science fiction, because now I didn’t even have to reach into my pocket. If it rang, I started talking. Productivity unlocked. Again.

Then keyboards. BlackBerry. Windows Mobile. Email in my hand. I remember thinking, this is it, this is the force multiplier. What more could you possibly need?

Then the iPhone. Apps. Then data, slow and unreliable at first, but a web browser in your pocket, which was a concept that had not existed before. Then real apps. Then Bluetooth, which we all made fun of until every single one of us was wearing it. Then video calls. Then maps that knew where you were. Then a bank in your pocket. Then a camera better than the one in my closet.

At every single one of those stops, I thought we had arrived.

I was wrong every single time.

The phone in my truck and the phone in my pocket today are not the same product. They are not the same category. They are barely the same species. And the version of me sitting in that truck in 1992 could not have described to you what the device in my pocket is today, because the words for it did not yet exist.

Now look at AI

I have a fleet of agents working for me right now.

One of them triages my inbox before I’m awake. One of them rewrites my drafts. One of them sits on my calendar and resolves conflicts before I see them, then sends me a morning report telling me what it moved and why. One of them builds dashboards on demand. One of them runs a weekly report on how many tokens I burned, how many artifacts got produced, and a rough estimate of how many hundreds of thousands of dollars of human effort would have been required to do all of that two years ago.

I am, by any reasonable measure, more productive than I have ever been.

And every time I demo a piece of this to someone, the reaction is the same. This is incredible. This is the future. We must be so close to the peak.

I keep wanting to agree with them. I have lived inside the productivity gain. I know what it feels like.

But I’ve been through this movie before.

We’re in the S-10

We are not at the iPhone moment of AI. We are not at the BlackBerry moment of AI. I don’t think we’re at the Nokia moment of AI.

I think we’re at the phone in the truck.

I think the version of AI my kids are going to use in a decade is going to be as unrecognizable to us, sitting here in 2026, as a modern smartphone would have been to me sitting in my truck in 1992. The words for it don’t exist yet. The form factor for it doesn’t exist yet. The social patterns for it don’t exist yet. We don’t even have the right complaints yet, and complaints are usually a leading indicator that a category is mature.

The exponential nature of this curve fools us. It feels like we’re moving so fast we must be near the end, when in reality the speed is the tell that we’re near the beginning. Things move fastest when they have the most room left to run.

The fact that the pace has compressed does not invalidate the pattern. It just means we’re going to see the next several stages inside a single career instead of across three of them.

So when somebody asks me where we are on the AI curve, I have a real answer now.

I’m in the truck. The cord goes into the dash. The handset is next to the gear shift. And I am absolutely certain I have arrived, in exactly the way I was certain the last four times.

Your turn

Where do you think we are on the AI curve? Phone in the truck? Nokia flip? BlackBerry? Early iPhone? Something later?

Drop your honest answer in the comments. Bonus points if you can name the feature you’re using today that will look as quaint in ten years as a handset bolted to a dashboard looks now.

Lessons from doing, not theorizing.

Step 7: We Almost Broke Everything

📍 Part 7 of 8 · Becoming Agent-Native
An 8-part series on going from delivery team to agent-native organization — lessons earned, not borrowed.
Genesis · Anxiety · Names Matter · Proof of Value · The Pivot · Co-Creation · → The Garage · The Flywheel

Let me describe the period just before we built the Garage.

High creativity. Great energy. Agents proliferating across the team.

Underneath it: loose operational foundation at best. Governance ideas and concepts.

Flailing.

Here’s what “flailing” actually looked like:

Seven agents doing roughly the same thing. No design pattern to rationalize them. A delivery team member builds an agent, it works great, she goes on vacation, the model updates, it breaks, nobody knows who to call.

Some agents didn’t log to the dashboard. Some logged multiple entries. Some logged events for failed runs. Agents that hadn’t been through a security review. Agents that got stuck in loops and churned resources. Agents without error handling.

None of it malicious. All of it predictable.

Momentum without infrastructure eventually produces exactly this.

What the Garage is.

The name is intentional. The Garage is where things get built right; maintained properly, run reliably, tuned up occasionally, extended thoughtfully.

The core insight: every agent, regardless of who built it or how fast it came together, needs to meet a consistent baseline.

  • Usage logged to the central dashboard
  • Security parameters and data governance verified
  • Responsible AI framework compliant
  • Clear ownership with a maintenance plan
  • No unnecessary overlap with existing agents
  • Fit into the software development lifecycle

Before the Garage, those things happened by luck. After the Garage, they happen by design. They were all documented in the Garage Green Book.

The thing we were most careful not to break.

The creative momentum from Phase 5.

The worst version of an agent ops team is one that becomes a bottleneck. Submit your agent request here. Six-week review cycle. Fill out this form in triplicate. You missed section 17 of the BRD. How did you come up with that ROI. We need LT buyoff. Thank you for your patience.

That kills everything. Literally everything. Momentum, creativity, usage, passion; everything.

So we designed what we think of as a barbell.

One side is the delivery team: the ideation, the domain expertise, the speed, the ideas born from real work. To quote my mentor “In the business, not on the business”

The other side is the Garage: the rigor, the telemetry, the governance, the scale.

Both sides need each other.

Delivery without ops builds fast and breaks things. Ops without delivery builds carefully and solves the wrong problems. Together: fast and right.

What good agent ops actually enables.

It’s not just about catching problems.

Operational infrastructure is what makes scale possible. When the process for onboarding a new agent is defined, you can move faster. When agents share a common architecture, you can combine them. When the foundation is solid, extensions are fast. When your telemetry is accurate, you get buy in and more funding.

The Garage isn’t friction for innovation. It’s the launchpad.

One more thing the Garage gave us: a real answer to “what agents do we have, what do they do, and who owns them?”

That’s not glamorous. It’s essential. It’s an incredibly valuable asset. You need a library of agents, an agent to search that library, and an agent to simplify the process for getting more agents into the library. That’s agent ops. That’s The Garage.

Agent ops is a real thing. If you’re scaling agents without it, you’re not running a program. You’re running a mess.

Next: What the whole system looks like when it’s actually working.

Step 6: The Phase Nobody Plans For

📍 Part 6 of 8 · Becoming Agent-Native
An 8-part series on going from delivery team to agent-native organization — lessons earned, not borrowed.
Genesis · Anxiety · Names Matter · Proof of Value · The Pivot · → Co-Creation · The Garage · The Flywheel

When we started, the model was simple.

Squad builds. Delivery uses.

That division felt right. Clean organizational lines. Clear ownership. A good model.

By Phase 5, it was gone, and it was the best thing that could have happened.

Delivery became builders.

Not because we told them to. Not as a program or initiative.

Organically…as the natural result of everything that came before.

People moved through the anxiety, saw agents make their days better, made the mindset shift from threat to tool to teammate. They started showing up with more than feedback. They showed up with half-built ideas. With sketches of agents they needed. With “I figured out how to make this work”

And with a low-code toolkit they built them. Themselves.

Why this works better than centralized roadmaps.

The people doing the work every day know the friction better than anyone. They know which task is genuinely painful versus just annoying. They know which data lives in the wrong place. They know what “good output” actually looks like for their specific context. They aren’t looking at a PowerPoint slide or a Figma, they are living the experience.

When they build the agent, it fits because it was designed by someone in the workflow it’s automating.

Mona is a great example. She didn’t come from a squad roadmap, she came from a delivery team member who was tired of the back and forth with humans scheduling meetings. She understood the problem completely. She had opinions about exactly what the output should look like. She came to demo days and the engineers said “that’s a great idea but it won’t work” and then she showed them the MVP…working. That day changed our world.

That’s the model. You can’t push it from the top down. It has to grow

The propagation effect.

When everyone in delivery is creating, velocity compounds. One agent spawns an idea for three more. A tool that worked for one person gets adapted for the whole team. The surface area of “problems we’ve automated” expands faster than any squad sitting in an ivory tower could imagine.

There’s not some special team that’s the only one creating. Everyone is. That’s the whole point.

The catch.

There is one. And it’s significant enough to become its own post.

When everyone is building, you get overlap. You get orphaned agents when the person who built them goes on vacation and something breaks. You get agents that don’t log to the dashboard, don’t meet governance requirements, don’t fit the responsible AI framework.

We hit all of this. And more.

Seven agents doing roughly the same thing. Nobody quite sure who owned what. A model update quietly breaking something nobody was watching.

Citizen development at scale without operational infrastructure eventually leads to chaos.

Which is exactly what led us to build the Garage.

Creativity without ops is a mess waiting to happen. Ops without creativity is a very well-governed nothing. You need both.

Next: The mess — and what we built to fix it.

Step 5: The Day Anxiety Became Curiosity

📍 Part 5 of 8 · Becoming Agent-Native
An 8-part series on going from delivery team to agent-native organization — lessons earned, not borrowed.
Genesis · Anxiety · Names Matter · Proof of Value · → The Pivot · Co-Creation · The Garage · The Flywheel

There isn’t a single moment. It’s more like a temperature change.

Gradual. And then all at once. Exactly like Hemingway described bankruptcy.

The signal: someone stops asking “is this going to replace me?” and starts asking “what else could they do for me?”

That question – unsolicited, forward-looking, a little excited – is the pivot. And everything after it is different.

What caused it.

Not a single thing. An accumulation.

The email draft that was perfect. The research that came back before they’d finished their coffee. The weekly summary that was just there without anyone asking for it.

When those moments pile up, the mental model flips. The agent stops being a threat and starts being an asset.

And once it’s an asset, a very natural question follows: how do I get a better one?

That question is the whole game. Because it means your delivery team has become an active participant in the quality of their own AI teammates. They want them to improve. They have opinions about how. They’re invested.

The frame that accelerated it.

Our team always has more work than capacity. There are always more customers to serve, more research to run, more value we haven’t gotten to yet.

We are not, and have never been, trying to reduce headcount.

What we’re trying to do is amplify the headcount we have. Get more high-value work. Free people from the repetitive work that agents handle better anyway. Work on the hard stuff. Grow your career.

It’s like the tractor replacing the hand plow. You didn’t lose the farm. The farm got bigger.

When people understood that frame, agents as multipliers, the math became obvious. More impact, same team, better work.

That’s not a threat. That’s a competitive advantage for every person on the team.

What the pivot looked like in practice.

Feedback volume jumped. People who had never commented on an agent suddenly had opinions. Feature requests started flowing. Someone said “could Reese do this if we gave him this additional context?” and “I think George would be even better if he also pulled from this system.”

That’s not tool usage. That’s coaching. And you can’t coach something you’re afraid of.

When you see this shift starting, lean in fast. Turn that spark into a fire. Prioritize the feature requests that come from delivery. Make it visible that their input is landing in the roadmap. Create the fastest possible feedback loop.

The pivot is fragile at first. Feed it.

The moment your team starts coaching their agents instead of tolerating them, the phase change is real.

*Next: What happens when delivery stops requesting agents and starts building them.

Step 4: The Agent Dashboard

📍 Part 4 of 8 · Becoming Agent-Native

An 8-part series on going from delivery team to agent-native organization – lessons earned, not borrowed.
Genesis · Anxiety · Names Matter · → Proof of Value · The Pivot · Co-Creation · The Garage · The Flywheel

Early in Phase 2, before we knew if people would even use these agents, we built a usage dashboard and a small component that every agent had to include – Power Automate, Copilot Studio, M365 Copilot – it was table stakes to onboard.

It felt a bit like overhead at the time.

It became the foundation of everything.

What the dashboard tracked: which agents were being used, how often, by whom, and with what outcome.

Simple. But surprisingly revealing.

Some agents were hits. Usage climbed. Feedback was positive. The team became genuinely dependent on them. These got investment: more features, deeper integration, wider rollout.

Some were mediocre. Usage below expectation but not zero. The dashboard made us ask the right question: is the agent underperforming, or is there an onboarding gap? Is there a better design? Those are different problems. You can’t diagnose without the data.

Some just didn’t work out. And the dashboard gave us permission to retire them. No politics, no ego, just “the numbers say this isn’t earning its place.”

The data showed us insight about people, not just agents.

We saw a clear split emerge: pro users and skeptics.

Some team members were all in. They used agents daily, sending feedback all the time, acting like internal product managers for the agents they’d adopted. Others were lukewarm.

That visibility mattered. It let us find the right internal champions. It let us understand the gap between those two groups. It let us have a business conversation, with real numbers, about what was working.

ROI reporting doesn’t only justify the investment. It shows your team you’re taking this seriously. And them.

But the most important proof never showed up in the dashboard.

It was the moments.

The team member who realized they hadn’t manually changed that case status in weeks. Not because they forgot, but because Theo handled it.

The person who got their Friday afternoon back because George was doing the weekly summary.

The quiet relief of: oh, that’s just handled now.

When those moments accumulate, something shifts. The agent stops being an experiment and starts being infrastructure. The dashboard tracks the what. The moments explain why it matters.

If I were advising someone starting this today, I’d say: Build the measurement layer early, at the business group level, not deep in IT.

Once you have 10 agents and a skeptic asking “what’s the ROI on all this?” you’ll be very glad you have an answer.

“Measure early. The dashboard will make decisions for you that would otherwise become arguments.”

Next: The inflection point, when the team stopped worrying about agents and started wanting more of them.