TowerOps

Inspiration

The idea for TowerOps came from seeing an Instagram reel about two aircraft operating with the same callsign. That kind of ambiguity can create confusion between pilots and controllers, especially in busy airspace where clarity and timing matter. We wanted to build a system that helps catch those risky situations early, surface the conflict clearly, and support safer decision-making.

What it does

TowerOps is a synthetic air-traffic-control assistant focused on conflict awareness and communication safety.

It monitors simulated traffic, detects hazardous situations such as callsign confusion and loss-of-separation risk, and proposes safe next actions. The system is designed to:

• identify potential aircraft conflicts

• flag callsign ambiguity

• suggest resolution actions

• verify communication intent and readback consistency

• fail safely when confidence is low or state is uncertain

Instead of replacing a controller, TowerOps acts like a decision-support layer that helps reduce avoidable communication and coordination errors.

How we built it

We built TowerOps as an agentic ATC workflow around structured traffic state, conflict detection logic, and an LLM-powered reasoning layer.

At a high level, the system:

1. ingests aircraft / traffic state

2. evaluates proximity, trajectory, and communication context

3. detects possible conflicts or ambiguity

4. generates a recommended controller response

5. records and presents the result in a form that is easy to review in a demo setting

We focused on a 2D radar-style presentation because that matches how ATC situations are often understood operationally and makes the demo easier to follow.

Challenges we ran into

One of the biggest challenges was balancing realism with the time available for a hackathon submission. Air traffic control is a safety-critical domain, so even a demo needs to be careful about how it frames recommendations.

Other challenges included:

• representing traffic state clearly enough for an agent to reason over

• handling ambiguous cases like same-callsign traffic

• making outputs understandable instead of overly technical

• keeping the system safe by failing closed when it is not confident

We also had to decide how much realism to simulate versus how much to simplify so the project would remain coherent and demoable.

What we learned

We learned that ATC-style problems are not just about path planning — they are also heavily about communication, ambiguity management, and trust. A useful system in this space must do more than generate an answer; it has to explain risk clearly and behave conservatively when uncertainty is high.

What's next for TowerOps

Next, we want to expand TowerOps with:

• richer traffic simulations

• more scenario coverage

• stronger separation/conflict prediction

• better controller/pilot dialogue handling

• improved visualization and replay tools

• broader evaluation against realistic edge cases

Long term, we see TowerOps as a safety-oriented ATC copilot that can help surface issues earlier and support better human decisions.

Built With

• amazon-web-services
• bedrock
• fastapi
• python
• strands
• streamlit