Skip to main content

The Man Who Invented the Transformer Is Now at OpenAI Designing What Comes Next

An architect sketching a new circuit diagram over an older schematic on a lightbox

Noam Shazeer co-authored "Attention Is All You Need" in 2017. That paper introduced the Transformer architecture, which sits underneath every major AI model running today: GPT, Gemini, Claude, all of them. He then co-founded Character.AI, Google paid around $2.7 billion to bring him back as VP of Engineering and co-lead on Gemini in August 2024, and two years later he walked out the door to join OpenAI.

His title at OpenAI: Lead for Architecture Research. His mandate: design next-generation architectures beyond the current GPT line.

That's not a talent story. That's a directional signal.

What Actually Happened

On June 18, 2026, Shazeer announced he was leaving Google for OpenAI. Google had spent $2.7 billion to retain him (as part of a partnership deal that brought back his Character.AI co-founder Daniel De Freitas alongside him) less than two years prior. They paid that to keep him. He left anyway.

The same week, Google also lost a prominent researcher to Anthropic. Two of the most cited AI architects leaving for competitors in three days is not coincidence.

Why This Title Matters More Than the Move

"Lead for Architecture Research" is deliberate and specific. Shazeer is not going to OpenAI to fine-tune prompts or ship product features. He's going there to rethink the underlying structure of how large models are built.

The Transformer has proven remarkably durable. It scales. Throw more compute and data at it and performance keeps improving. But if you work with these systems day to day, you hit structural limits pretty quickly.

The most visible one: attention is O(n squared) in sequence length. At 128k or 200k tokens, you're burning significant compute just on the attention step itself. Efficient attention variants like Flash Attention help, but they're patches on the underlying design, not a rethink of it.

There's also a subtler issue. You can give a model a million-token context window, but how it actually uses that context is constrained by the architecture. Information flows through a fixed-width residual stream at each layer. The model has to compress what it's seen into a finite representation. Shazeer has spent years watching where exactly that wall appears in Gemini.

The mixture-of-experts work he's closely associated with, including the Switch Transformer and elements of Gemini's architecture, is itself already a departure from vanilla dense transformers. MoE activates only a fraction of parameters per token. Efficient, but also a signal that "one big dense transformer" is not the end state.

What a New Architecture Would Mean for Builders

A wall socket with two contrasting interiors showing old complex wiring versus a clean new circuit

The API interface won't change. Whether a model runs on a transformer, a state space model, a hybrid architecture, or something that hasn't been published yet, you'll still send a list of messages and get tokens back. The contract at the API boundary is stable.

What changes is the capability profile underneath it.

If a new architecture handles long contexts more efficiently, the tradeoffs you currently accept get renegotiated. The aggressive chunking, the summarization pipelines, the retrieval-before-inference steps you've built to work around context limits: some of that might stop being necessary. Or the model's ability to actually reason over a long document (not just attend to it) improves enough to change what you build.

The agentic case is where this matters most. Multi-step tasks where the model needs to track state across many steps are where transformer limits are most visible today. A better architectural fit for that pattern would change the economics of building agents substantially. I haven't run this at scale with non-transformer architectures, but the theoretical argument is solid.

The practical implication: don't hard-code assumptions about context window tradeoffs or attention costs into your architecture. Keep those as configuration. The model behind your API call will look different in 18 months.

What Google's Loss Tells You

Google spent $2.7 billion to retain Shazeer. He stayed two years, worked on one of the most capable model families in the world, and then chose a competitor. That tells you something, even if you can't know exactly what.

One reading: OpenAI offered the freedom to do fundamental research without the constraints of a product line that ships quarterly. Another reading: he believes the next foundational bet in AI will be made at OpenAI. Both of those readings matter for how you think about which lab to watch most closely over the next few years.

The institutional knowledge Shazeer carries about what works at scale, where efficiency gains are most likely to come from, what Google tried that didn't pan out: none of that is in any published paper. OpenAI now has it. That's the part that's hard to undo.

Comments

Popular posts from this blog

AngularJs call one method of controller in another controller .

I have seen many question about calling one method of one controller in another controller or extending scope of one controller in another controller.so here are the ways. if you want to call one controller into another or extending scope of controllers there are four methods available $rootScope.$emit() and $rootScope.$broadcast() If Second controller is child ,you can use Parent child communication . Use Services Kind of hack - with the help of angular.element() 1. $rootScope.$emit() and $rootScope.$broadcast() Controller and its scope can get destroyed, but the $rootScope remains across the application, that's why we are taking $rootScope because $rootScope is parent of all scopes . If you are performing communication from parent to child and even child wants to communicate with its siblings, you can use $broadcast If you are performing communication from child to parent ,no siblings invovled then you can use $rootScope.$emit HTML <body ng-app = ...

Closures in javascript and how do they work ?

JavaScript Closures for Dummies  Closures Are Not Magic This page explains closures so that a programmer can understand them — using working JavaScript code. It is not for gurus or functional programmers. Closures are  not hard  to understand once the core concept is grokked. However, they are impossible to understand by reading any academic papers or academically oriented information about them! This article is intended for programmers with some programming experience in a mainstream language, and who can read the following JavaScript function: function sayHello ( name ) { var text = 'Hello ' + name ; var sayAlert = function () { alert ( text ); } sayAlert (); } An Example of a Closure Two one sentence summaries: a closure is the local variables for a function — kept alive  after  the function has returned, or a closure is a stack-frame which is  not deallocated  when the function returns (as if a 'stack-fr...

250,000 AI Agent Instances Exposed on the Internet — Is Yours One of Them?

If You're Running OpenClaw, You May Want to Read This A public watchboard has surfaced listing over 250,000 OpenClaw instances that are directly reachable from the internet. Some of these instances have leaked credentials. Many are running on infrastructure already flagged for known CVEs and threat actor activity. This isn't theoretical. It's happening right now. You can check the exposure list yourself at openclaw.allegro.earth . Why This Is a Big Deal OpenClaw is a powerful AI agent framework. That power comes with serious responsibility. A typical OpenClaw deployment runs with: Personal API keys — OpenAI, Anthropic, Google, cloud provider credentials Broad system permissions — file access, shell execution, network requests Autonomous execution capabilities — the agent can act without human approval Complex codebases — large attack surfaces that haven't been fully audited When one of these instances is publicly reachable without authentication...