You started out as a systems engineer at Cisco, spent almost a decade there, then went to MapR, then AWS, and now you're at Amazon AGI leading adoption. That's a pretty wild arc. Most people who start in infrastructure don't end up owning how millions of builders discover and stick with AI products. Was there a specific moment where you realized the thing you actually care about is getting this stuff into people's hands, or did it just kind of happen gradually?
Honestly, it happened gradually, but looking back there's a clear through-line I didn't see at the time.
I grew up when the internet was becoming a thing. I still remember the sound of my first modem connecting, and publishing my first HTML 1.0 website in high school. That feeling of "I can build something and put it out into the world" never really left me.
Cisco was the first wave: learning how the internet actually worked, helping customers build data centers (and yes, avoiding spanning tree loops along the way). Around 2016, big data hit, so I joined MapR to help customers turn data into insights. That pulled me naturally into AI/ML, where the really interesting applications were headed next. Cloud became the way all of this got built and shipped, which is what brought me to AWS, and now Amazon AGI Labs.
When I zoom out, every step followed the same instinct: a new technology wave shows up, and I want to be in the place where I can help developers actually use it. The arc from infrastructure to AI adoption looks dramatic on paper, but from the inside it's always been the same mission. Meet builders where the frontier is, and help them ship.
You've now ridden like four of those waves, networking, big data, cloud ML, generative AI. Each time, the gap between what the technology can do and what builders can actually ship with it is different. With generative AI specifically, where do you see that gap right now? What's keeping most builders stuck between cool demo and actually in production?
Chat was a forgiving medium. If the model said something wrong, the user shrugged and retyped. Now we're asking models to take actions in the world, book things, click things, write to real systems, and the tolerance for "close enough" drops to zero.
That's the gap I see most clearly right now. Teams prototype an agent that works beautifully on the happy path, but production means handling the 5% of runs where the page layout changed, the user hit cancel, or the model hallucinated a button. Shipping an agent is less about the model and more about everything you build around it: recovery, observability, guardrails, human handoff.
That 5% of runs problem is so real, and it's basically what my team works on every day with Nova Act. You mentioned recovery, observability, guardrails, human handoff. If you could wave a magic wand and give every builder ONE thing that would get them past that gap faster, what would it be?
The magic wand I'd wave is a shorter feedback loop between builder and user. Most teams I see spend three months polishing in private and then unveil it, which is almost the opposite of what works with AI products. The technology is moving too fast, and users surprise you too often, for long dark-room builds. The teams that make it to production tend to ship something rough, watch five real people use it, fix the things that broke, and repeat. That loop is the actual moat.
If I was talking to someone just starting their journey, I'd tell them the same thing: build in public, ship early, and get your work in front of users as fast as possible. That's been true at every stage of my career, from my first HTML site to the books to everything at AWS and AGI Labs. The people who grow fastest are the ones who are willing to put something imperfect into the world and learn out loud.
You literally wrote the book on GenAI on AWS, twice. 440K learners on the course. What does it actually take to write a technical book? The unglamorous reality of it. And how do you decide what to include when the technology is changing under your feet while you're writing?
Honestly? Writing a technical book is mostly saying no to your weekends for about a year. You write a chapter, throw out half of it, and rewrite it. You test every code sample three times, because if it doesn't run, the reader will find out before you do. Then you do that over and over. For me the hard part isn't actually the writing. It's the judgment calls. Deciding what matters, what to cut, how things connect, and then staying with those decisions without losing conviction.
That's why having co-authors matters so much. You keep each other honest. When one of us was drifting, the other would pull it back. That's really what you need: someone who'll push back on your thinking and challenge the structure.
On the frozen-in-time part, I actually don't think there's as much tension as it sounds like. A book isn't trying to compete with a blog post or a release note. You pick the layer that won't move. APIs change, SDK versions change, but the way you think about a system tends to hold up for years. The question I kept coming back to was: will this concept still matter in two years, even if the exact code doesn't? If yes, it earns a page. If not, it probably belongs in a blog post. My job as a writer is really just to figure out what's signal and what's noise, and cut the noise.
And the ship-early philosophy still applies. Every chapter was a draft. Every review cycle was a feedback loop. Every new edition was basically a v2.
You've built an audience across so many surfaces, books, courses, keynotes, LinkedIn, conferences. 440K learners trust you enough to spend hours learning from you. What do you think actually builds trust with a technical audience? And has your approach changed as you've moved from AWS to AGI Labs?
People assume trust comes from being technically right. I don't think it does. Being right is table stakes. If you're wrong, you're out. But being right isn't why people come back. What builds trust is usefulness. Did the reader walk away able to do something they couldn't do before? Did the thing I showed them actually work when they tried it at their desk on a Tuesday? That's the bar. Every time I publish something, I'm basically making a promise that if you spend an hour with this, you'll get an hour of value back. The audience forgives a lot, outdated screenshots, a typo here and there, an SDK that's already moved on, as long as the core promise holds.
What's changed, working on agentic AI now, is the size of that promise. At AWS, I was building on a proven foundation of two decades. I had to earn the audience's trust in me, but not in the tech underneath. Agentic AI is different. The category is new, the patterns are still forming, the technology is moving under everyone's feet. So the burden shifts. Every claim has to be demonstrable, every demo has to actually run, every rough edge has to be called out honestly. Lean on the work, not the logo.
If I had to boil it down to audience-building 101: be useful, be honest about what doesn't work, and show up consistently. That's it. The technology changes every few months. Those three don't.
You've kept this pace for years, books, courses, keynotes, a full-time product role, and now a new org. What have you learned about avoiding burnout? What does a break actually look like for you?
Balance is the wrong word. It implies some steady state I've never actually lived in. I think in seasons. There are seasons where I'm in heavy output mode, a book deadline, a product launch, a keynote tour, and I accept that weekends and evenings are going to be uneven. And there are seasons where I pull back and do much less. The mistake I made earlier in my career was trying to do both at the same time. You end up half-committed to everything and burnt out by all of it.
The other thing I've learned is that burnout isn't just about hours. It's about meaning. I've worked extremely hard on things that energized me and extremely hard on things that drained me, and the hours looked almost the same on paper. The difference was whether I cared about what I was working on. So the biggest thing I've done for my own longevity is being pickier about what I say yes to. I still work a lot, I'm not going to pretend otherwise, but I try to make sure the work is the kind that gives back.
For me, a real break is travel. Going somewhere new, getting out of my own bubble for a while, eating food I've never had before. Spending quality time with friends and family. Completely disconnecting, sometimes even from screens and WiFi. That's what actually recharges me.
And the pull to keep learning? I've stopped treating it as work. It's more like a hobby that happens to pay the rent. The day that changes is probably the day I need to do something else.
You've gone from writing for hundreds of thousands of learners to now shaping how a brand-new AI product gets adopted. How do you know you're actually getting better at this? What are your mile markers now?
The thing I've come back to over the years is that the storytelling only works if I've actually built the thing, or used the thing, or struggled with the thing. When I'm speaking from experience, the audience can tell. When I'm speaking from a deck someone handed me, they can tell that too. So my approach has gotten simpler, not more sophisticated. Build it myself first. Speak from what I actually went through. Be honest about the parts that didn't work.
If there's a mantra, it's just: be authentic. That sounds almost too simple to say out loud, but it's the thing that took me the longest to fully trust. Audiences are sharp. They forgive a lot, but they don't forgive a story that isn't yours.
Last one. You've ridden four technology waves, written two books, built courses for nearly half a million people, and now you're at the frontier again with AGI. If you could go back and tell early-career Antje, the one at Cisco in Dusseldorf figuring out spanning tree loops, one thing about how this all turns out, what would it be?
I'd tell her not to be afraid of taking risks earlier. Every big step in my career has come from leaving a comfort zone, not from staying in one. And the pattern is almost embarrassingly consistent: if a decision feels uncomfortable, it's usually the right one. That's where the growth is hiding. The safe move is almost always the one you regret later.
Oh, and I'd tell her to laugh the next time someone asks "where do you see yourself in 10 years?" Because none of it has turned out the way I envisioned it, and that's the best part. Cisco-Antje couldn't have predicted where she'd end up. The plan was never the point. Following my passion was.