AI Agents
AI agents for airline crew scheduling: rostering, reserves, and recovery under FAR 117
Crew is the constraint that turns a two-hour delay into a cancelled bank of flights, and every reassignment has to clear duty-time law before it's legal. Here's where an agent helps a crew controller during IROPS, what stays with the optimizer and the human, and why FAR Part 117 is the boundary the agent proposes up to but never crosses.
A line of thunderstorms parks over a hub for ninety minutes, and by the time it clears the problem has moved. It’s no longer the weather. It’s the crews.
A captain is now three hours into a duty day that can’t legally absorb the delay. The first officer for the next leg is sitting in a different city. A reserve pilot at home has a phone that hasn’t rung yet. The aircraft is fine. The crew is the constraint.
Crew recovery is the hardest problem in irregular operations. It’s also the one an AI agent gets pointed at with the least thought about where it has to stop. So let me put the boundary first.
An agent can watch the roster, assemble the context a crew controller would gather by hand, and propose a legal reassignment in seconds. What it can’t do is decide the reassignment is legal on its own judgment, or commit it. Duty-time law is the boundary, and the agent proposes up to it. It doesn’t sign.
This is the crew side of a disruption. The passenger side is a different agent on a different system of record. Confusing the two is how a project ships an agent that rebooks travellers beautifully and mis-rosters a pilot into an illegal duty period.
Why crew is harder than the aircraft or the passenger
Rebooking a passenger is a search over available inventory. Recovering a crew is a search over people. Each one carries a running clock, a qualification set, a home base, and a contract, and a candidate solution has to satisfy all four before it’s even allowed to exist.
The qualifications are hard constraints. A pilot is current on a type or is not. Putting an A320-current first officer in a 737 right seat is not a worse plan. It’s not a plan.
Base assignments, route language qualifications, and recency narrow the pool the same way. Then the contract narrows it again. The collective bargaining agreement governs how reserves are called, how much rest counts as rest, and what the airline owes a crew member it reassigns. None of that is in the regulation, and all of it is enforceable.
The aircraft has one state. A crew member has a state, a history, a qualification set, and a contract. The legal reassignment is the one that clears all of them at once.
The legal clock sits on top of that. It’s the reason crew recovery is a real-time problem and not a next-morning one. A delay doesn’t just push a departure. It pushes a duty period toward a limit that, once crossed, cancels the flight no matter how many willing pilots stand in the terminal.
The rules the agent has to reason inside
For US Part 121 passenger carriers, the clock is 14 CFR Part 117, the FAA’s flight and duty-time rule. Any assignment an agent proposes is something Part 117 will permit or forbid. So the rule is worth stating in the terms the agent has to check.
Flight time for an unaugmented crew is capped at nine hours. The flight duty period runs from report until the aircraft blocks in on the last leg. Table B caps it, and the cap is not one number: it moves with the crew member’s acclimated report time and the number of segments, from around fourteen hours down to nine.
An augmented crew with onboard rest facilities gets more under Table C. That’s an aircraft configuration, not a lever a controller pulls in the moment.
Rest is the other half. Part 117 requires ten consecutive hours before a flight duty period, with an eight-hour uninterrupted sleep opportunity inside it. Ten hours of rest is not ten hours of sleep, and the rule counts the opportunity, not the outcome.
On top of the per-duty limits sit cumulative ceilings. A recovery plan can breach these even when each leg looks fine: 100 flight hours in any 672 hours, 1,000 in a year, and 60 flight-duty-period hours in any 168 hours with 190 in any 672.
Reserves are their own sub-problem. A reserve pilot is available inside a defined availability period, and there’s a difference between long-call reserve, who gets notice, and short-call, who can be assigned inside the current window. Shifting between the two is itself governed by rest. So “call a reserve” is never one move. It’s a legality check against that reserve’s own clock and status before the call is worth making.
What the agent actually does in the loop
Salesforce has no native crew-operations product, so treat the design below as an architecture, not a feature you switch on. The crew management system, whether a specialist rostering platform or an in-house optimizer, stays the source of truth and stays the thing that computes the optimal solution. The agent is the reasoning and communication layer in front of it, and it earns its place in four steps.
It watches. A delay or a sick call lands as an event, and the agent sees a duty period trending toward a limit before a human has finished reading the ACARS message. That’s the posture of an operational agent that detects the exception rather than waiting to be asked.
It assembles. The agent pulls the context a controller would otherwise gather from six screens. Who is qualified on this type, at this base, with hours left on every clock. What reserves are available and in which status. What the contract says about this reassignment.
Grounding that well is the whole game. Qualifications, recency, base, contract terms, and the running duty state have to come together so the agent reasons over one picture instead of guessing. Grounding the agent in the systems of record through governed integration is what separates a useful proposal from a confident wrong one.
It proposes. The agent hands the controller a short list of legal options with the reasoning attached: reassign this reserve, deadhead this crew member to reposition them, swap these two pairings. Each option shows the clocks it respects and the contract cost it carries. The controller approves a decision instead of reverse-engineering one.
It executes, after a human approves. The agent writes the change back into the crew system, notifies the affected crew, and updates everyone downstream. The notification leg is not a footnote. A plan that’s legal on paper and never reaches the pilot is not a recovery.
What stays with the human and the solver
Two things never move to the agent, and the project that tries to move them is the one that fails.
The optimizer stays specialist. A network-wide crew recovery under cumulative limits is a large combinatorial problem, and mature airline systems solve it with operations-research engines built for it. A language model does not out-optimize a solver, and it shouldn’t try. The agent makes the solver’s output legible, works the single-crew exceptions a controller handles by hand, and runs the conversation with the crew.
The signature stays human. Crew recovery decisions carry contractual and safety weight, and they belong to a licensed crew controller who is accountable for them. The agent proposes; the human disposes. That’s the human-in-the-loop pattern in its strictest form, because a wrong autonomous action here is a grievance, a fatigued crew, or a violation, not a re-sent email.
Where it breaks, and the one thing you can’t get wrong
The failure mode that should keep you up is a legality check the agent computed itself. Ask a language model whether a duty period is legal under Part 117 and it will produce a fluent, plausible, sometimes wrong answer. A wrong “yes” is a rostered violation.
The rule is not a place for probabilistic reasoning. The legality test has to run as deterministic logic, a rules engine or the crew system’s own compliance check. The agent calls that check and reports its verdict. It is never the check itself. Putting hard guardrails around the agent’s actions stops being a nicety in this setting and becomes the design.
The rest of the hurdles are the ordinary ones, sharpened. The crew system is the source of truth, so an agent working from stale duty state proposes against a clock that already moved. Latency matters too: a proposal that lands after the duty period expires is a history lesson.
And the contract layer is airline-specific. The reserve rules, the rest definitions, and the reassignment obligations are negotiated, so the agent reasons inside the version in force, not a template lifted from another carrier.
What to build first
Don’t start with autonomous recovery. Start with the assembly step, where the agent removes the most toil at the least risk.
Give a crew controller an agent that, the moment a duty period trends red, pulls the qualified-and-legal candidate list, the reserve availability, and the relevant contract terms into one view. Show every clock. Run the deterministic legality check against each option. That alone turns six screens and four phone calls into one reviewed decision, and the agent never commits a change.
Earn the write-back and the crew notification next, behind an explicit approval gate, once the assembly layer has proven its context is right often enough that a controller trusts it. Keep the optimizer where it is. Keep the signature with the human. Keep the Part 117 verdict in a rules engine that can’t hallucinate.
Do that, and the agent becomes what a good crew controller wants at 6 p.m. on a thunderstorm day. Not a system that decides. One that has already done the reading.
Understanding the basics
Can an AI agent legally schedule airline crews on its own?
Not the legality decision, and not the commitment, for a US Part 121 passenger carrier. Flight and duty limits under 14 CFR Part 117 are hard law, and whether a proposed assignment complies has to be determined by deterministic logic, a rules engine or the crew system’s compliance check, not by a language model’s judgment. An agent can watch the roster, assemble the qualified and legal candidate list, and propose reassignments in seconds, but a licensed crew controller approves the plan and the crew system records it.
What is FAR Part 117 and why does it constrain a crew agent?
14 CFR Part 117 is the FAA rule governing flight time, flight duty periods, and rest for flightcrew at Part 121 passenger operators. It caps unaugmented flight time at nine hours, limits the flight duty period by report time and segment count through Table B, and requires ten hours of rest with an eight-hour sleep opportunity before duty. Cumulative ceilings apply too, such as 100 flight hours in 672. Every reassignment an agent proposes has to fit those limits, which is why they’re checked authoritatively rather than estimated.
How is a crew recovery agent different from a passenger reaccommodation agent?
They solve different problems on different systems of record. A passenger agent searches available inventory in the reservation system and rebooks travellers. A crew agent searches people against duty clocks, qualifications, base, and contract terms in the crew management system, where a wrong move is a rostered violation rather than a re-sent itinerary. They often run during the same disruption, but keeping them as separate agents with separate boundaries is the safer design.
Where does Salesforce fit if it has no crew-ops product?
As the reasoning, grounding, and communication layer in front of the specialist crew system, not a replacement for it. Agentforce can detect the exception, assemble context through governed integration to the crew and HR systems, present legal options to a controller, and run the crew notification and case management once a human approves, with Data 360 unifying the qualification, contract, and duty-state context the agent reasons over. The optimization engine and the Part 117 compliance check stay where they are.
Standing up an operations agent that assembles the decision without ever making the call it isn’t allowed to make, grounded in your crew and reservation systems with the boundary drawn where the regulation draws it? Talk to us, getting the grounding right and the guardrails hard is exactly the work that makes an operational agent trustworthy. Our Agentforce practice builds this kind of thing.
