Our Deliberately Unreasonable AI Test
We intentionally give STRATUM AI missions that are too large for a scripted demo because that is where architectural weaknesses become obvious.
We have been testing STRATUM AI with prompts that are intentionally excessive. One recent example asked it to build ten switches, deploy ten Windows Server 2025 VMs, install Guest Tools, create an Active Directory domain, join the remaining Windows systems, fully patch them, and then build ten Red Hat Linux VMs with PyTorch, llama.cpp, additional data disks, distributed AI inference, a web front end, Nessus scanning, and recurring patch and vulnerability-scan schedules.
That one request represents twenty VMs, ten switches, operating-system installation, networking, Active Directory, patching, storage, AI software, distributed inference, vulnerability assessment, credentials, reboots, and scheduling. It is deliberately unreasonable because every hidden assumption starts to surface. A Windows template may have 2 GB of RAM when the installer needs 4 GB. A disk may need to grow. A user account may be required. A package installation may take longer than expected. One machine may fail while nineteen others continue normally.
A useful infrastructure AI has to recognize those conditions and adapt. It might discover the RAM requirement before boot, or encounter the installer error later, stop the VM, increase memory, and continue. It may ask the user for credentials during planning, or create approved credentials and return them securely afterward. The LLM still never needs to see the actual secret values because STRATUM handles those inside the harness.
We use large missions like this because they force STRATUM AI to behave like an infrastructure operator instead of a scripted demonstration. They exercise planning, concurrent DAG execution, GUI control, Skills, recovery, policy, secure credentials, scheduling, and independent verification in one mission.