Here's what I was trying to do.

I built a tiny HTML page — a personal launcher with clickable tiles for every tool, admin console, and URL I use during a working day. Thirty-eight tiles, one page, deployed to my own domain. I wanted it gated to one email address — mine — so that if anyone stumbled on the URL, they couldn't get in.

That's it. One page, one gate, one email.

Forty-five minutes. Four different identity systems. At one point I had five tabs open across three companies and I still couldn't tell the assistant helping me what my "team name" was, because nobody had agreed on what a team name is.

I did get it gated. The launcher is live, the gate works, I'm happy with it. But somewhere in the middle of the exercise, something clicked that I've been failing to name in writing for months. It wasn't that the tools were bad. Each one, individually, was reasonable. It's that they all assume you are the integration layer — that you'll carry their separate mental models in your head and translate between them by force of will.

Let me show you what I mean.


The four models I had to hold simultaneously

Model one: Cloudflare. I had to know my Cloudflare account, which zones I own, which Pages project hosts the page, which path prefix I want gated, and what Cloudflare means by "application" versus "destination" versus "policy." Cloudflare has its own vocabulary — these words don't mean what they'd mean elsewhere. An "application" in Cloudflare Access isn't the thing I built. It's a policy object that sits in front of the thing I built.

Model two: Cloudflare Zero Trust. Not the same as Cloudflare. It's a separate dashboard, at a separate subdomain, with a separate hierarchy of concepts — team, identity providers, policies, applications again but with different meanings. Zero Trust also wanted me to pick a "team name" that I had never created before this moment, that lives in a global namespace where my first two choices were already taken, and that becomes part of a URL I'll see in every login flow forever.

Model three: Google Cloud Console. To use Google as an identity provider I'd need to create an OAuth application, configure a consent screen, pick scopes, add my own email as a test user, paste a callback URL generated by Cloudflare into a field owned by Google, then copy two secret strings back the other direction. None of these concepts exist in Cloudflare. None of them exist on my launcher page. They only exist because Google and Cloudflare have to agree on who I am, and agreement happens to require a roundtrip through Google's developer-tools UI.

Model four: Google Workspace. The email I typed during testing went to an address I own at a domain I control, hosted on Google Workspace — which is not the same as regular Google, nor the same as Google Cloud Console, and has its own dashboard, its own billing relationship, and its own notion of which inbox a message actually lands in when routing rules fire. When the test code didn't arrive where I expected, I had to reason about MX records, forwarding rules, catch-alls, and alias resolution. Not about the gate. Not about the launcher. About whether Google's internal routing had delivered a six-digit code to the inbox I was looking at.

Four models. For one URL.

None of them are individually wrong. Cloudflare's model is internally consistent; so is Google's; so is Zero Trust's; so is Workspace's. Each one is a well-designed product with coherent documentation. The problem is that they don't know about each other, and because they don't, I have to be the integration layer between them.


"You are the integration layer" is not a business model

Every software-as-a-service company implicitly sells you this promise: our tool will save you time. And individually, each tool does. Cloudflare saves me from running my own HTTP gate. Google OAuth saves me from building a password database. Google Workspace saves me from running my own mail server.

But nobody sells "these four tools in combination" — because nobody has to. The tools are sold one at a time. The integration between them is sold implicitly to you, the user, at the price of your cognitive attention. You're expected to know what a callback URL is, why a team domain matters, how cookies interact with policy evaluation, what happens when a session cookie is valid but the identity provider hasn't been assigned to the application.

You're expected to know all this not because you want to, but because there's nobody else to know it on your behalf.

For a while, documentation was the compensating layer. Tutorials, integration guides, StackOverflow answers, random blog posts from someone who got it working in 2018 and wrote up the steps. That model works until the integration surface gets too wide. The problem I hit today wasn't one Google-Cloudflare pattern; it was four systems and their interactions, configured through three different UIs that have each changed their wording since the most recent guide was written.

At some point you're not following documentation — you're doing original research every time you want to connect anything new.


The Third Layer

I've been calling this the Third Layer for a few months now. The first layer is the infrastructure — Cloudflare, Google, AWS, the raw services. The second layer is the app or product you build on top of it — kurkalabs.dev, my launcher page, anything a customer ultimately touches. Most of us have been taught there are only two layers, and the job of being a builder is to work out the relationship between them.

But there's a missing layer in between. The layer where the infrastructure tools would know about each other, where "I want to gate this page to this email" would be a single intent expressed once and executed across all four systems without forty-five minutes of my attention. The layer that, if it existed, would have turned today's task into: here, deploy this page, gate it to me, done, go have lunch.

That layer doesn't exist today. Not because it's technically hard — it isn't — but because no single vendor owns it, and no single vendor is incentivized to build it. The tools stay isolated because isolation is what each vendor optimizes for. You pay the cognitive tax because you're the only common denominator.

The Third Layer, as I'm coming to think of it, is the user's representative. An agent that holds your intent, across your tools, and does the translation work that used to be documentation and tutorials and sheer willpower. Not a new tool next to the existing tools. An integration substrate on top of them.

The launcher I built today isn't the Third Layer — it's just a clickable HTML page, one layer deep. But the act of building it, the forty-five minutes of fighting four separate identity models, showed me the shape of the thing that should have been there and wasn't.


What it felt like when the page was done

I opened the launcher for the first time after the gate was working. Thirty-eight tiles. Platforms I log into weekly. Admin consoles I'd been copy-pasting URLs for. Drive folders I couldn't find via the UI. Substack. LinkedIn. X. GitHub. Cloudflare. Google Drive. Stripe. Resend. And a dozen project-specific things.

I hadn't realized how much I was carrying in my head until I saw it all in one place.

That feeling — oh, I was doing a lot more mental work than I thought — is the quiet symptom of the missing layer. You don't notice the load until the tool that could hold it for you finally appears. And when it does, what surprises you isn't that the tool is clever; it's that you'd been doing the clever part yourself, every day, without anyone ever naming the job.

That's the job I think AI is about to do for a lot of us. Not replace the tools. Not unify the tools into a single mega-tool. Just hold our intent across the tools we already use, and carry the translation burden that we've been carrying alone.

The Third Layer isn't a product category yet. It's the shape of an unmet need — the one you feel in your bones the moment you realize you just spent forty-five minutes wiring one HTML page to one email address.

If you've ever asked yourself at the end of a long day "what did I actually accomplish?" and the honest answer was I integrated four vendors who don't know each other exist, you already know what I'm talking about.


Frank Kurka is the creator of TQL (The Question Layer), MemoryOS, and the Glass Bead Game development paradigm. He is the author of What is Artificial Intelligence, has been building software for 45+ years, and writes weekly at fkxx.substack.com.