The Red Hat Summit 2026 keynote teased two customer use cases on the main stage: one running production workloads on highways here on Earth, one running in space. I went looking for the space one on the show floor, and found Josiah Johnson, Operations Support Center Systems Architect at NASA’s Marshall Space Flight Center in Huntsville, Alabama. What he described is one of the more distinctive AI infrastructure stories I heard all week — not a chatbot, not a copilot, but real-time decision support wired directly into a human spaceflight mission.
A Center Built on Propulsion
Marshall’s legacy is not incidental context — it is the reason this conversation carries weight. This is the center behind Saturn V, the rocket that took Apollo to the Moon, and a center with deep roots in the Space Shuttle program’s propulsion systems. Marshall’s mission today is delivering the most vital propulsion systems, hardware, flagship launch vehicles, and world-class space systems for NASA.
The operational arm of that mission is the Huntsville Operations Support Center (HOSC). Johnson’s team runs it around the clock: ingesting massive scientific data streams from space operations, providing 24/7 mission support, and handling scientific payload integration and maintenance for hardware on board the International Space Station. The HOSC is not a research lab experimenting with pipelines on the side — it is the operations floor that flight controllers and payload scientists depend on today, with astronauts and hardware on the other end of the data.
What Artemis 2 Adds to the Picture
Artemis 2 will send a crew around the Moon and back — NASA’s first crewed lunar mission since Apollo — and Johnson’s team is building the data layer that supports engineers making real-time calls during it.
The numbers he gave me are worth sitting with: 907 virtual workloads processing 340,000 parameters to help engineers make the right decisions in real time. That is not a single model serving predictions — it is nearly a thousand distinct virtual workloads, each contributing a slice of the parameter space flight engineers need synthesized fast enough to act on. Layer on top the preparation behind it: hundreds of simulated launches and thousands of hours of rehearsal, all before a crew ever sits on top of the rocket. The workload count and the rehearsal hours are two sides of the same requirement — you do not get to run this kind of decision infrastructure live for the first time on launch day.
Compare that to the AgentOps demos I watched a few hours later on the same keynote stage — guardrails wrapping an LLM so a lemonade-stand chatbot cannot be talked into discussing oranges. Both are “real-time AI decision support.” The gap is what happens when the decision is wrong: a blocked jailbreak prompt is a bad demo, a bad real-time call during a lunar flyby is not something you get to retry. Johnson’s team operates at the end of that spectrum where the tolerance for failure is close to zero.
Infrastructure That Cannot Fail Quietly
What struck me talking to Johnson is how unglamorous the actual engineering problem is, once you get past the mission romance. The HOSC’s job is fundamentally about throughput and trust: get telemetry data from spacecraft and station hardware to the people who need it, fast enough and reliably enough that they can act on it without second-guessing the pipeline. That is the same problem every platform engineer building observability or real-time inference systems is solving — just with a launch vehicle and a crew attached to the outcome instead of a service-level agreement.
It is also where Red Hat’s enterprise pitch gets tested. The keynote’s framing — infrastructure trusted for a NASA mission is infrastructure you can trust for your own workloads — is not just marketing copy once you have heard the underlying numbers from the person who owns the operations center. Nearly a thousand virtual workloads processing real mission telemetry in real time is a harder bar than most “mission-critical” enterprise systems will ever clear. Worth noting: the same week I heard Marshall’s numbers in Atlanta, astronaut Tim Peake was closing out RoachFest London with a related point from the other side of the same coin — resilience in space systems is a design discipline, not an accident.
Why This Story Matters Beyond NASA
Most of what I saw on the Summit show floor was about guardrails and agent governance — keeping LLMs from going off-script. Johnson’s team is solving a related but harder problem: process hundreds of thousands of parameters across hundreds of concurrent workloads fast enough that a human engineer can trust the output during a live, physically consequential event. If your AI infrastructure can survive the rehearsal discipline of an Artemis 2 flight — thousands of hours of rehearsal, hundreds of simulated launches, zero tolerance for a missed real-time call — it can survive whatever your own production environment throws at it. Marshall’s Saturn V and Space Shuttle legacy is the backdrop. The 907 workloads and 340,000 parameters are the engineering answer to what comes next.
Related Reading
- Red Hat Summit 2026 in Atlanta: Open Source Meets AI
- Red Hat Summit 2026 Keynote: Eight Announcements That Matter
- RISC-V in Space: Radiation-Hardened Open Silicon
- AgentOps in Production: Hands-On Lab at Red Hat Summit 2026
- Infrastructure Resiliency: Patterns That Keep
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of platform engineering, cloud security, and enterprise AI deployments. Book a consultation.
