Agent-ready vertical software · a field spec, v1
An AI can read your operation. The hard part is letting it safely act.
Agent-ready software is not an assistant bolted on, and it is not just a read/write API. It is a governed set of actions over a trustworthy model of operational state. The connection is commoditizing. What decides whether an action is correct is the part that lasts.
Written by Justin Smith, an operator in Idaho. Part one is the diagnosis: where the stack breaks, who has already fixed parts of it, and what is still missing. Part two is the spec.
Part one · the diagnosis
Six layers sit between a booking and the work getting done.
Three of them are solved and well funded. Three are thin: they exist at enterprise scale and inside a few sophisticated vertical platforms, and are largely unavailable at the price and scale most operators run at. Here is which is which, and why the split falls there. The narrative version of how I found this is in what was the solution is now the bottleneck.
and the two layers in the middle are not for sale anywhere.
The six layers
Three are solved. Three are not, at the size most operators are.
Every service business that runs on bookings has the same stack, whether or not anyone has drawn it. The split below is consistent across rafting, field services, hospitality, and the trades.
The site, the cart, the channels, and increasingly the AI assistant that recommends you. Mature, competitive, and improving fast.
The booking, the payment, the customer. Decades of investment. It remembers everything that happened, reliably.
The operation talks all day, in messages, calls, and field reports. Almost nothing listens, and none of it becomes structured state.
People, qualifications, assets, capacity, timing, permits, and the rules connecting them. Palantir and Celonis model exactly this, at enterprise prices. Below that line it lives in an owner's head.
Given good state and clear rules, the model works. This was the part everyone expected to be hard, and it stopped being hard.
Writing a decision back into the systems that hold inventory and money, under a permission model somebody trusts. Some platforms write a slice. Almost none accept a change that moves the whole model at once.
Why the split falls where it does
The three solved layers all touch money directly. The three broken ones touch operations, which for thirty years lived in one person's head, so nobody ever had to write them down.
That is the whole explanation. Software got built where the transaction was, because that is where the revenue and the obvious buyer were. The coordination that starts the second a booking lands never got a system, because a competent person could hold it together, and holding it together was their job.
Which worked, right up until AI arrived and the constraint moved. The system of record was the solution to operational chaos. Now it is the thing standing between a model that understands your business and a business that actually changes.
The three breaks
Where it actually fails, and what each one costs.
The operation talks and nothing listens
A guide mentions a bad blinker. A group grows by six on the phone. Someone picks up an appointment in a group chat. Each of those is a state change, delivered in plain language to a channel no system reads. It surfaces the morning it breaks.
Cost: every failure is discovered late, when the options are worst.
The business was never written down
Not the bookings, the business. Who is cleared to lead what water. How many boats a trip takes. Which movements collide. What a large group on a short trip is worth against a small group on a long one. An AI cannot reason about a model that does not exist, and no vendor ships one, because it is different for every operation.
Cost: the intelligence has nothing to be intelligent about.
Partial writes, not operational writes
This is the one I had to correct. Platforms do write: ServiceTitan's Dispatch API writes shifts, skills, and technician assignments, and some booking platforms in tours and activities expose crew assignment writes behind an integration review. So the binary version, that nothing writes, is simply wrong. The real constraint is narrower and harder. What almost nothing accepts is a semantically complete change: a decision that moves crew, equipment, timing, and capacity together, under permissions somebody trusts. Creating a booking is not changing the business. On my own stack there is no write path at all, and a person retypes the answer one record at a time.
Cost: correct decisions that never become actions, and never get counted.
The obvious question
If the gap is this clear, why is there no version for the middle?
It has been filled at the top. Palantir, Celonis, and Microsoft Fabric all model operations and act on them, for buyers with seven-figure budgets and an implementation team. The question is why nothing lands in the enormous middle. Four reasons, and none of them is that the industry is careless.
Enterprise has a buyer: a COO with a mandate and a budget line. The middle does not. An operations layer has to sell to the person currently holding the operation together in their head, who has no budget line for it and does not experience the problem as a software problem. They experience it as their job.
A booking is a booking in any industry. But who is qualified to do what, what a job consumes, and which commitments collide are different in rafting, HVAC, catering, and marinas, and different between two companies in the same town. There is no shrink-wrapped version.
The model only pays off once the rules are in it, and getting them in is slow, unglamorous, and entirely front-loaded. Every vendor who has looked at this has run the same math and walked.
Keeping a detailed model of a live operation current used to cost more attention than it saved. You would spend the afternoon feeding the system instead of running the day. That is the thing that actually changed. The cost of maintaining a rich model collapsed, and the math flipped.
The obvious objection
So why will the platforms not just build this themselves?
Some already are, and further along than I first credited. The ones that succeed will have a real advantage. But three things still work against it.
A platform has to ship the average
Vertical software succeeds by finding what customers share. The operating model is the opposite: it is precisely where two companies in the same town differ most. The more a platform generalizes it, the less it fits any particular operation, which is the reason the configurable version keeps getting cut.
The incentives point at the transaction
Configuration write access adds support burden and liability without obviously adding revenue. Payment volume and booking volume are measurable. "Our customers ran their season better" is not, at least not on a quarterly basis.
The gap is wider than it looks from inside
I have read booking platform API documentation end to end. Rich product data, real availability, per-tier pricing, a full transaction ledger, and a self-serve key. There is no concept of a guide, a vehicle, or a resource anywhere in it, and the manifest endpoint returns a participant count rather than a passenger list. That is not a criticism of any one product. It is the shape of the whole category.
The honest engineering
And why it stays hard even once you decide to do it.
These are the problems that make this a real engineering effort rather than a weekend of prompting.
Meaning has to come before action
Before anything can act, the objects and their relationships need agreed definitions. What a trip is, what a qualification permits, what a movement consumes. That vocabulary is per-vertical and largely unwritten, and you cannot skip it, because an agent acting on a model it misunderstands is worse than no agent.
Half the state changes leave no digital trace
A boat tears on a rock. A road washes out. A guide's certification lapses in a drawer. The physical world updates itself constantly and files no ticket. Any model of a real operation is partially blind by default, which is why the sensing layer is not a nice-to-have.
The scheduling problem is genuinely hard
Assigning people and equipment against qualifications, capacity, geography, timing, and permits is a constraint satisfaction problem, and the general case is computationally brutal. Real operations survive it on heuristics and human judgment, which is exactly the part that is hard to write down.
The mistakes are physical and do not roll back
You can undo a database row. You cannot un-strand a group at a takeout at dusk. That asymmetry is why every serious version of this keeps a human on anything touching money, compliance, or safety, and why autonomy has to be earned one category at a time.
Permissions have nowhere to live
The rule from enterprise software is that if permissions are defined somewhere other than where the data lives, you have already lost. For operations, the place where the data lives did not exist. So there was nowhere legitimate to put the permission model, and bolting one on from outside is exactly the failure that rule describes.
Which is why the wall is rational. Writing to inventory and money is where a vendor gets sued. Read access is safe and write access is risk, so the category stopped at read. Nobody drew that line stupidly. It just stopped being the right line.
What the field is finding
The same three walls, described by people who got there another way.
None of this came from reading the literature. It came from a season. Some of it confirmed what I thought and some of it corrected me, and both are below, because a spec nobody has tried to falsify is not worth much.
"The AI agent bottleneck isn't model performance, it's permissions." Enterprise agents all hit the same wall: what is this agent allowed to touch, on whose behalf, and how does the system know. The sharpest line in it, from Dan Obendorfer at Würk: if your permissions are defined somewhere outside of where the data actually lives, you have already lost.
Four approaches to grounding agents in the physical world. One of them is uncertainty-aware reasoning: an agent grounded this way halts and asks for human intervention when its own uncertainty crosses a safety threshold. That is the human-in-the-loop rule, derived from the research side rather than from a bad night on a river.
Some platforms already write. I argued for a while that systems of record let software read and never write. That is too strong. ServiceTitan's Dispatch API manages technician shifts, appointment assignments, and capacity windows, and some booking platforms in tours and activities expose crew assignment writes behind an integration review. The constraint is narrower than I first said: what almost nothing accepts is a semantically complete change across the whole operational model, under permissions somebody trusts.
a16z and Sequoia put $40 million into dispatch for the trades. Probook raised a $6 million seed from Sequoia and a $34 million Series A led by a16z, whose stated reason was that almost every AI vendor building for the trades skipped dispatch and rushed to voice agents and chat instead. The founder grew up in the trades and worked inside a $40 million home-services business before building it. That is the same argument I am making, from the same starting point, in a different vertical.
The next enormous AI business is implementation, not models. Ode with Anthropic launched in 2026 on exactly that premise, roughly a hundred engineers, explicitly aimed at large enterprises where AI is the CEO's top one or two priority. Which leaves every operationally complex business below that line on its own.
Part two · the distinction that matters
An API surface is not an operational action surface.
A normal API exposes the third layer and leaves the other four to you. Being able to call an endpoint is not the same as knowing you should.
Call the endpoint
A booking gets created. Technically valid. The request succeeds. POST /booking → 200 OK
Whether it should
- Does it blow past capacity or a permit limit?
- Does it create an equipment or vehicle conflict?
- Does it put an unqualified person on the job?
- Does money move, so a human has to sign off?
The gap between those two columns is where two years of my work lived. I could read enough to know what should happen. What I could not do was let the system safely write it back.
Not a slide
This ran a full season on a real operation.
A multi-location outdoor-recreation business: dozens of seasonal staff, vehicles, equipment, certifications, payments, permits, and constant last-minute change. The operating layer sat on top of the booking system and modeled all of it.
A live operational model, not a set of exports.
State an agent can reason over in real time.
~20,000 lines, 566 production deployments.
On jobs launching within a week, nothing chasing them.
Two systems disagreed. The layer refereed, every fix in the crew's favor.
One offhand text parsed into three checked reassignments.
The spec
Ten things a platform has to expose to be operable by an agent.
Each with a real example from the system I ran. Platform-neutral throughout: "the booking system" means any system of record.
Customers, jobs, employees, skills, assets, vehicles, locations, schedules, payments, permits, inventory. All first-class, which is why one guest-count change traced across boats, guides, trailer, and food instead of hiding in a field.
Which people, assets, and money belong to which work. Twelve guests to eighteen is not one update. It changes the ratio, the vehicle, the food, and the launch time at once.
Created, moved, assigned, canceled, paid, checked in, dispatched, completed, refunded. "i'll take Maia's driving tomorrow" is a state-change signal in plain language.
Not "click the button." A named action with inputs, preconditions, and effects. Reassign driver, stage a swap, flag for collection, each carrying the context it touches.
Read, suggest, write, financial write, irreversible write. Rebuild tomorrow's driver runs, yes. Issue a refund, never, without a human. That line belongs in the platform.
Enforced, not hoped for. Pulling a backup across two bases 300 miles apart, the system caught that the backup was not licensed for the run.
Duplicate actions prevented, failed actions safely re-tried without double-charging or double-booking. Exactly the layer a read-only integration cannot provide.
The gate is a property of the consequence. A board rebuild proceeds with a confirmation. A payroll change or refund always stops for a human, reasoning shown.
Establish what happened, repair a mismatch. 107 availability records against 382 operating records, three structural errors found, all corrected.
Realistic historical and synthetic scenarios. The real value of an accumulated operation is the library of exceptions the agent has to survive. That is the test suite.
The same spec, from the buying side
Five things an operator should evaluate, and none of them are features.
The ten above are what a vendor has to build. These are what a customer can check before signing, and they decide whether a system can participate in the next architecture or becomes the thing that has to be replaced.
API coverage
Can I read every object that matters, or only the ones the vendor found interesting? Partial coverage is the tell. A system that exposes products and bookings but not the resources behind them has decided which half of your business is real.
Write access, and how far it reaches
Not whether anything can be written, because a booking usually can. Whether a change that moves across the whole operating model can be written, in one transaction, and rejected cleanly if it would break an invariant.
Events
Does the system tell me when something changed, or do I poll and hope? Anything built on polling is permanently a few minutes behind the operation, which is exactly the gap the whiteboard used to fill.
Permissions the operator controls
Can I say this agent reads manifests and never issues refunds, that one assigns crew and never touches pricing? And can I say it where the data lives? Permissions defined anywhere else are theatre, which is the enterprise rule arriving in a smaller business.
Portability
Can I take my history, my customers and my operational data out without asking nicely? This is the one vendors have the clearest incentive to be slow about, because clean exports are the thing that makes leaving possible.
The industry's own connectivity standard covers products, availability, bookings, pricing, content, pickups and dropoffs. It has nothing for crew, vehicles, equipment, qualifications or permits. Selling the seat is standardized. Delivering it is not.
Where a moat actually forms
Operational context is not automatically defensible.
Knowing one company calls a truck "Big Red" is consulting knowledge, and it does not transfer. The moat forms only when the knowledge becomes reusable vertical infrastructure.
Client configuration
- Employee names, specific vehicle IDs
- Local vendor relationships
- This year's permit numbers and staff availability
- One company's unusual terminology
Vertical IP
- A standard ontology and event model
- A reusable qualification and capacity model
- Action schemas, permission templates, approval thresholds
- An exception taxonomy and a standard evaluation set
The test for any engagement, and any platform decision: did this make the tenth implementation materially faster, safer, or better than the first? If yes, it is infrastructure. If no, it is revenue.
Part three · what becomes possible
What follows once the three broken layers exist.
These are mechanical consequences rather than forecasts. Each one follows directly from an operation being written down and something being allowed to act on it.
Planning stops being an event
Today an operator plans on a cadence, weekly or nightly, and reality drifts away from the plan between sessions. With a live model and a write path, the plan is simply always current. Optimization becomes continuous instead of periodic, and the drift never accumulates.
The operating model becomes an asset you can move
Once how a business runs is data rather than memory, it can be handed to a new manager, audited by a buyer, or used to open a second location that runs correctly from day one. Right now the most valuable thing in most service businesses walks out the door at the end of a career.
One layer can run many operations
The same model that coordinates two bases can coordinate twenty, or a portfolio of businesses that share a shape. That is when this stops being a productivity tool and becomes infrastructure, and it is the version that interests the people funding this category.
The part worth saying plainly
Some of this is going to take work away, and I should be honest about whose.
The work most exposed is coordination. The reconciling, the retyping, the checking whether two things collide, the role that exists because the schedule is too complicated to hold any other way. I am not going to make predictions about what stays human in twenty years. I am describing what this particular layer displaces, which is administrative work rather than the work itself.
In my own operation the first job this eliminated was mine. Not a guide's. The part of my week where I was the integration layer, 20 to 40 hours of it, is gone. Nobody was let go. That capacity went into growth, and we ran a bigger season with the same crew.
At the scale of a whole industry I do not think it stays that tidy. Coordination roles are genuinely at risk, and anyone selling this while insisting no work disappears is not being straight with you. What I would say is that the specific work most exposed is the work that made people miserable, and that the honest version of this argument names that rather than hiding it in a footnote.
Falsifiable
What would change my mind.
Three things would weaken this argument considerably, and I would rather name them than be argued into them. The first has already partly fired, which is why the write-access claim on this page is narrower than the one I published earlier.
If a major platform ships configuration write access with a real permission model. The wall is the load-bearing part of this. If it comes down from the inside, the layer I am describing belongs inside the system of record after all, and that is a better outcome than the one I am arguing for.
If computer use gets reliably fast enough. If agents can operate a normal interface at production speed and reliability, the API argument matters much less, and the moat moves entirely to the model of the operation.
If the operating model turns out not to transfer. This is the one I actually worry about. If every business needs a fundamentally different model rather than a configured one, then this is consulting rather than a category, and no amount of conviction changes that. The test is simple and I am running it: does the tenth build go materially faster than the first. Process mining companies are partial evidence that implementation knowledge does compound into reusable infrastructure, but partial evidence at enterprise scale is not proof at mine.
Which layer is still missing?
Booking software solved the transaction, and it increasingly handles pieces of resource scheduling too: assign a guide, reserve a vehicle, flag an overlap. The harder layer starts when reality changes underneath the booking. A guide calls out. A group grows from twelve to eighteen. A boat comes off the water damaged. A message arrives from a canyon with no cell service. Those aren't independent updates. Each one changes what the rest of the operation can do.
So the thing worth building stacks like this. The booking platform is the system of record. A sensor layer sits on top of it, reading the bookings, the forms, the field radios, and the messages the crew already writes. Underneath is a live model of the operation: people, qualifications, assets, geography, timing, and permits, with the real rules encoded. A reasoning engine works out what each change breaks. Then the system acts, and a human stays in the loop on anything touching money, compliance, or safety. That shape is the same in field services, hospitality, marinas, events, and tours.
So here's the question I'd put to anyone who runs one of these businesses: what's the update you stopped making in your software because it was faster to just remember it? That gap is the product. The longer version is here.
What is the seam worth building?
Booking software is a solved, mature, well-funded category. The operation that starts the second a booking lands is none of those things, and that gap sits under every service business that runs on bookings: field services, hospitality, marinas, events, tours. Whoever works out how to let an AI operate safely on a live, structured model of a real operation is building the thing the last decade of software left on the table.
I don't think that gets built from a slide, or by a team that has never had to get a van to a takeout with no cell service. It gets built by people who have run the operation and know exactly where it breaks. I think this is bigger than my company, and it is the work I most want to build next.
That is not just my read on it. The industry's own connectivity standard now covers products, availability, bookings, pricing and pickups, and has nothing at all for crew, vehicles, equipment, qualifications or permits. Selling the seat is standardized. Delivering it is not.
The most expensive version of this is capacity. I built an engine that knows how to fill the season, and it can only advise.
The open question
Should this governed action surface live inside the system of record, or in a new operating layer on top of it?
The invocation layer is standardizing fast: MCP already supports action tools, scoped authorization, and destructive-operation metadata, and write actions are shipping in production agent platforms now. Computer use means an agent will increasingly act even where no clean API exists. So the question is no longer whether a platform has a read/write API. It is whether it exposes reliable, governed, machine-operable actions over trustworthy state, through whatever interface. I ran the operating-layer version of that answer for a full season. This spec is v1 of what I think the minimum has to be.