Every AI coding tool is racing to solve memory. Longer context windows. Better recall. Smarter summaries of what happened three sessions ago. And that matters — an agent that forgets your database choice mid-conversation is genuinely broken.
But here's the thing nobody's talking about: an agent that remembers everything and then decides on its own to add audio generation to your app is also broken. Just in a way that's harder to catch.
Memory is not the same as restraint
The current generation of AI coding tools is very good at answering the question "what did we decide?" They track your architectural choices, your dependencies, your schema. They compress old conversations so nothing gets lost.
What they don't answer is a different question: "who gets to decide what happens next?"
That's the gap. Your agent knows the project inside out. It remembers every decision you've made. And then, because nothing told it where to stop, it makes a new decision you never asked for. It's not malfunctioning — it's being helpful within an unbounded scope. It saw a problem, it found a solution, it implemented it. You just didn't know until it was done.
What scope lock actually is
Throughliner works on a principle I call scope lock. The term is already in circulation — it's a natural name for the idea, and other people have reached for it too. What differs is where the boundary lives: elsewhere it's a prompt you write, and in Throughliner it's built into the workflow itself.
The idea is simple: before the agent works on anything, the scope of that work gets defined. Not "here's the whole project, go." Instead: here's the specific thing we're building right now, and everything outside it is off limits.
This means the agent can't wander. It can't decide your app needs a new feature. It can't pull in a library you've never heard of to solve a problem you didn't know you had. It works within the boundaries that were set, and when it's done, it stops and asks what's next.
That's it. That's the whole concept. And it turns out to be the difference between directing an AI and discovering what it did.
Why this matters more if you're not a programmer
A programmer can review a diff. They can look at what files changed, spot an unfamiliar import, and say "why did you touch that?" They have a mental model of their codebase that acts as a natural check on agent behaviour.
If you're not a programmer — if you're building with AI because you can't code — you don't have that. Your first signal that something went wrong is the app doing something weird, and by then the damage is baked across multiple files you can't read. You can't do code review because you don't read code.
Scope lock is the non-coder's substitute for code review. It doesn't require you to understand what the agent wrote. It prevents the agent from writing things you didn't ask for in the first place. I've written that case out at length in You can't review what you can't read.
The industry is starting to notice — but not for non-coders
To be fair, I'm not the only one thinking about this. Enterprise security teams are building runtime scope monitors. Developers are formalising prompt frameworks that set file-level boundaries. The idea that agents need restraint, not just recall, is gaining traction across the industry. I wrote about that landscape in a companion piece — who's solving for restraint, and who they're solving it for.
The short version: every other solution assumes you're technical enough to define the boundaries yourself. Throughliner is the one that builds them into the workflow so you don't have to.
If you're building with AI and you've ever looked at your app and thought "I didn't ask for that" — that's not a memory problem. That's a scope problem. And that's what Throughliner is for.