The Parable of Three Schedulers and the Future of Air Operations
2025 was a transformative year for OpsLab. We scaled our automation capabilities across dozens of new squadrons, brought our first generative AI features to production, and expanded our footprint beyond U.S. borders. More importantly, we learned something fundamental about what we're building - not from our own roadmap, but from watching how our customers actually use our systems. Let me explain.
Last month, I visited a base and sat down with three different schedulers. Each of them used our automation tools. Each of them loved the results. But when I asked them to walk me through their workflow, I discovered something fascinating: they each approached scheduling in completely different ways.
The first scheduler built his week one day at a time. Monday first, then Tuesday, then Wednesday - sometimes leaving Thursday morning deliberately empty before moving to Friday. The second scheduler organized their work by mission type: throw in all the sorties first, then simulators, then ground duties, verifying each category before moving to the next. The third scheduler thought about seniority: schedule the senior pilots and VIPs first to lock in the most important commitments, then the upgrade pilots and students, and finally fill in the gaps with whoever's qualified and ready.
Three schedulers. Same squadron. Same data. Three entirely different mental models for how to build an effective flying schedule.
This moment taught us a powerful lesson, signs of which we've been observing more and more across our customer base lately: OpsLab isn't just a scheduling tool anymore. Our users don't think of us in terms of discrete features - automation here, data management there, reporting somewhere else. They think of us as a single integrated system that needs to flex to their way of working. They want to live in our application, conduct their entire workday within it, and have it adapt to them rather than the other way around.
In short, we're becoming a true mesh between these application layers, essentially, a more complete operating system for air operations. And as we look toward 2026, everything we're building will reflect that reality. Let’s dive into the three components of what this strategy will look like:
1) The Road to Automation: Making Intelligence Work for Everyone
Our first major initiative for 2026 is what we're calling the "road to automation" - a systematic effort to ensure every squadron can actually extract value from our intelligent scheduling capabilities, not just access them.
When we deployed automation features over the past year, we learned that adoption wasn't primarily a technical problem. The schedules our algorithms generated were high-quality. The issue was trust. When schedulers clicked "optimize" and a schedule appeared, their first question was always: "Why?" Why did the system make these assignments? Why is this pilot on this mission? What rules drove these decisions?
We're addressing this head-on by embracing the IVO principle: the idea that any automated output is only production-ready if users can immediately validate the system output. That means two things for us.
First, we're making our rule-checking engine completely transparent. Right now, users aren't aware of many of the complex rules our system validates when building schedules. They learned them during onboarding and then forgot them. In 2026, those rules become visible in real-time. As you build a schedule, the rule engine runs continuously, showing you every constraint you're violating and every requirement you're satisfying. You'll know exactly what the system is checking for.
Second, and more fundamentally, we're changing how our automation relates to the work schedulers have already done. Our original approach assumed the system should fix mistakes automatically - if you accidentally assigned a pilot to the same mission twice, the optimizer would quietly correct it. We thought we were being helpful. But users told us they actually don't want that. They want their decisions to persist, even if they technically violate a rule, because there's often an intangible, human reason for that decision that no algorithm can capture.
So we're making the optimizer work around human judgment rather than override it. If you've placed a pilot somewhere for a reason we don't understand, the system will respect that and build the rest of the schedule accordingly. We're protecting your work, not replacing it.
The metrics we're targeting here are ambitious: a 10x increase in scheduled sorties built using our automation, and a 20x increase in automation workflows by year-end. But the real goal isn't the numbers - it's making sure that when schedulers interact with our intelligence, they feel more capable, not less in control.
2) Generative AI: From Chatbots to Customized Workflows
Our second major thrust is generative AI, and we're approaching it through four concrete use cases that users have explicitly asked for.
The first is straightforward: users want to understand their own data. They have questions - "How many sorties did we fly last month?" or "Which pilots are overdue on their currencies?" - and they want answers without having to build custom queries or export spreadsheets. Our LLM-powered interface translates natural language questions into database queries and returns clear, conversational responses.
The second use case is automating mundane tasks. Schedulers told us they want to tell a chatbot to do things that would otherwise take twenty clicks - simple administrative work that's necessary but tedious. This is where we're bringing in agentic capabilities, allowing the system to actually execute actions on behalf of users rather than just retrieving information.
The third is ad hoc report generation. Here's a scenario that happens constantly: a higher-up sends an email requesting a detailed report by the end of day. The scheduler drops everything, spends hours building a massive Excel file, sends it up the chain, and then... crickets. No feedback, no follow-up, just back to their regular work. They're disconnected from the impact of their effort. So they want the system to generate these reports automatically. They'll still review and edit them, but the heavy lifting of structuring data and formatting spreadsheets can be handled by AI.
The fourth use case is the most exciting to me, and it connects directly back to those three schedulers I mentioned earlier. Instead of having everyone click the same "optimize" button and get the same workflow, we're letting users describe how they want the automation to run. Tell the chatbot: "Build Monday through Wednesday, leave Thursday morning empty, then build Friday." Or: "Schedule all sorties first, then simulators, then ground duties." Or: "Start with senior pilots, then upgrades, then fill in the rest."
The chatbot extracts structured data from that conversation, configures the optimizer accordingly, and runs automation the way that specific scheduler thinks about the problem. One button doesn't fit all - so we're replacing the button with a conversation.
3) Deployments: Federated Systems, Shared Intelligence
The third major area of focus is expanding beyond our current operational footprint - but not in the way you might expect.
When we add a new squadron today, we give them a table in our database. They're part of one large, shared system. But as we scale internationally, particularly with NATO partners, we're standing up completely separate instances of SkySchedule. Each nation gets its own sovereign system with its own data, its own security posture, its own operational control.
The challenge - and the opportunity - is making these federated instances talk to each other when they need to.
Imagine a French pilot visiting a U.S. base for a training exercise. Their qualifications, their currency status, their flight hours - all of that data lives in the French instance of SkySchedule. But they're flying missions from a U.S. base that's running the U.S. instance. We need to know that the pilot sitting in that cockpit is a French pilot, that their identity and records persist across systems, and that the right data flows to the right place at the right time.
This isn't just a deployment challenge - it's a fundamental architectural shift. We're building a data mesh layer that enables cross-instance data persistence while respecting the sovereignty and security requirements of each system. It's a federated model where instances can remain independent while still being interoperable.
This work will define much of our technical roadmap in 2026, and it's critical not just for international expansion but for our vision of becoming an operating system for air operations. If you're going to be the central platform that powers air operations, you need to be able to operate at scale, across boundaries, with multiple instances working in concert.
The Thread That Connects It All
These three initiatives might seem disparate, but they're all responses to the same underlying insight: our users want SkySchedule to be more than a tool. They want it to be the place where air operations happen.
That means meeting different users where they are, adapting to their workflows rather than forcing them into ours, and connecting systems that were never designed to talk to each other. We didn't set out to build an operating system for air operations. But as we've listened to our customers, watched how they use our systems, and understood what they're really asking for, that's the direction we’re headed. And in 2026, we're leaning into it fully.
At the end of the day, our mission remains the same: improve the quality of life of warfighters and make operations efficient. But the way we're accomplishing that mission is evolving. We're not just optimizing schedules. We're building an ecosystem that every other air operations function can plug into. We're making it possible for schedulers, training shops, standardization offices, and command elements to work from a single source of truth with tools that adapt to their needs.
That's what 2026 is about. Not just doing more of what worked in 2025, but building toward a larger vision of what an operating system for air power should be. And if those three schedulers taught me anything, it's that we need to build a system flexible enough to work the way each of them thinks - because they're all right.
