For the last couple of months, we have been quietly building something that started with a very simple question:

What would it take to build an AI Air Traffic Controller that actually understands the operation, not just the phraseology?

Not a chatbot with an aviation prompt, not a system that simply reacts to the last transmission, and not an ATC voice generator that happens to know how to say "cleared to land."

We wanted to build a controller.

Very quickly, we realized that meant building much more than a controller.

We also realized something else very early: we did not want to be the people deciding whether our own ATC system was convincing.

If we were going to take this seriously, at some point somebody who had actually spent a career on the other side of the frequency was going to have to look at it and tell us where we were wrong.

More on that later.

State before language

ACE of ATCs is designed around the actual operational state of the airport and the airspace. Aircraft are not treated as isolated conversations. They exist inside a continuously changing traffic picture where position, route, runway configuration, sequencing, taxi state, frequencies, clearances, previous instructions and the movement of other aircraft can all affect what should happen next.

ACE maintains that state continuously. It knows where an aircraft is, where that aircraft is supposed to go, and whether it is arriving, departing, taxiing, holding, lining up, landing or parking.

An instruction issued thirty seconds ago still matters thirty seconds later. A decision made for one aircraft may affect several others.

That is where a huge part of our work has gone.

From gate to gate

ACE is not limited to one phase of flight. The same system can carry an aircraft through:

Taxi -> Departure -> En-route / Arrival -> Approach -> Landing -> Taxi -> Parking

while preserving operational state throughout the entire chain.

On arrival, ACE can work with sequencing, descent, vectoring, approach clearance, landing and runway vacation. After landing, the aircraft does not simply disappear. The operation continues through frequency changes, Ground handoff and the taxi network toward parking.

Departures and arrivals can exist inside the same operational picture.

The controller is not the entire brain

This became one of the most important architectural decisions in ACE.

We did not build one giant AI model and ask it to control everything. Behind the controller sits an operational architecture responsible for looking at the traffic picture before the radio transmission is ever generated.

That includes our AMAN, Arrival Manager, which looks ahead at inbound traffic, arrival demand and sequencing rather than treating each arriving aircraft as an isolated conversation.

Then there is DMAN, our Departure Manager, which looks at the outbound side of the operation, including departure demand and how those departures fit into the larger airport picture.

Above those systems sits what we internally call the Director.

The Director is not another radio controller. It is an orchestration layer whose job is to look at the larger operational picture and coordinate what is happening underneath it.

A Tower controller should not have to rediscover the entire airport every time a pilot presses the PTT button. A Ground controller should not invent the ground operation from scratch, and an arrival controller should not sequence aircraft without understanding what is happening ahead.

The intelligence is distributed across the system.

The controller is the part the pilot talks to. It is not the entire brain.

The radio is an interface, not the source of truth

ACE does not reconstruct reality from a transcript because the system already has its own operational state. The radio conversation interacts with that state rather than defining it.

That means ACE can reason about information that may not have been spoken in the last transmission at all: aircraft position, route progression, runway occupancy, traffic ahead, previous clearances, controller ownership and what the aircraft should logically be doing next.

That separation between language and operational state has become one of the foundations of the project.

Route awareness and progression

Aircraft are not simply pushed toward random waypoints. ACE follows route structure and understands where an aircraft currently exists within that route.

The controller can therefore work with the progression of the flight instead of repeatedly reconstructing it from scratch. The same philosophy continues during approach, landing and taxi operations.

Progression matters. History matters. State matters.

Readbacks matter too

Pilots can read instructions back, and ACE validates those readbacks against the clearance that was actually issued. A correct readback can progress the operation, while an incorrect one can be challenged.

The system therefore has a concept of what it said, what the pilot was expected to read back, what the pilot actually said, and whether those things agree.

That sounds simple until you try to maintain it across a stateful operation involving multiple aircraft, multiple clearances and multiple controllers.

And this is also where having someone around who has actually worked real traffic becomes uncomfortable in the best possible way.

A developer can look at an interaction and think, "That sounds right."

A controller can look at exactly the same interaction and say, "No. Why would I do that?"

We have heard that question more than once during development.

And ACE is better because of it.

Frequencies are operational boundaries

Tower and Ground are not simply different AI personalities with different voices. They are operational roles.

An aircraft that changes frequency should not continue interacting with the previous controller as if nothing happened. The controller handling an aircraft matters. Frequency matters. Handoffs matter.

Those boundaries exist inside ACE rather than being left entirely to the language model.

Then we went further down the aviation infrastructure rabbit hole

Our work around aviation systems has also taken us into areas such as AFTN and AMHS, the messaging infrastructure used throughout real-world aviation operations.

That work is separate from ACE itself, but it strongly influenced the way we think about system architecture.

Aviation infrastructure teaches you very quickly that important operational information cannot simply live inside a conversation. State needs to exist independently, events need to be traceable, transitions need to be observable, failures need to be reproducible, and systems need to know what happened before something went wrong.

That philosophy now runs throughout ACE.

Clearances, state changes, controller actions and operational transitions are not treated as disposable lines of text. They are part of a larger causal system.

So, for the software engineers and aviation infrastructure nerds reading this: yes, we care about causality, deterministic state transitions, missing context, handoffs, reconnects, incorrect readbacks and what happens when the pilot tunes the wrong frequency.

And yes, we have spent an unreasonable amount of time deliberately trying to make ACE fail.

Because making an AI sound like ATC is not particularly interesting to us.

Making it understand what the controller is responsible for is.

Then we started feeding it the real world

Eventually, we connected ACE to live traffic data and started running the system against real operational traffic pictures.

That changed the question.

It was no longer:

"Can an AI control an airplane?"

It became:

"Can it understand an airport?"

That is the problem we have been working on ever since.

We have built regression tests, causal checks, operational guards and end-to-end scenarios specifically to find situations where the system might sound convincing linguistically while being wrong operationally.

Because for us:

Sounding like ATC is the easy part. Thinking like ATC is the product.

And we think we have built something fundamentally different from what people currently expect when they hear the words "AI ATC."

That confidence does not come only from us running our own tests and congratulating ourselves when they pass.

For a significant part of this journey, someone with decades of real-world ATC experience has been looking over our shoulder, challenging decisions, questioning behavior and occasionally sending us straight back to work.

We will introduce him properly in a moment.

First, there is something we want from you.

Public Beta

ACE of ATCs is entering BETA.

For the first public beta, we are opening exactly 10 seats.

Not because we are trying to manufacture scarcity.

Because we want the first ten people using ACE to have our attention.

We want people who will actually fly, test, challenge and break the system. People who will notice when something operationally does not make sense and tell us exactly why.

If you are looking for a polished product where every edge case has already been discovered, wait for the release.

If you want to be one of the people who helps us discover those edge cases, this is your invitation.

We are particularly interested in experienced flight simmers, real-world pilots, controllers and people with enough aviation knowledge to make our lives difficult.

There are 10 places.

If you want one of them, email us at:

[email protected]

Tell us a little about yourself, what you fly, your aviation or simulation background, and why you want to test ACE.

We are not looking for ten people to tell us how impressive it is.

We are looking for ten people capable of proving us wrong.

And if ACE survives them, we open the doors wider.

One last thing

Remember the controller we mentioned at the beginning?

When we decided we wanted someone from the real world to challenge ACE, we did not exactly choose the easy option.

We wanted someone who had spent his career handling traffic at one of the busiest and most demanding airports on the planet.

Someone who would know immediately when something sounded clever but made no operational sense.

Someone who would not care how complicated the software was if the controller made the wrong call.

So we brought in Steve Abraham, retired JFK Ground Controller.

He did not come in to record a testimonial.

He worked with us.

He challenged the system, challenged us, talked ATC with us and helped us understand the difference between something that merely sounds like a controller and something that begins to behave like one.

And today, Steve officially joined ACE of ATCs.

We could write another thousand words telling you what he thinks.

But after everything above, that would be a ridiculous way to end this post.

Best of luck! Looking forward to learning more.

This is awesome new! Kennedy Steve and all! Great work Anil!

8 hours ago, iFlySimX said:

Best of luck! Looking forward to learning more.

Thanks a lot! Really appreciate that — especially coming from someone building on the commercial side of the flight sim community.

We’ve put a huge amount of work into ACE of ATCs, and we’re very excited to finally start showing what it can do. There’s a lot more to come very soon.

Would genuinely love to hear your thoughts once you’ve had a chance to see it in action!

6 hours ago, vonduck said:

This is awesome new! Kennedy Steve and all! Great work Anil!

Hey vonduck! Thanks a lot for your kind words brother.

Having Kennedy Steve on board is something we’re incredibly proud of, and we’re only just getting started.

Can’t wait to finally get ACE of ATCs into your hands! ❤️

Awesome! I believe I called Kennedy Steve back on the original announcement thread 😀

I look forward to learning more.

Edited Tuesday at 12:22 PM2 days by regis9

I look forward to watching this grow and develop. It seems like, at least at the moment, the software is geared towards larger airports and airliner traffic. Can you speak to how it will manage GA traffic from small and regional fields? Will it handle VFR flights?

How about you make simpassengers functional before you start a new product. It's better to have 1 good product, than 2 word not allowed ones.

1 hour ago, TangoSierraMike said:

I look forward to watching this grow and develop. It seems like, at least at the moment, the software is geared towards larger airports and airliner traffic. Can you speak to how it will manage GA traffic from small and regional fields? Will it handle VFR flights?

Yes I also only fly GA. Will this at all be for me? Competition has VRPs for leaving and entering control zones for example. How will you cater for us non jet/IFR pilots?

Major Best Wishes! The field all have various significant issues and it will be interesting to see what ACE offers.

We need a lot more operational detail rather than numerous one-liner "soundbites" akin to the "in a world...." movie trailers.

1. IFR, VFR, both, other options (VFR On Top, Special VFR, etc etc?)

2. AI integration: Does this work with packages like FSLTL live traffic, default MSFS live traffic, JustFlight, AIG injected traffic? Do you use your own injector? If so, what's the source?

   1. Will I be given traffic alerts (as well as AI pilots)?

3. FAA vs ICAO phraseology differences? JFK is infamous for their controllers not using formalized language (either FAA or ICAO approved) thus leading to a lot of problems with pilots trying to understand casual instructions in their non native language.

4. Aircraft types. Most here use modern jet airliners on scheduled routings. What about our light sport pilots? What about helicopter operations? Do you support proper helo phraseology such as "...at your own risk"?

5. Weather implementation: Is your ATC product aware of weather (live weather and/or user preset weather)? Can a pilot deviate around weather? Will ATC put you in a hold due to storms over an airfield or advise of storm fronts on the route and accommodate a different routing?

6. Non-standard procedures: Can I request a radar assisted approach? Can ATC implement LAHSO (land and hold short operations) at an airport due to traffic?

7. Ground taxiing: Will I be accurately directed to following company traffic to the runway (for example) if I'm operating as the same airline as an AI aircraft ahead of me?

Probably more questions but these are the immediate ones come to mind until more info is provided via follow-on responses or edits to the original post. Always interested in new ATC services but this really reads with a lot of superfluous marketing speaks. Give me the facts, not just the philosophy.

10 hours ago, regis9 said:

Awesome! I believe I called Kennedy Steve back on the original announcement thread 😀

I look forward to learning more.

You absolutely did, Dave (: You called it very early.

Kennedy Steve is indeed part of ACE of ATCs, and I think you’ll enjoy what we have coming next.

There is a lot more operational detail to share now, so I’ll be getting into that properly in this thread.

7 hours ago, Lerimer said:

How about you make simpassengers functional before you start a new product. It's better to have 1 good product, than 2 word not allowed ones.

You are def right! i had some family related problems that i had to handle, but everything is a-ok right now and a new version is coming up tomorrow.

8 hours ago, TangoSierraMike said:

I look forward to watching this grow and develop. It seems like, at least at the moment, the software is geared towards larger airports and airliner traffic. Can you speak to how it will manage GA traffic from small and regional fields? Will it handle VFR flights?

Good question.

The initial beta is focused on IFR operations, not specifically on airliners or large hubs. So the real boundary in the first release is flight rules, not aircraft size.

GA aircraft operating IFR from smaller and regional fields are absolutely within the intended scope, provided the relevant procedures and airport data are available.

VFR will not be part of the initial beta release. We are deliberately expanding the operational scope in stages, with VFR and broader GA operations coming later as the IFR core matures.

So in short: small aircraft, yes. Small airports, yes. IFR, yes. VFR, not in version one.

6 hours ago, Noel said:

Major Best Wishes! The field all have various significant issues and it will be interesting to see what ACE offers.

Thank you, much appreciated.

I agree, the ATC space still has some very real gaps, and that is exactly what made us want to approach it differently.

Over the next few posts I’ll be sharing more of the operational detail behind ACE, so you’ll get a much clearer picture of where we think those differences are.