Als Betriebssystem kam ein prioritätengesteuertes Multiprozesssystem mit dem Namen „Executive” zum Einsatz. Dieses ermöglichte die gleichzeitige Verarbeitung von bis zu acht Prozessen, wobei einer davon ein Leerlaufprozess war, die übrigen sieben waren „arbeitende” Prozesse. Das Scheduling erfolgte dabei hauptsächlich mittels kooperativem Multitasking. Die Prozesse mussten das „NEW JOB”-Register periodisch (alle 20 ms) abfragen, dieses Register zeigte an, ob ein Prozess höherer Priorität vorlag. Da es sich beim AGC um einen Computer mit festgelegtem Bestand an Programmen handelte, der auch nicht laufend Software-Updates erhielt, funktionierte dies gut. Die Entwickler hatten immerhin die volle Kontrolle über die Programme des AGC. Dennoch waren sie sich durchaus bewusst, dass es möglich wäre, dass ein einzelner nicht reagierender Prozess die Arbeit anderer Prozesse blockieren könnte. Daher wurde im AGC auch eine preemptiv arbeitende Komponente, ein „Nachtwächter”, eingesetzt, die „Night Watchman”-Fehlererkennung: Das „NEW JOB”-Register enthielt die Information darüber, welcher Prozess gerade die höchste Priorität hatte. Erfolgte nun die Abfrage des NEW JOB-Registers durch die laufenden Prozesse nicht oft genug, verursachte der „Night Watchman” einen Restart. Daher auch der Einschub „Hauptsächlich”, zu Beginn dieses Abschnitts. Das Scheduling des AGC war also eine Mischung aus kooperativem und preemptivem Multitasking. Bei einem Restart eines Prozesses musste dieser auch nicht zwangsläufig komplett von vorn beginnen und seine (möglicherweise komplexen) Berechnungen komplett wiederholen; Restart-Tables ermöglichten es, einen Prozess an einem Restart-Point fortsetzen zu können. Da mehrere, nicht synchron laufende Prozesse gleichzeitig an der Arbeit sein konnten, die somit auch unterschiedliche Abarbeitungsfortschritte aufweisen könnten, war es nötig, Restart-Points unabhängig voneinander fortzuschreiben. Zu diesem Zweck waren die Restart-Tables in fünf Gruppen unterteilt. Damit dieses unabhängige Fortschreiben der Restart-Tables für die laufenden Prozesse funktionierte, mussten sich die gleichzeitig laufenden Prozesse dementsprechend in unterschiedlichen Restart-Gruppen befinden.

Darüber hinaus existierte noch die „Waitlist”, eine interruptgesteuerte Komponente, die für zeitgesteuerte Prozesse zum Einsatz kam. Bei diesen Prozessen, den sogenannten „Waitlist-Tasks”, handelte es sich um kurze Anweisungsblöcke, wie z.B. der Signalisierung des Ablaufs eines Timers oder auch das Auslesen der Beschleunigungssensoren. Durch einen Interrupt wurde der Prozessor in seiner aktuellen Tätigkeit unterbrochen, Fortsetzungsinformationen zum laufenden Prozess wurden gespeichert und schließlich der Code der jeweiligen „Waitlist-Tasks” ausgeführt. Während der Ausführung von „Waitlist-Tasks” waren (weitere) Interrupts unterbunden, was einen weiteren Grund dafür lieferte, in diesem Modus nur kurze Anweisungsblöcke auszuführen. Wenn ein längerer Prozess über die Waitlist ausgeführt werden sollte, so wurde nur die Planung dieses Prozesses unter deaktivierten Interrupts durchgeführt. Auch die Interrupt-Prozesse unterlagen Sicherheitsmaßnamen: Das Betriebssystem prüfte, ob eine Waitlist-Task zu viel Zeit im Modus mit deaktivierten Interrupts verbrachte („Rupt-Lock”).