What was the solution is now the bottleneck
I want to lay out three seasons honestly, because the conclusion only makes sense in order.
2023: the software was the answer
We got real booking software, and it fixed real problems. Deposits stopped getting lost. Two groups stopped landing on the same boat. There was one place to look up what a customer had actually paid for. Anyone who tells you booking platforms did not earn their place never ran an operation on paper and a phone.
It was a genuine advance. I want that on the record before the rest of this.
2024 and 2025: the operation outran it
The problem was never that the software was bad. It was that the operation changed faster than anyone could update it, and I have written about that at length. Every tool we tried, whiteboards, spreadsheets, the scheduling module, failed the same way. Not for missing features. For speed.
A good part of that pressure I created myself. Those were the seasons I spent building the demand engine, and then rebuilding half the revenue base in ten weeks after a policy change took our largest account out from under us. Both worked. Guest volume grew roughly 3.6x while prices went up rather than down. And every booking that came in landed on an operation with no way to absorb it except through me.
So the operation ended up somewhere else. In my head.
There were stretches of twenty hour days. There were nights I did not sleep because I was holding a version of the next morning in my head and could not put it down. It was not sustainable and I would not recommend it to anyone. I am not telling you this because it was admirable. I am telling you because of what it proves.
I did not drop the ball.
Across two bases hundreds of miles apart, we put thousands of guests on the water every season. This year alone it is more than 4,600 so far, with 663 people on rivers across the state inside a single week and 272 on the water in one day. Multi-day trips run into the largest contiguous wilderness in the lower 48, five days out, no cell service, no way to fix a decision you got wrong at the put-in. Every trip carries a packing list hundreds of items deep. Food for a week for a specific headcount with specific allergies. Boats matched to water level, guides matched to qualifications, trailers, seats, shuttle timing, permits, and a launch window you do not get to move.
None of it fell over. That is not a boast. It is the setup.
Because the reason it worked is the problem. I was the integration layer. Every change ran through me, and a business that runs on one person’s memory is not a well-run business. It is a business with a single point of failure who happens to still be showing up.
Living inside that for two seasons is what turned knowing it into resolve.
2026: what actually fixed it
So I built the two things that were missing.
First, sensing. The operation talks all day, in messages and calls and field reports, and none of it was reaching the schedule. Now it does. A guide says a thing the way people say things, and it becomes a checked, staged change.
Second, the operational model. Not the bookings, the business. Who is cleared to lead what water, how many boats a trip takes, which movements collide, what a change two days out breaks downstream. Written down as data, in a form something other than me can reason about.
The result is the part I am proudest of. Weekly planning went from 20 to 40 hours down to 2 to 4. Not trimmed. Reduced by an order of magnitude, in the middle of our biggest season, while the operation grew.
And I want to be precise about where the saved time went, because it is the whole point of this piece. A good chunk of it went into manual data entry that the software will not accept any other way. I have a capacity engine that can only advise. It works out what should go where, and then I retype its answers into the booking system one record at a time.
The bottleneck moved. It did not disappear.
Six layers, and only three built for the middle
Here is the map I ended up with. Every service business that runs on bookings has these six layers, drawn or not.
Demand is solved. The site, the cart, the channels, and now the AI assistants doing the recommending.
The system of record is solved. The booking, the payment, the customer. Decades of investment, and it remembers everything that happened.
Sensing is broken almost everywhere. The operation talks and nothing listens, so a problem surfaces the morning it breaks.
The operational model rarely exists off the shelf. Enterprise platforms model this properly, and a few sophisticated vertical products are getting there. At the size most operators actually are, nobody sells it, because it is different for every operation. So it lives in somebody’s head.
Reasoning is solved, and this was the surprise. It was supposed to be the hard part. Give a model good state and clear rules and it works, almost immediately.
Action is the narrow one. Some platforms do write now: a shift, a technician assignment, a booking. What almost none of them accept is a decision that moves across the whole operational model at once, under permissions somebody trusts. Creating a booking is not changing the business.
Three solved, three thin, and the split is not random. The three solved layers all touch money directly, so software got built there, because that is where the obvious buyer was. The three thin ones touch operations, which for thirty years lived in one person’s head, so nobody ever had to write them down.
I have written the reference version of that map up separately, with the diagram, what each break costs, why nobody has filled the gap, and the engineering problems that keep it hard: the agent-ready operations spec. This piece is how I got there. That one is what I think the answer has to look like.
The buyers have started saying it out loud
While I was writing this, the founder of Resend posted something that reads like the demand side of the same argument. He was talking about how he now chooses software:
i used to care about features, now i care about interacting with my data. no MCP means i have to use your UI. that’s a dealbreaker now.
MCP is the emerging standard for how a piece of software exposes its data and its actions to an agent. The protocol is not the interesting part. The interesting part is a software buyer saying that reaching his own data without opening somebody’s interface has become a purchase criterion, and that the absence of it kills the deal.
That is my complaint arriving from the other direction. I have been making it as an operator who cannot get his own operation to move. He is making it as a customer who will not buy software he has to sit inside. Neither of us is asking for more features. We are both asking for a door.
And it is worth being precise about what he is describing, because it is the easy half. Reading your data through an agent is a solved problem the moment a vendor decides to expose it. Changing something is the half that stays hard, for all the reasons above. But a category where buyers start refusing software they cannot reach into is a category where the harder half eventually gets built too.
Since writing that, I went and looked at what the industry itself has standardized. The tours and activities sector now has an open connectivity specification, and its entire capability list is products, availability, bookings, pricing, notifications, content, pickups and dropoffs. Nothing for crew, vehicles, equipment, qualifications, maintenance or permits.
So the category has agreed on how to sell a seat and has not started on how to deliver it. That is the same gap as the operational model layer above, arriving as a published standard instead of as my opinion. I wrote that up separately, with the market numbers and the satisfaction data behind it.
It also sharpened how I say this. “Booking software needs a write path” is right but small. The better version is that reservation software is becoming infrastructure, and the next control point is the agent-accessible operations layer that turns reservations into executed work.
The line
The booking system was the solution. It replaced the paper and the double-booking and the lost deposit, and it was a real advance.
But the constraint moved.
What was formerly the solution is now the bottleneck. The system of record does its job perfectly and, in doing so, stands between a model that understands the operation and an operation that actually changes. It will let software read all day. What it lets software write is a slice, and the operational model is not in that slice. So a system can work out the right answer and still have no way to make it real.
That is the whole thing. The intelligence is not the gap. The gap is somewhere for the intelligence to stand, and a door on the far side.
I am not the only one who found this. People coming at it from research describe agents that fail without grounding in physical reality, and solve it by having the agent stop and ask a human when its own confidence drops. People coming at it from enterprise software have concluded the bottleneck is not model quality, it is permissions, and that if permissions live somewhere other than where the data lives you have already lost. And the largest bet in applied AI right now is that implementation, not models, is the enormous business, aimed almost entirely at big enterprises with a CEO mandate.
Which leaves every operationally complex business below that line to work it out alone, the way I did.
It should not take a season of twenty hour days to get here. That is what makes this worth building.
Every claim in this piece has a screen behind it. The board that replaced the whiteboard, the crew grid that will not offer you a guide who is not cleared for that water, the collisions flagged the moment they are created instead of at the boat ramp the next morning. That is what the finished half looks like, mostly in pictures. Two seasons of holding all of it in my head, and now anyone on the crew can open it on a phone.