Spencer Fuller
The Short Version
Section titled “The Short Version”I’m a Data Architect working with Palantir Foundry at an aerospace & defense company. Before that, I designed hardware that held rockets in place until the engines said otherwise.
My career has been a series of deliberate jumps between domains — aerospace mechanical design, spacecraft operations, data engineering, and now the intersection of data architecture and AI systems. Each jump sharpened the same skill: learning how complex systems actually work, then making them work better.
I’m based in Huntsville, Alabama. Rocket City. It’s not a coincidence.
The Longer Version
Section titled “The Longer Version”Aerospace Roots
Section titled “Aerospace Roots”I have a Master’s in Aerospace Engineering from Embry-Riddle Aeronautical University. My first engineering role was mechanical design on NASA’s Space Launch System — specifically the umbilical panels on the core stage. These are the interfaces between the rocket and the ground systems: propellant, gases, electrical, data. They have to connect perfectly, hold under load, and release cleanly at T-0.
That work teaches you something about interfaces that no software textbook covers. When your design failure mode is “rocket doesn’t launch” or “launch pad gets destroyed,” you develop a certain rigor about how systems connect.
The Pivot
Section titled “The Pivot”From mechanical design I moved into spacecraft operations, then progressively toward the data and software side of engineering. Not because I got bored with hardware — because I kept finding that the hardest problems in any system are information problems. How data flows. Where it gets stuck. What decisions it enables or prevents.
The transition wasn’t overnight. It was the kind of gradual shift that happens when you keep pulling on the thread of “why is this so hard?” and the answer keeps being “because the data architecture doesn’t support what we need.”
Where I Am Now
Section titled “Where I Am Now”Today I work as a Data Architect on Palantir Foundry, building the data infrastructure that aerospace and defense programs depend on for decisions. Ontologies, pipelines, integration patterns — the unsexy plumbing that determines whether a program can actually use its own data.
Outside of work, I’m building at the intersection of data architecture, AI agent systems, and infrastructure. I run a home Kubernetes cluster. I’m developing frameworks for AI agents that operate under fiduciary principles. I think a lot about how to make complex systems legible and trustworthy.
What You’ll Find Here
Section titled “What You’ll Find Here”This portfolio is organized around the work, not the résumé.
Open Source & Infrastructure
Section titled “Open Source & Infrastructure”Projects I’ve built and maintain — Kubernetes configurations, data pipeline patterns, infrastructure-as-code. Real repositories with real commit histories.
AI Agent Framework
Section titled “AI Agent Framework”Design documents, protocol specifications, and architecture decisions for building AI agents that actually serve their operators’ interests. This is active, ongoing work.
Architecture Decision Records
Section titled “Architecture Decision Records”The why behind technical choices. I believe decisions without recorded reasoning are decisions waiting to be repeated badly.
Case Studies
Section titled “Case Studies”Selected deep-dives into problems I’ve solved. Some are public; others are available on request for interview contexts. The protected ones contain proprietary context that deserves discretion.
How I Work
Section titled “How I Work”Immersion learning. I don’t learn from the edges in. I jump into the deep end and build understanding through direct contact with the actual system. Multiple career transitions have validated this approach — not because it’s comfortable, but because it produces real competence faster than any structured curriculum.
Pattern recognition across domains. The best insight I carried out of aerospace engineering isn’t any specific technique — it’s that good solutions to similar problems tend to converge on similar shapes, even across wildly different fields. Interface design patterns from rocket umbilicals show up in API design. Failure mode analysis from spacecraft operations applies directly to distributed systems. The underlying physics of complex systems rhymes.
Document the why. I record architectural decisions, design rationale, and the context that drove choices. Not because process is sacred, but because future-you (or future-someone-else) deserves to know what you were thinking.
If you want to talk about data architecture, AI agent systems, or why aerospace engineers make surprisingly good software architects — I’m not hard to find.