AI-native companies are eliminating expensive software abstractions by making work legible to agents
Nate B Jones of AI News & Strategy Daily argues that the real barrier to AI agent adoption is not memory or model capability, but the opacity of modern enterprise workflows.
Summary
Nate B Jones presents a solo strategic briefing arguing that most companies will fail to unlock AI agent leverage not because of model limitations, but because their work is trapped inside graphical user interfaces, opaque tools, and tribal knowledge that agents cannot reliably operate against. He uses a recent case study from Lee Robinson at Cursor — who migrated cursor.com away from a headless CMS back to raw code and markdown in three days over a weekend, using roughly $260 in tokens and hundreds of agent pull requests — as a signal of a broader strategic shift. The CMS had cost Cursor $56,000 since September, and its hidden state and permission complexity had become a wall between agents and the work itself. Jones argues that the deeper lesson is about "primitive fluency" — teaching non-technical people across an organization to understand the building blocks of artifact-based workflows so that agents can become operators rather than mere drafting assistants. He concludes that agent strategy is fundamentally a literacy decision, not a procurement one.
Key Takeaways
FULL TRANSCRIPT
The problem agents hit even after you solve for memory
Nate B Jones: In last week's executive briefing, I argued that most enterprise agents are sophisticated amnesiacs. The models are capable, but without domain memory, explicit goals, progress tracking, and operating procedures, multi-session work just turns into a lot of thrash and you don't get very far.
This week is the uncomfortable follow-on. Even if you solve for memory, most companies still won't get agent leverage because they haven't taught the organization to work in primitives. Not prompting, not tooling, but primitives — the shared building blocks that let humans and agents reliably ship work without heroics.
The real failure mode I want to talk about this week is that AI agents run into walls even with memory, because the work that you have is usually stuck in 20th century work patterns. Most agent deployments are going to stall at a similar place where the agent can write a plausible draft, the agent can summarize a meeting, the agent can generate options and propose plans — and it just can't get farther. The wall is your operating environment.
In most Fortune 500 companies and even most small-to-medium businesses, important work lives inside opaque workflows. Let me give you some examples. Maybe it's behind the click-pads in business software — behind an admin portal, behind a ticketing tool, behind a CMS screen, behind a dashboard. Maybe it's trapped in a hidden state somewhere — it's in draft mode, it's in an unpublished version, it's in permission rules that aren't visible until you hit them. Maybe it's encoded as tribal knowledge: "Ask Sarah." "Actually, finance owns that." "You know what, we don't touch that system."
An agent cannot reliably operate inside that environment. It cannot advise. It cannot draft. And most importantly, it cannot ship with you. So you can't accelerate. The company that buys agents is actually buying a conversation layered on top of those same bottlenecks.
The Cursor case study: Lee Robinson's CMS migration
Now I want to give you a case study around how you can unlock this and think differently. Lee Robinson is a longtime builder and writer. He was previously at Vercel. He now works at Cursor, teaching about AI. Cursor is obviously one of the breakout companies in AI-assisted coding. The product is an IDE designed around AI agents. If anybody is AI-native, you'd think it would be Cursor — and in this case, that's true.
Just a few days ago, Lee published an essay that reads like a weekend project, but we should treat it as more of a strategic signal. I think it's a fantastic case study in how we can make AI agents native in non-tech organizations. Lee was able to migrate cursor.com from a headless CMS — a content management system — right back to raw code and markdown.
Now, for decades we would have said that was regressing capability. We would have said we need marketers to have a CMS so they can reliably make changes. Well, Lee didn't think that was true anymore, and we'll get into why. He estimated it would take weeks and maybe an agency — and this is a guy at an AI-native organization. He himself was surprised, because he finished the job in three days over a weekend using about $260 in tokens and hundreds of agents. That is hundreds of agent pull requests and calls — around 300 and some before it was all done.
The headline is not "AI agents can code," nor is it "AI agents are fast." What I noticed is that they used to be able to ask the agent to modify the website directly, and then when they introduced a CMS in the middle — which was a change Cursor made as a way of trying to become a grown-up marketing organization — suddenly they were back to clicking through UI menus instead of just delegating work to agents.
What Lee realized is that there is a larger lesson here with AI and coding agents. The cost of an abstraction has never been higher.
What an abstraction costs you — and why that cost just changed
An abstraction is just a layer that hides the underlying work behind a simplified interface. We needed it for a long time because most organizations are mostly non-technical. A CMS is an abstraction — it hides the messy parts. It hides the files, the structure, the deployment, the version controls, and gives humans a nice friendly screen that says "edit page" and "publish." For decades, that's been a good trade.
And even AI-native organizations like Cursor think in those terms, which I guess should be encouraging to us — because if Cursor thinks that way, we can take some comfort in taking a minute to get AI-native here. But the thing you need to realize is the minute you want agents, all that stuff you hid becomes really expensive.
That was Lee's core insight: before they actually added in their CMS at Cursor, it was actually easier to update the site. You just tagged Cursor and you changed your marketing copy. That's as simple as you want it to be.
Agents don't thrive in clicky environments where state is scattered across different screens, different permissions, different draft modes, hidden dependencies, different roles. Agents thrive in environments where the underlying work is visible and editable. So the CMS stopped being a helpful tool as agents gained capability. Instead, it became a wall between the agent and the work.
That is why this story matters. It's not really about a website. It's not about CMS. It's not even about Cursor. It's about the new economics of complexity.
The hidden tax: what the abstraction was actually costing Cursor
Lee's essay is unusually valuable because he doesn't just say the CMS is bad. He actually lays out the hidden tax that we don't realize we're paying by using these abstractions. If you strip away the web dev details, the list looks like a kind of familiar executive pattern.
You have multiple identity systems — some people are in GitHub and in the CMS, and someone always needs to be added for permissions. There's operational drag. There's permissions risk. There's preview complexity — draft content requires special access paths and brittle preview logic. Sharing what you're about to ship becomes a friction point in and of itself. And more moving parts are required to keep everything fast and reliable. The site wants to be simple and stable and pre-built. The CMS introduces additional uptime dependencies and additional special modes, so there's a legitimate cost markup to this that the organization pays even if you're not thinking about the agent side.
Lee shares that Cursor spent $56,000 on CMS usage since September — a really hefty markup for the convenience of a graphical user interface. It also introduced hidden dependencies. When pieces of the site come from network fetches, or when humans can't easily answer "where does this piece of the site come from," Lee points out that that inability to completely and clearly explain what is going on with the site introduces additional costs in time and knowledge. Maintaining hidden state in our heads is really expensive.
So this is the actual state most of us face with graphical user interfaces. This is the size of the tax that we have been paying for non-technical people to use non-technical tools that are abstractions over a technical workflow.
What has changed is that it is now absolutely possible for non-technical people to drive technical agents directly against the workflow code itself. So why would you pay the tax on the abstraction anymore? Why not move back to the work surface that is legible to both humans and agents — raw code and markdown?
That's what Lee did. And that move collapsed all of the complexity of Cursor's website into a single inspectable place. If you're not technical, what you need to understand is that the work moved from state that was hidden inside of a tool to artifacts everybody — including agents — can see, review, and undo. And that's what really matters here.
Cursor's real advantage: technical as a default posture
Cursor's advantage isn't really AI agents. Everyone's going to make a big deal out of the fact that Lee used 300-some agent pull requests. That's not really it. It's that the whole company is technical by default.
When I ask myself what is stopping other companies from doing this, the thing I come up against over and over again is that Cursor is building a culture where technical is not a department — it's a default posture. Lee describes this explicitly when describing user management. He says designers are developers. This is absolutely the case at OpenAI as well, and it's absolutely the case at AI-native organizations that I have run into all over the world in the last year.
It can sound radical if you're in a traditional business, but at Cursor and other companies, it's really just normal. It does not mean that you don't have non-technical staff. It means that everybody is semi-technical. And when you talk to folks like designers — which I've done — who are also committing code, they're surprisingly open-minded about it. They say, "You know what, I don't worry a lot about exactly where my job family ends up. I'm interested in solving problems. I bring a design mindset to solving problems. I happen to have a toolset that allows me to iterate really quickly with code, which keeps me closer to the problem space, and I love that."
That is the kind of attitude that we need across the board in our organizations.
By the way, this is not just Lee's personal vibe or take. Colossus has actually written up a comprehensive profile on Cursor's go-to-market team and noted that they're surprisingly technical and they use Cursor itself for website updates, for dashboards, for internal tooling, and they ship that work directly. They do not route everything through engineering.
If you think about it, that mindset of getting as close to the code as you can and allowing the code to establish primitives that agents can build against — that is scalable, and that leads to surprisingly efficient thinking, because you're thinking in terms of the core artifacts that everybody can see and work against.
Internal debates at Cursor look like the kinds of debates we all dream about as leaders. People talk about whether something gets used, and if not, they proactively move to kill it. There's a culture of dogfooding and testing that keeps the defaults continuing to evolve as they try things. Cursor has a pre-ship ritual called a "fuzz" where everyone tries to break the release, and then fixes land fast because everyone has actually tried the new thing.
This is not startup chaos. This is not something that's impossible to copy at a larger scale. It's actually a very coherent operating model. It's just foreign to the way we've worked before, because 20th century defaults are stuck in the age of the graphical user interface.
"Code wins" as a strategic law for the whole business
This model emphasizes shared agency, a shared substrate of primitives, and shared responsibility. And that brings me to the deeper thesis that we've been circling around in this conversation.
The real thesis is that "code wins" is not about engineers. It's about how you extend legibility, investment, and leverage across your entire organization. When executives hear "code wins," it's often translated as an engineering slogan that means engineers win versus design versus product versus business, because they can actually put the product out there.
In the agentic era, it's different. It becomes more of a strategic law for how we operate our businesses. Work that can be expressed in code-like form gets a fast track to agents, because the entire industry is investing its best models, its best tools, its best safety investments and mechanisms, and every evaluation discipline they can find — all into the code pathway.
You can see this clearly in Anthropic's own engineering guidance on long-running agents. They describe the core long-running problem the same way. Agents work in discrete sessions and every new session begins with no memory — we talked about this last week. Their solution is not magical AI memory. It's a disciplined harness: an initializer agent, a coding agent, and clear artifacts for the next session.
The key thing to remember is that those artifacts are not just for agents. The world is being built where artifacts are already native — around code and repos and tests and logs and markdown files. So if a workflow resolves to artifacts plus validation and checks, it's likely that agents can participate in execution today. But if a workflow lives inside a tool's user interface state — a graphical, clicky-based software that humans have to operate and remember how to adjust, all dependent on human memory plus that GUI — agents at best remain advisers.
This is why software is winning first. It's not because engineers are better people or more deserving. It's because software is already built around the infrastructure of legibility — version history and diffs and tests and rollbacks and audit trails.
Fundamentally, when you are looking at composable workflows, those are the primitives you build around. That's what Lee saw. Lee saw you didn't need the graphical user interface. You could have all the muscle and power of the software just by tagging Cursor in the command line. Why would you need to do anything else if you actually decompose the workflow down?
Teaching your organization to think in primitives
I got to thinking: how do we as enterprise leaders start to teach our teams to think this way?
First, I think we need to really emphasize an understanding of primitives as places where work lives. A primitive is not complicated. It's just a small, stable building block that stays useful even when tools change. There are a couple of basic primitive stacks that I want to emphasize. You need a clear definition of done. You need a persistent record of state — or domain memory, as I talked about last week. You need a process for how work progresses and how it's validated. Without those three things, it's hard to make an agent reliable.
But beyond that, you also need to understand how work gets done across the organization. And most enterprises never define this explicitly. I think we're paying for that lack of definition. We've been paying for it through graphical user interfaces where humans use tribal knowledge to accomplish workflows by clicking things. That's no longer necessary.
So we need to start asking ourselves harder questions. What are the work primitives that drive operational change for us? For example: where's the thing that we change? That would be the system of record. How do we see that it changed? That's a readable before-and-after state. How do we approve it? That's a defined gate. How do we prove that it worked? That's a check. How do we undo it? That's a rollback. How do we know who did what and why? That's traceability.
All of those questions are questions business stakeholders ask all the time when vetting software. And really, they're coding questions. Lee's CMS story is really a story about work primitives being extended across a technically fluent company. He replaced a UI-state workflow with an artifact workflow, because artifact workflows have natural review, rollback, and traceability — and they just make sense when that's how agents are being built.
Anthropic's long-running harness is the same work-primitive story. They made progress reliable by insisting on artifact, state, and incremental steps, and they were fluent enough to build the business around that.
Domain memory is not just an agent technique. It's really one of several work primitives — it's the written state of the project. And so if your organization doesn't know how to write state down in canonical places, memory itself won't save you, because the work is still not legible.
The cultural pattern at AI-native companies
The cultural pattern we're seeing at Cursor, OpenAI, Anthropic, and other major studios is that non-technical people are learning the substrate of code — and they're learning it well enough that they can commit code. They're learning it well enough that they can be fluent in understanding how code drives workflows. And they're learning it well enough that they can operate against the code with the help of agents.
By the way, this does not mean they learn it well enough to authentically and correctly write JavaScript without help from an AI agent. I'm not saying they do. I'm not saying they ever will. I know lots of design engineers who cannot do that, but who nonetheless commit pull requests.
The reason Cursor can kill a CMS is not because they have a bias against graphical user interfaces — don't hear that. It's that their people understand that they can operate on one simple underlying workflow substrate of code and common primitives, and that's enough. They can do that with agents.
The reason I'm calling this out today is that I have a strong conviction that simple wins. If you are working in a world where you could have a more complex graphical user interface or a simpler substrate that gets closer to the code — especially given the pace of AI agent change — I would opt for the simpler solution. Simple is going to win when AI agents change fast. Simple is going to win when LLMs change fast.
If you can get to a block of stable, basic work primitives, if you can help your people understand that they need to have mental models of workflows and code and how code operates to get work done — through read-write on databases, through approvals, and so on — even if they can never write that code individually themselves, you are going to be in a position where you can ask them to operate agents. And that's going to give you a tremendous amount of freedom to delete abstraction layers from your business that are extremely expensive, like Cursor's CMS.
So "code wins" becomes an operating model for the business as a whole, and it allows us to extend the premise that simplicity is what wins in the age of AI.
What this means for enterprise training and security policy
The organization needs to train more people to think and act in artifact-based workflows, because that's where agents are strongest and that's where they're safest. And this is the piece that most enterprise leaders are not really ready to hear.
If you keep your workforce in the 20th century — if you keep them graphical-user-interface-native because your security department or your IT department tells you this is what we should do because it's safe, and only the engineers should commit code — your agents are going to be stuck as drafting assistants. You're not going to unlock the kind of velocity that you see and want from these AI-native companies.
Whereas if you teach your workforce to be artifact-native, your agents can then become operators and collaborators with your teams. And this has profound implications for training. It has profound implications for our security policies.
If the strategic claim is that code-like work wins because it's agentable, then the logical conclusion is that enterprise AI training must transform into something like code-concept training for non-engineers. Not "learn Python," not "become an engineer" — but learn the concepts that make work legible to agents. Because the goal is not to turn everybody into programmers. The goal is to turn more of the company into people who can express work in a form that agents can safely act against.
So things like: state — what is the current status of your work, and where is that written down? The artifact — what is your system of record? What is the real thing we ship and maintain? Is it a document, a dataset, a configuration, a product catalog, a policy? If the truth lives in a hidden state in the UI, your agent can't reliably operate.
Another example: what's a change record? Can we see what changed without an argument? Software has diffs. Enterprises need the equivalent. Checks — who proves this is correct? "It looks good" is not a check. A check is something objective: a test, a reconciliation, a policy rule, a validation script. Rollbacks — how do we undo what we've done? Agents increase throughput. Rollback is how you keep that throughput from becoming a risk. Traceability — who changed what, when, and why? When your AI workforce grows, this stops being a compliance nicety. It becomes existential as you get lots and lots of agents.
If you can teach these kinds of ideas broadly, you create the precondition for real agent adoption, because your organization stops treating tools themselves as sacred — "I'm a Salesforce guy" — because everyone understands what must stay true underneath. It's not Salesforce that's the thing. It is the workflow that's the thing.
And that's why Cursor can ask "do we really need a CMS?" and actually execute the deletion. They weren't being reckless. They understood what it would replace. They understood they could replace it with a simpler substrate with a stronger core primitive set that both agents and humans could operate against.
The competitive advantage of primitive fluency
So if you're a Fortune 500 exec or a small business leader, the mistake would be to interpret this as "let's copy Cursor and put marketing into GitHub." I don't mean do that exactly. That is not the point.
The point is that there is an underlying competitive advantage in the age of AI. Primitive fluency diffuses power. When teams share a mental model of state, artifacts, checks, rollback, and traceability, the company gains a new superpower — because people can see that a standard tool is just a convenience layer with a measurable tax. People can propose a simplification without triggering fear, because they can articulate what stays safe and everyone's technically fluent enough to follow. Work can be recomposed into forms agents can operate against instead of being trapped in process.
That is what moving fast looks like in a mature agentic organization. It's not speed for its own sake. It's just simpler, less hidden state, fewer brittle handoffs, and more of the company able to safely ship changes.
Last week, I called out that agents fail because they don't remember — and you can fix that with domain memory, but it's not enough. This week, I want to remind you that organizations fail because they don't write work down in agent-legible forms. You fix that by teaching primitive fluency — which is really code-concept fluency — across your entire organization.
Agent strategy is not really a procurement decision. It's a literacy decision. The winners won't be the companies that have agents. They'll be the companies where enough people understand the primitives that they can delete sacred workflows, notice where those workflows are incorrect, move work into more legible artifacts for agents, and unlock agents actually operating. And that's what unlocks 10x speed.