Schiphol has largely solved the average day at security: 99.6% of travelers with a booked time slot wait less than ten minutes. What it has not solved is the disrupted day. When a storm, strike or IT failure builds up queues, opening an extra lane should relieve the pressure. But the new lane is announced to everyone, so everyone rushes there, and it simply becomes the next bottleneck. Our project, FlowPilot, uses AI to tell each traveler which lane to go to, so the crowd spreads out instead of moving as one. Working on it changed my view of what AI is really good for.
I took on the economic, competitive and ecosystem analysis and approached it as a chain of questions: what would FlowPilot cost, who would gain and who would pay, who could copy it, and who is the real rival?
What would it cost?
Going in, my hypothesis was that AI would undoubtedly be cheaper than human labor, based on my own use of AI tools and the countless news reports about AI replacing human workers.
The calculations told a different story. FlowPilot would cost about €489,000 a year, yet AI inference accounted for only €4,400 of that. Almost all the money went into building and running the system. Hiring 12 extra marshals on the five disrupted days, by contrast, would only cost about €40,000 a year. My mistake was confusing AI’s marginal cost with its total cost. As a user, I only ever saw the near-zero cost of one more query, the classic trait of an information good, as we discussed in class. The real cost lay in the fixed investment around it.
This changed the question I had to answer. If FlowPilot had no cost advantage, why was it worth paying for? I started identifying what AI could do that people could not. The answer lay in the very problem I described at the start: a single broadcast creates what we called in class a negative same-side network effect, because the more travelers follow the same advice, the worse it works. FlowPilot avoids this by giving each traveler an individual instruction, reaching them before they join a queue and without needing scarce security staff.
Who would gain, and who would pay?
Even so, I still expected the return to be the strongest part of our case. For society, FlowPilot would indeed create about five times its cost in value even without crisis benefits. But when I split the numbers by stakeholder, Schiphol itself would recover only about a third of its cost unless a crisis like its summer of 2022 was factored in. So I stopped leading with the return and built the case on reliability instead, with a break-even the pilot must prove: FlowPilot has to cut the damage of such a crisis by at least 5.5%.
Who could copy it?
During desk research, I found that several companies, including Veovo, Xovis and Copenhagen Optimization, already sell queue-sensing and prediction systems to airports worldwide. My first reaction was doubt: if so many established firms were already doing this, was our AI agent simply redundant? Had we picked the wrong project?
Looking more closely, I got a clearer picture. These systems stop at prediction and none of them tells the individual passenger which lane to go to. That gap was our opportunity. Yet the same gap could also be a threat, since adding an LLM layer would be cheap for these companies. So, should Schiphol build or buy? My answer was to buy or partner, because the software is easy to copy. The true moat, I believe, is the lane allocation authority. Only Schiphol can open a lane and make an allocation binding. Even the passenger interface is no moat: as we saw in class, travelers multihome across airline apps, the Schiphol app and AI assistants.
Feedback from class pushed this further. Professor Li highlighted our proposal for placing defensibility in Schiphol’s own infrastructure rather than in the AI itself. I turned that into a test: for every possible source of advantage, I asked whether it was durable, copyable, or no moat at all. Only the lane allocation authority passed, and it became the basis of our strategy: own the lane, and open the interface to any app or agent.
Who is the real rival?
Within the competitive analysis, I also spent a lot of time on one question: who exactly are Schiphol’s competitors? Aviation is an unusual industry, and competition can be defined by locations, transfer fees, airlines and more.
In the beginning, I analyzed it from the airport’s perspective, but I gradually realized this would not solve our problem. We were redesigning one process inside Schiphol, security lane allocation, so the real question was what else could solve that problem. The answer surprised me: our biggest rival was Schiphol’s own time-slot system. It already shifts some travelers away from peak hours, but it has blind spots. It requires advance booking, it does not cover transfer passengers, and I suspect many travelers do not even know a slot can be booked. So we positioned FlowPilot where time slots cannot reach: disrupted days, walk-up travelers and transfer passengers. I took two lessons from this: define the unit of analysis before applying a framework like Five Forces, and a substitute can be harder to beat than any direct competitor.
Learning from collaboration
Collaboration shaped my thinking as much as the numbers did. My value estimates depended on my teammates’ simulation results, so we had to align constantly. We also had real debates. One was whether AI assistants such as ChatGPT could bypass our agent and then give travelers lane advice in their replies. I raised two possibilities: if Schiphol allowed these agents to use its data, they could become a promotional channel, especially now that ChatGPT shows ads; if not, they could at least link travelers back to FlowPilot. This debate fed into our final strategy of treating AI agents as channels rather than rivals. Looking back, I would bring the competitive analysis into the prototype discussions earlier, rather than after the design was set.
What I am taking away
So what is AI really good for? Not, as I first assumed, being cheaper than people. In our case, it won on coordination. I also recognized that the stakeholder who pays is not always the one who benefits, so value capture must be designed case by case. Above all, the moat lies around the AI, not in it. As Barney and Reeves argue in one of our course readings, AI amplifies the advantages a firm already has rather than creating new ones.
A recent popular view holds that AI products build their moat through the usage data they accumulate as they scale. Our project suggests a limit to this view: at a single airport, data plateaus quickly, and what cannot be copied is control over the lanes and exclusive access to the live data. Looking ahead, as AI agents become the front door to customers, the winners will not be those who own the interface, but those whose assets agents cannot bypass. Whether the same holds for platforms with millions of users is the question I want to explore next.
