The setting
builds autonomy technology for vehicles and machines. is software and hardware that lets drones act on their own, made for defense and commercial customers.
A mixed mission can look ready on every aircraft and still fail as a group.
Aircraft-specific configuration protects platform flexibility, while a shared launch decision protects coordinated mission execution.
Who you’d be doing this for
“I had two crews tell me their aircraft were ready, then we lost the first run sorting out which mission each one had loaded.”
Tanvi Bhat · UAS Operations Manager · a character in this brief
Leads crews preparing mixed-aircraft autonomous missions for defense operations.
What is at stake
Mixed-aircraft crews lose flight runs when mission settings only conflict after launch setup. You must decide which aircraft signals earn a shared readiness result and which remain platform-specific.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- common readiness signals vs platform-specific autonomy states
- operator clarity vs diagnostic detail
- OEM flexibility vs reusable interfaces
- flight-test speed vs validation confidence
Why Applied Intuition
Drone autonomy deployments depend on making heterogeneous OEM aircraft operate as one coordinated mission.
Written with these in mind
Not your kind of problem? 93 more at Applied Intuition, or browse every organization.
Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.
The organization context comes from public information. The situation and characters are written for the brief.
Job postings it was written from
Public descriptions of the work at Applied Intuition. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.
- Senior C++ Software Engineer - Drone Stack (opens in a new tab)
- Integrate autonomy software into hardware in collaboration with autonomy engineers that supports full integration with aircraft autopilots, datalinks, sensors, PNT/GPS/INS, ground control stations, etc.
- As a Software Engineer on our Drone Stack team, you will design and integrate complex autonomy and vehicle intelligence systems spanning hardware and software domains.
- GNC Engineer (Guidance, Navigation & Control) (opens in a new tab)
- Your work will involve developing, integrating, and testing core flight autonomy capabilities that span all classes of aerial platforms (Group 1-5).
- Write software that operates real autonomous aircraft systems including F16 fighter jets, group 1-5 unmanned aerial vehicles (UAVs), as well as simulated models to accomplish tactical military missions
- Software Engineer - Robotics (opens in a new tab)
- Some days you might find yourself out in the field, integrating hardware and software directly onto vehicle platforms and pushing autonomy algorithms through live testing.
- Develop and adapt mission behavior, navigation, and decision-making logic to meet the needs of diverse defense platforms and missions
- Software Engineer - Multi-Agent UAV Autonomy (Defense) (opens in a new tab)
- Our defense customers are building fleets of unmanned aerial systems that have to fly, coordinate, and complete missions in the real world.
- This on-site role focuses on the capabilities defense customers rely on to design, train, and validate coordinated UAV behavior.
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.
Where similar work appears
Other live briefs connected to this one, and what connects them.
The same setting, from another role
Each is set around Applied Intuition’s Drone autonomy stack (DroneStack), written for a different role. They’re separate briefs, not the same scenario.
Vibration-related anomalies are returning because evidence is split across test results, build records, and failure reports.
You must decide where the correlation package stops and the mechanical engineers start, from joining the records in Python to naming the physical cause and entering it in Jira.
Payload changes are forcing crews to rebuild mounts and reroute cables between missions.
You must weigh field reconfiguration against flight time, survivability, and a pilot build that can be repeated.
One aircraft lost navigation quality during a vibration-heavy climb, putting the next multi-aircraft evaluation at risk.
You must weigh a durable avionics bay against the flight-time and release cost of added structure.
Other problems with a similar purpose
In each of these, as in this one, the aim is to turn fragmented, conflicting operational signals into one clear, actionable call.
Checking customers retry account actions when the mobile app and backend services tell an incomplete story.
You decide where the AI's trace of an incident stops and where the on-call engineer's confirmation of the cause begins.
Conflicting updates are letting carrier-integration risks reach readiness reviews too late.
You must decide which dependency changes the workflow sends straight to a Program Manager as uncertain and which it records as flags for the readiness record.
Regional production can stop while aggregate workspace activity still looks healthy.
You must decide where the ranking stops and the CSM starts: which signals set an account's place in the order, and which the CSM reads for themselves before choosing what to say.
