What did not get cheaper is knowing whether any of it works. That gap is the reason CreateOS exists, and I want to lay the thesis out properly for once. I have a good excuse this week: Foundation Capital just published Rebuilding software for AI agents, and the first opportunity it maps, execution environments, is the layer CreateOS is built for. Everything below is about that one layer. Their conclusion by analysis, ours by scar tissue.

Why is verification the bottleneck for AI agents, not code generation?

Because generation became nearly free, and the bottleneck always moves to whatever stayed scarce. What stayed scarce is proof that the work is correct.

Every team that adopts coding agents makes the same plan: we will review the output the way we review each other. That plan dies in the first week. Humans review at human speed, agents produce at agent speed, and the queue does not shrink on weekends.

At that point you have three options:

- rubber-stamp the output and hope

- throttle the agent and lose the speed you paid for

- build a machine that does the checking

We picked the third, and it shaped everything about the product.

Here is what the checking already costs, from our own Slack.
On August 23 one of our devs posted the bill for asking AI to review two pull requests on one of our products, #431 and #459: $130.16. Not to write the code. To review it.

What does an execution layer for AI agents actually do?

It puts the validation check inside the path to production, so nothing an agent writes can ship without passing it.

Every request an agent makes through CreateOS is routed, governed, validated, and audited, in that order. The order matters. Validation is not a dashboard someone might look at later. It is a gate the change has to clear.

Agents do not click through screens built for me. They discover and drive the platform directly over MCP, and the gate sits between them and production. I wrote up the fuller definition in What is a unified execution environment if you want the long version.

Foundation Capital’s essay states the strategic consequence better than I ever have. When agents write most of the code, every change has to pass a validation check before it ships, “and the product performing that check becomes the gatekeeper to production.” Models are commoditizing each other at a ferocious pace. The gate is the one thing every change passes through, no matter which model wrote it. That is where leverage settles.

What did we learn running an execution layer in production?

Three things, and none of them were in the original design doc

Environments have to be disposable, or agents ruin them. A shared staging server cannot coexist with a workflow that forks fifty experiments before lunch. Environments on CreateOS start in seconds from a known state and are destroyed without ceremony. Nothing left running, nothing for the next run to trip over.

A prompt is a wish. A boundary is a fact. Early on we watched agents route around soft constraints the way water routes around a rock. Not malicious, just thorough.

Telling an agent in its prompt not to spend more than fifty dollars is hope. A metered budget that stops the run at fifty dollars is architecture. Every constraint that matters on our platform binds in the runtime: data access, tool scope, spend. That is the argument of Why cloud agents need a governed runtime, written well before this week gave it a co-signer.

The trace is the product. When an agent’s change fails in a normal setup, you get an outcome and a shrug. When every run carries its full record from instruction to outcome, a failure is something you replay, not something you theorize about. Enterprises will forgive an agent for being wrong. They will not forgive being unable to find out why; we broke down what that record has to prove in AI agent audit trails.

Foundation Capital’s essay lists four requirements for agent infrastructure, and they map almost exactly onto the three lessons above:

- agent identity with delegated authority

- capability constraints “enforced by infrastructure, not prompts”

- full traceability from instruction to outcome

- cost metering as a hard limit, not a dashboard

That list is near enough our architecture diagram that reading it felt like being audited, pleasantly. When the operator’s scars and the investor’s analysis agree, the conclusion is probably load-bearing.

Which software gets rebuilt for agents, and which just gets an API?

This framework comes straight from the Foundation Capital piece, and it is the most reusable tool in it. Databases sit low on the first axis. They were always machine-facing, so they mostly need to absorb more traffic. A five-screen approval workflow sits high on both axes, and things high on both do not get an API bolted on. They get replaced.

Execution sits in the top-right corner. That is where we live.

And not since last quarter. We started working on this infrastructure three years ago and heavily doubled down on reliability, performance, and scalability for any apps and agents getting deployed on cloud. With this transition towards agents writing almost a hundred percent of the code, all of these factors play a very critical role in actually running this software in production.

Where does the execution layer category go next?

It gets crowded, and the full spec stays ahead of everyone shipping today. Both of those are fine.

I will say the uncomfortable part out loud. A fund publishing this essay tells every founder it meets that the category is fundable, so more competition is coming. Categories get big when smart money says their name in public, and I would rather compete in a named category than keep explaining an unnamed one.

Their complete spec, branchable full-stack environments plus simulated third-party services plus deterministic replay, is more than anyone ships today, us included. We read it as a roadmap. We are further along it than anyone gets credit for being.

The essay closes with a line I would frame: “The last platform shift rewarded whoever made software easiest for humans to use. This one will reward whoever makes work possible for agents to do.” Read the whole thing; it earns the fifteen minutes. Joanne Chen’s short summary of the founder opportunities in it is the best entry point if you only have five.

CreateOS is the execution layer this essay is about. Agents ship through governed, validated, audited runs at CreateOS. If your agents write faster than you can verify, that is exactly the problem we sell the answer to.

Follow me on X | LinkedIn | naman.wiki

We don’t usually break from our weekly cadence, but some news is worth its own post. This is one of those.

CreateOS just ranked #1 on the ComputeSDK Sandbox Benchmarks - out of 27 providers.

Not by our own measurement. On an independent, public leaderboard that anyone can verify, run on identical hardware (4 vCPU / 16GB RAM, Northern Virginia, US).

Try CreateOS Sandbox

The numbers 📊

Here’s what “time to interactive” looks like on CreateOS sandboxes:

• Median TTI: 0.34s

• P95 TTI: 0.38s

• P99 TTI: 0.38s

Composite score: 96.5, ahead of every other provider on the board.

But here’s the part we’re most proud of: look at the gap between the median and the P99. There barely is one.

Anyone can post a fast median. Almost nobody can post a P99 that close to it. That 0.04s spread means your sandbox spins up just as fast on the worst day as it does on the best one: no cold-start lottery, no tail latency surprises. Consistency at that level doesn’t happen by accident. It took a lot of blood, sweat, and sleepless nights from the team to get here.

Speed is the floor, not the pitch 🚀

Being the fastest sandbox is table stakes for us. What you build on top of that speed is where CreateOS really pulls away:

• P2P mesh networking: connect your sandboxes directly, no middleman.

• Built-in VPN: secure access out of the box.

• BYO-S3 disk: bring your own storage, keep your data where you want it.

• Auto pause/resume: pay for what you use, pick up exactly where you left off.

…and 10+ more features designed so you never have to trade capability for speed.

See it for yourself 👀

Benchmarks are public and reproducible: check the leaderboard, inspect the methodology on GitHub, and then put us to the test with your own workload. The fastest way to believe a 0.34s median is to feel it.

ComputeSDK Benchmarks

Thank you for building with us. This #1 spot belongs to every creator who pushed us to be faster, and we’re just getting started.

Sid

Two updates this week; one we’re proud of, and one where we could use your help. Let’s get into it.

CreateOS ranks #2 on Sandbox Benchmarks 🥈

CreateOS now sits at #2 on the Sandbox Benchmarks leaderboard, as published by @computesdk on July 24, 2026.

Why does sandbox startup speed matter? Because when you’re running AI agents at scale, cold-start latency compounds. Every millisecond of spin-up time gets multiplied across thousands of invocations in an isolated execution layer. What looks like a small delay on a single run becomes minutes, even hours, of wasted compute across a real agent workload.

• Faster cold starts - sandboxes spin up in a fraction of the time, so your agents get to work sooner.

• Compounding gains - savings multiply across every invocation, not just the first one.

• Isolated by design - speed without compromising the security of the execution layer.

• Benchmarked, not claimed - independently measured and ranked against the best in the space.

Visit ComputeSDK

We’re live on Product Hunt 🐱

We also launched CreateOS on Product Hunt this week. We’d rather earn your upvote than ask for it.

So here’s our request, in order:

1. Try CreateOS Sandbox: Spin up a sandbox, deploy an agent, kick the tires.

2. If it’s genuinely useful to you, head over to our Product Hunt page and leave an upvote.

3. Even better - drop a comment with your honest feedback. What worked, what didn’t, what you’d love to see next. That’s what actually helps us build a better product.

Visit Product Hunt Launch

That’s all for this week. See you in the next one!

Sid

A big one this week, two of them, in fact. We’re introducing UNO, a brand-new AI agent, and rolling out CreateOS V2, a ground-up refresh of how you build, manage, and ship. Let’s get into it.

Meet UNO — one agent, a whole team of specialists 🧠

UNO isn’t a single assistant. It’s a team of specialists behind one chat. Ask in plain language, and UNO routes your request to the right expert, or several of them, and hands back a single, clean answer.

• Auto-routing — requests go to the best-fit specialist automatically.

• Builds and runs code — writes, executes, and returns downloadable files.

• Real documents — generates actual PDF, DOCX, XLSX, PPTX, and chart files.

• Works inside your apps — connects Gmail, Calendar, and Notion to act in your own accounts.

• Confirm before acting — shows what it’s about to do and waits for your approval.

Deploy your UNO Agent

CreateOS V2 is here ✨

We’ve rebuilt the CreateOS experience from the ground up, new look, and a workflow that finally keeps everything in one place.

• A fresh new look — a cleaner, redesigned interface across the board.

• One project, everything together — manage your vibe-coding sessions and deployments under a single project, no more hunting across screens.

• Bring your own GitHub repos — import a repo, start working on it right away, and ship it through our deploy flow.

• Third-party connectors — plug in auth, payments, productivity tools, and more to wire up your app without the boilerplate.

• Sandbox (new) — a dedicated space to spin things up and experiment before you take them live.

Try CreateOS - New Version

That’s it folks, see you next week!
Sid

Last quarter I sat in two conversations about a week apart, with two companies in roughly the same industry, at roughly the same size. The first one walked me through their AI agent with real pride. One agent, live, doing something genuinely useful in their support workflow. They had fought hard to get it there, and they had earned the pride. I told them so, and I meant it.

The second company, same week, mentioned almost in passing that they were running twelve. Not pilots. Twelve agents in production, across different functions, and they were mid-conversation about the next handful. They did not say it to impress me. They said it the way you mention how many laptops your team has. It was just infrastructure to them now.

I have not been able to stop thinking about those two conversations, because the first company does not yet understand that they are not one agent behind the second. They are a year behind, and the distance is growing while they sleep. That is what this issue is about, and if you read issue 1 about why most pilots die, this is the uncomfortable thing that happens to the ones that live.

The number that should worry boards

The analysts have now put a shape on what I was seeing in those two rooms. HFS Research studied this and found that the enterprises leading on AI agents, the ones they call Orchestrators, already run an average of about twelve agents in production, with some pushing twenty. The rest of the market is sitting at zero or one, mostly still in pilot.

Read that again, because the framing matters. The leaders are not slightly ahead. They have crossed into a different mode of operating. While most companies are still debating which model to standardize on, the leaders settled that question a year ago and moved on to the part that actually decides the outcome.

The wall at the sixth agent

Here is the part the proud-of-one company is about to discover, and it is the most counterintuitive thing I have learned in this space.

Going from one agent to two is easy. Two to five, harder but manageable. Then somewhere around the sixth agent, something breaks that has nothing to do with any individual agent’s quality. They start stepping on each other. One agent takes an action that quietly invalidates an assumption another agent is relying on. Behavior emerges that nobody designed and nobody can trace. A small failure in one workflow cascades into three others. And the audit gaps multiply faster than any human can keep up with.

I have watched teams hit this wall and misdiagnose it completely. They think agent number six is buggy. They debug it for weeks. But the agent is fine. What broke is that they were running six independent agents with no shared system underneath them, no common view of the data, no enforced boundaries between what each one is allowed to do, no single trail recording all of it. Five disconnected agents is a manageable mess. Twelve is chaos, unless there is an operating layer holding them together.

The companies running twelve did not get lucky or hire better prompt engineers. They built, or adopted, the layer that lets a fleet run without colliding. That is the whole difference. The analysts even have a name for it now, the same name we use: the agent operating system.

Why it is a clock and not just a gap

A gap you can close at your own pace. A clock you cannot.

The reason this is a clock is that the lead compounds. Every agent the second company puts into production teaches their operating layer something. A constraint gets tightened. An audit gap gets closed. A pattern gets reused on the next agent so it ships faster than the last. Their twelfth agent took a fraction of the effort their first one did, because the hard infrastructure work was already done.

So when the first company finally decides to get serious and go from one agent to twelve, they are not starting twelve steps behind. They are starting behind a system that has been compounding for a year, getting faster and safer with every deployment. The analyst read on the window is blunt: somewhere around twelve months for most enterprises, after which catching up stops being a budget decision and starts being a structural disadvantage. I think that read is right, and I think most boards have not priced it in at all.

What I would tell the company with one agent

I did not say all of this in the room, because nobody wants to hear “your proudest achievement is actually a warning sign” in a first conversation. But here is what I would say now, to them and to anyone sitting at one agent feeling good about it.

Be proud of the one. Getting even one agent into real production is harder than the demos make it look, and you did it. But do not mistake it for a finish line. The question that matters is not “do we have an agent in production.” It is “what happens when we try to run the sixth one next to the first five, and who owns the trail when all of them are acting across our systems at once.” If you cannot answer that, you are not behind on agents. You are behind on the system that lets agents become a fleet. And that is the thing with the clock on it.

One ask, same as last time

If you are inside a company doing this right now, hit reply and tell me the real number. Not how many agents you have built or demoed. How many are actually in production, governed, today. I am collecting these, honestly, because the gap between the number people say and the number that is real is its own story, and it might be the next issue.

Next issue is the one I have been building toward since issue 1: the last mile itself. How a single agent actually gets across the line from “works in the demo” to “live and governed,” told through the rescues I have watched up close. It is the most hopeful issue of the three, because it is the part you can actually do something about starting Monday.

If this was useful, subscribe so the last issue lands in your inbox. See you there.

Naman

Source:
HFS Research, HFS Horizons: Agentic Technology, 2026.
Product-voice version on the blog: createos.sh/blogs/enterprise-velocity-gap

We’ve built something new and we’re not launching it publicly yet. Before we do, we want a small group of developers to run real workloads on it and tell us your experience.

Run untrusted AI code without holding your breath 🔒

It’s called CreateOS Sandbox: it runs untrusted, AI-generated code in isolated micro-VMs.

• Real isolation — each sandbox is a Firecracker micro-VM with its own kernel, not a shared-kernel container.

• Private networking — sandboxes can talk to each other over a private network.

• Locked-down egress — outbound traffic is controlled at the kernel with eBPF.

• Bring your own storage, and boot in seconds.

What we’d love from you:

• Run something real — an agent loop, a code interpreter, CI for untrusted PRs.

• Tell us what felt slow, confusing, or missing.

• Push on the security model. If the isolation or egress control doesn’t match your threat model, we want to hear why.

Try CreateOS Sandbox

That’s it folks, see you next week!
Sid

One update this week, and it’s one a lot of you in India have been asking for. Paying for CreateOS just got a whole lot easier. Let’s get into it.

Pay in INR with Razorpay 🇮🇳

You can now top up credits and manage your subscription in rupees, paid straight through UPI with Razorpay. No currency conversion, no card-only checkout, no friction. Just open your UPI app, approve, and you’re back to building.

• UPI, the way you already pay — settle up in INR through Razorpay to top-up credits or start a subscription.

• Start from just ₹100 — no big upfront commitment. Begin small, see what fits, scale when you’re ready.

• Cancel anytime — your subscription, your call. Turn it off whenever you like, no hoops.

• One smooth checkout — local payments, instantly reflected in your credit balance.

Subscribe Now

That’s all folks, see you all next week!
Sid

The first time I watched an enterprise AI pilot die, I assumed it was a fluke. A good team, a capable model, a demo that made the room lean forward, and then six weeks later it was quietly shelved. Bad luck, I thought. Wrong use case. Move on.

Then I watched it happen again. Different company, different industry, different model. Same death. And then a third time, and a fourth, until the pattern stopped looking like bad luck and started looking like a law. The pilots were not dying because the AI could not think. They were dying because the AI could not do anything. That realization is why I am writing this newsletter, and it is what the whole first issue is about.

This is The Last Mile Notebook. It is the place I am going to write down what I actually see while trying to get AI agents from a slick demo to something running inside a real business, governed, at scale. Not predictions. Not think-pieces about where AI is going in five years. Field notes from the part everyone skips: the last mile between “it works in the sandbox” and “it is in production and legal is fine with it.” If that is the part of the job you live in, I think you will want to be here.

The number that stopped sounding like a stat

You have probably seen the MIT figure by now. Project NANDA’s State of AI in Business 2025 looked at 300 deployments and found that about 95% of enterprise generative AI pilots deliver no measurable impact on the business. Only around 5% break through.

When that report landed, most people read it as a verdict on the models. The AI was not smart enough. We need better foundation models, better fine-tunes, better prompts. I read it differently, because by then I had already watched enough of these die in person to know where the body always was.

It was never in the reasoning. The reasoning was usually fine. The demo was real. The body was always in the same three places.

The same three walls, every time

Here is the sequence I have now watched more times than I can count.

A team builds an agent. In the sandbox it is genuinely good. Then they try to wire it into the actual company, and they hit the first wall: the data the agent needs is scattered across systems that were never built to share it The CRM here, the ERP there, the warehouse somewhere else, all with access controls designed for human employees with badges, not for an autonomous process. So someone does the only thing they can. They hand the agent a credential and quietly hope.

Then the second wall: the agent can think but it cannot safely act. Reading data is one thing. Writing back, triggering a workflow, moving money, updating a record, that is the thing the business actually needs, and there is no governed mechanism for an autonomous process to do it. So either a human signs off on every single step, which makes the agent a very expensive form, or the agent acts freely, which makes the security team’s stomach drop.

And then the third wall, the one that kills it for good: nobody can say what the agent did. A regulated business cannot put a process into production if it cannot reconstruct, after the fact, every action that process took and why. There is no audit trail because the agent was never built to leave one. Compliance asks one question, the team cannot answer it, and the pilot goes into the drawer where pilots go to die.

Three walls. Data, action, audit. None of them is a model problem. Every one of them is infrastructure that does not exist yet.

Why I find this exciting instead of depressing

I want to be honest about something, because this newsletter is going to be honest or it is going to be boring. When I first understood that the 95% was an infrastructure problem and not a model problem, my reaction was not disappointment. It was relief, and then something close to excitement.

Because a model problem is somebody else’s problem. If the bottleneck were model capability, the answer would be “wait for the labs,” and there would be nothing for the rest of us to build. But an infrastructure problem is a buildable problem. The thing standing between 95% and production is a layer that someone can actually make. The execution layer underneath the agent: governed data access, an enforced action boundary, an audit trail that holds up. The 5% who break through are not running smarter models than everyone else. They are running on that layer. They built it, or they bought it, and it is the entire difference.

We spent a decade building software for humans. Deterministic rules, siloed databases, a person in the loop holding the context together in their head. Then we dropped probabilistic, autonomous agents on top and acted surprised when they could not survive it. That is not a tragedy. That is just a layer we have not built yet. And building it is the most interesting problem I have worked on.

Yes, I am building in this space. I am not going to pretend otherwise or hide it. But this newsletter is not a place I am going to sell you anything. It is the place I think out loud about the problem, because thinking out loud in public is how I have always figured things out, and because the people who deal with this same wall are exactly the people I want to argue with.

What this newsletter is going to be

Here is the plan for The Last Mile Notebook, so you know what you are subscribing to.

It is field notes, roughly weekly, on getting agents from pilot to production. Some issues will be about a specific wall and how a real team got past it. Some will be uncomfortable, like the next one, which is about the clock I think most enterprises are not watching: the leaders already run about a dozen agents in production, coordination breaks around five without something underneath holding it together, and the catch-up window looks like it is measured in months, not years. Some issues will just be me being wrong in public and correcting it later, which is the most useful thing a builder can do.

What it will not be: recycled X threads, generic AI commentary you could get from any model, or a drip campaign with a newsletter costume on. If I ever start writing those, unsubscribe, and you will be right to.

One ask, and it is not a sales ask

If you have watched a pilot die at one of those three walls, hit reply and tell me which wall it was. Data, action, or audit. I read every reply, and the patterns in those replies are going to shape what I write about next. The best issues of this thing are going to come from your stuck pilots, not my opinions.

And if the way I see this is useful to you, subscribe. The next issue is about the twelve-month window, and why being one agent behind is worse than it sounds.

That is the whole game. See you in the next one.

Written with CreateOS

---

Sources I leaned on this issue:
1. MIT Project NANDA, State of AI in Business 2025
2. The longer, product-voice version of this argument lives on our blog:
Why 95% of Enterprise AI Pilots Never Reach Production

Two updates this week, both built to give you more visibility and more control over what’s happening. Let’s get into it.

What’s New Section 📣

No more hunting through release notes or refreshing your inbox to see what shipped. The new What’s New section lives directly inside CreateOS, so every fresh feature is one click away from your dashboard.

• In-product updates — see what’s new without ever leaving the platform.

• Always current — every release shows up the moment it goes live.

• Zero catch-up — features land in front of you, not buried in an email thread.

  

Check What's New

Query your DB straight from CreateOS 🗄️

You’ve deployed your database. Now you can talk to it without leaving the platform. The new Raw Query tab inside the DB view lets you run SQL directly against your deployed databases — no external client, no port forwarding, no extra setup.

• Inline SQL editor — write and run queries straight from the deployment page.

• Read-only by design — SELECT, WITH, SHOW, EXPLAIN, and DESCRIBE are supported; write operations like INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, and TRUNCATE are blocked to keep production safe.

• Instant results — query output renders in a clean tabular view right beneath the editor, with row counts and execution time.

• Faster debugging — inspect data, verify schemas, and sanity-check deployments in seconds.

Whether you’re peeking at user records, checking row counts, or confirming a migration ran clean, it’s all one query away now.

Explore your DB

That’s a wrap, see you all next week.
Sid

Walk into any enterprise six months into AI adoption and you’ll find the same scene. There’s an agent in Slack summarizing channels. Two more inside Notion. A pricing assistant in Stripe. A code reviewer in GitHub. A research bot somebody’s intern built in Replit and forgot about. Someone connected ChatGPT to the CRM via Zapier. The CTO is sponsoring a “unified AI strategy.” Meanwhile twelve teams are running thirty-eight agents. Nobody knows what they cost, what they touch, or who owns them. Not security. Not finance. Not engineering.

This is the agent sprawl problem. It’s the second wave of shadow IT, except this time the shadow systems can write to production databases.

We’ve been watching this play out across every customer over the last quarter. Enterprise teams need to make one architectural decision in 2026 before any of the other AI decisions matter.

The scope of what’s broken

The failure modes split into visible and invisible.

The visible ones: inference costs that grew 4x year-over-year with no attribution to which team or use case drove them. Security teams discovering an agent has been writing to a production database for three months because someone wired it up through a no-code automation tool. Compliance officers in finance, health, and government quietly killing AI pilots because no one can answer the auditor’s first question: what touched the data?

The invisible failure mode is the one nobody flags in a status meeting. It’s velocity. Every team is reinventing the same five patterns: an internal copilot, a customer-facing assistant, a code reviewer, a research helper, a workflow trigger. None of them share infrastructure. The same agent gets built six times across six teams. The same authentication problem gets solved six times. The same observability gap exists six times. By the time the executive team gets serious about “AI strategy,” there’s a year of fragmented investment that doesn’t compose into anything.

The deeper problem is ownership. In the previous era of enterprise software decisions, somebody owned the architectural choice. The CIO owned the cloud decision. The CISO owned the security perimeter. The CFO owned the procurement model. With AI, the decision got made by everybody and nobody at the same time. Every team adopted tools faster than any central function could evaluate them. The people who would normally draw the architectural lines were busy approving budget requests for the next pilot. Nobody owns AI architecture inside most enterprises right now, because everybody owns AI.

How this happened (and why it’s not the teams’ fault)

This was rational at the team level and incoherent at the company level. When a frontier model gets ten times better in a year, no team can afford to wait six months for IT to evaluate a platform. So every team picks its own stack: the model, the orchestration framework, the deployment target, the observability layer. And ships. The result is exactly what you’d expect. Dozens of working solutions. No architecture.

This is the same dynamic that produced SaaS sprawl in the 2013–2018 cycle, compressed into eighteen months. The difference matters. SaaS sprawl was a finance problem and an integration headache. You ended up with seventeen tools doing roughly what three could do, and consolidation projects took years. Agent sprawl is a different category of problem. Agents aren’t just applications. They have agency. They write code that runs in production. They hit APIs that move money. They make decisions that affect customers. When the inventory you can’t see is a list of dashboards, the worst outcome is a budget overrun. When it’s a list of agents, the worst outcome is something you’ll be explaining to a regulator.

This reads as a tooling problem, fixable with another procurement cycle and a vendor RFP. It’s not. What got skipped is an architectural decision. Architectural decisions don’t get unmade by buying more tools. They get unmade by deciding what the layer beneath the tools looks like.

The architectural choice nobody’s making yet

The question is what the architectural decision is about. We think it comes down to three properties. The layer running your agents has to provide all three. No enterprise we’ve talked to has any of them yet.

Visibility. You can see every agent operating inside your environment. Not “we surveyed our teams and they reported 38 agents.” Actually observable, in a single place, by the people responsible for the perimeter. What’s running, what it costs per call and per day, what it last touched, who deployed it, when it last changed. This sounds basic. Today, most enterprises cannot produce this list, because no central system has it.

Governance. You can stop one. Or scope it. Or sandbox it. The ability to say “this agent can write to these specific systems and no others” and have it enforced at the execution layer, not relied on at the prompt layer. Today, most “guardrails” are instructions sitting inside a system prompt that the next jailbreak could undo. That’s not governance, that’s hope. Real governance is the ability to revoke an agent’s access to production at 3am from a single console and have the agent stop, immediately, everywhere.

Accountability. You can bill it back. Cost attribution by team. Performance attribution by use case. ROI attribution at all. If you can’t tell finance which team’s agent generated this week’s inference bill, you can’t make any rational allocation decision in next year’s budget. Today most enterprise AI spend is allocated by hand, after the fact, with disputes.

These three properties are not solved by buying a unified AI platform from any single vendor. The agents you need will come from different places: your own engineering teams, vendor-shipped agents, open-source ones, agent marketplaces that don’t exist yet but will by next year. The execution layer has to be model-agnostic and origin-agnostic. Anything that assumes you’ll buy all your agents from one place is solving a smaller problem than the one you actually have.

Where this leaves us, and where it leaves you

Here’s where CreateOS is. We’re not telling you we’ve solved agent sprawl today. We’re telling you we think this is the architecture problem worth solving, and we’ve been building toward it.

What’s shipped today is Multi-agent Create. It’s a builder layer for shipping full-stack AI apps end-to-end. Parallel agents (frontend, backend, database, reviewer) take a plain-language prompt to create a deployed application, entire workflow in under fifteen minutes. That’s a builder problem solved, not a governance problem solved. We’re clear-eyed about which one is which.

What we’re talking to a small number of enterprise design partners about is the execution layer underneath. The properties above (visibility, governance, accountability) are the spec we’re working from. The partners we’re working with are the ones who can tell us whether the spec is right before we ship the wrong thing. Our bet is that by 2027, the question of what runs your agents will be a board-level decision in regulated enterprises the same way what runs your data is today. We’d rather be early than right on schedule.

If you’re inside an enterprise with twelve teams, thirty-eight agents, no central view, and a CTO sponsoring a strategy that doesn’t exist yet, we’d like to compare notes. Not pitch. Compare notes. We’re taking a small number of design partners over the next quarter. The bar is real enterprise context and willingness to share what’s actually happening. In return we’ll share what we’re seeing across the rest of the conversations and what we’re building toward.

The architectural decision your team didn’t make in 2025 is the one that matters most in 2026. We think there’s still time to make it deliberately.
Reach out at business<at>nodeops<dot>xyz if you want to make it together.

One update this week, but a major one which many of you have been waiting for. Let’s get into it.

Unified credits, used anywhere 🎯

Deploy credits and AI credits are now unified into a single credit system. No more transferring between the two, no more juggling balances; one pool that works across everything you do on CreateOS.

• Unified balance — Deploy and AI credits merged into a single pool.

• No more transfers — credits move with you, automatically.

• Use anywhere — build, deploy, or both — same credit covers it all.

• Cleaner tracking — one balance to watch, one top-up to manage.

Try CreateOS Now

Two updates this week, let’s get into it without wasting anytime.

Sleep your vibe-coding session 💤

Not every session needs to stay awake. Pause the ones you’re not using and stop burning credits on idle builds.

• One-click sleep — pause unused sessions and stop credit drain instantly.

• Save credits — only spend on sessions you’re actively building in.

• Resume anytime — wake it up and pick up exactly where you left off.

• Context preserved — chat history, file state, and decisions all stay intact.

Pause your unused sessions

Categorize your Skills for better management 🧠

As your Skills library grows, finding the right one shouldn’t slow you down. Skills can now be organized into categories so they’re easier to browse, manage, and reuse.

• Add Skills under defined categories — group by stack, workflow, or however you think about your work.

• Cleaner library view — categories keep things tidy as your collection scales.

• Faster recall — Create surfaces the right Skill from the right category at the right time.

  

Manage Skills

That’s a wrap, see you in the product :)

Sid

The first major AI-supply-chain attack of the agentic era happened this weekend, and if your team uses any third-party AI tool connected to Google Workspace, GitHub, or Slack, you should assume you are already inside the blast radius.

The headline is that Vercel disclosed a security incident on April 19. The real story is how it happened. The initial access vector was not a zero-day, not a misconfiguration, not a rogue insider. It was a third-party AI tool called Context.ai, with OAuth scopes into a Vercel employee’s Google Workspace account that it probably should not have had. Vercel’s CEO, in his public statement, suspects the attacker was “significantly accelerated by AI.”

The defender was breached by AI, through AI, and at AI speed. That is the pattern. Vercel just happens to be the first big name to put that pattern on a status page with their CEO’s signature attached. It will not be the last.

We are building CreateOS as AI-native deployment infrastructure, so this incident has our full attention. This post is not a gloat. Vercel handled disclosure better than most companies in their position would have. What follows is what the incident actually tells us about the next two years of application security, and what to do about it this week.

What actually happened

The sequence, as Vercel has publicly described it and CEO Guillermo Rauch laid out in a thread on X on April 19:

1. Context.ai, a third-party AI platform used by a Vercel employee, was breached. The specific compromised artifact is the Google Workspace OAuth application associated with Context.ai.

2. Through that compromised OAuth app, attackers took over the Vercel employee’s Google Workspace account.

3. From the Workspace account, they pivoted into some Vercel internal environments.

4. Once inside, they enumerated environment variables that were not marked as “sensitive.” Variables marked sensitive are encrypted at rest and Vercel says there is no evidence those values were read. Non-sensitive variables were readable by design. That is the feature, not a bug.

5. A BreachForums listing subsequently appeared offering Vercel data, including access keys, source code fragments, employee accounts, GitHub tokens, npm tokens, and internal database records, for two million dollars, with a first payment of five hundred thousand in Bitcoin.

Vercel has engaged Mandiant, notified law enforcement, and shipped dashboard improvements for environment variable management. They have confirmed that Next.js, Turbopack, and their open source projects remain safe after a supply chain audit. If you consume those packages, you do not need to pin to a pre-incident version. Monitor the bulletin for updates, but the release path appears clean.

A few things are still claim, not fact. The BreachForums poster used the ShinyHunters moniker. Threat actors historically linked to ShinyHunters have denied involvement to BleepingComputer and Cyberinsider. Attribution is contested and probably will remain so. The two million dollar figure is the listing price, not a confirmed ransom demand. The precise scope of what was exfiltrated, especially around npm tokens, GitHub tokens, and internal Linear data, is what the BreachForums actor claims, not what Vercel has confirmed.

One specific indicator of compromise that every Google Workspace administrator reading this should search for right now, per Vercel’s bulletin:

OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

If that app appears in your Workspace admin console under Security → API controls → App access control, revoke it and treat any credentials that passed through Context.ai workflows as potentially exposed. Vercel notes the Context.ai compromise “potentially affected hundreds of users across many organizations.” You are almost certainly not the only downstream victim if you used it.

Why this matters beyond Vercel

The Vercel-specific story is real and serious. The ecosystem-level story is bigger. Three points.

The attack vector is going to repeat. Every AI tool your team installed in the last twelve months asked for Google Workspace, GitHub, Notion, Slack, or Linear OAuth access. Developers approve these prompts reflexively. Each one is a potential Context.ai. The rapid proliferation of AI tools across developer and operational workflows in the last eighteen months has dramatically expanded the footprint of third-party integrations holding OAuth grants. Every new AI tool added to a Workspace becomes another potential initial access vector for your company. The bar for “what gets approved” has dropped at exactly the moment when the blast radius of a compromised approval has grown. That mismatch is the structural vulnerability. Vercel was one instance of it. There will be more.

“Significantly accelerated by AI” is a claim worth taking seriously, and holding carefully. Rauch’s exact words, in his April 19 thread: “We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel.” This is a CEO’s personal assessment in the immediate aftermath of a breach, not a forensic finding from Mandiant. Treat it that way. But it is not an outlandish claim either. The pattern Rauch is pointing at (attackers moving faster, understanding targets more deeply, enumerating systems with the kind of efficiency that used to require long manual reconnaissance) is consistent with what multiple threat intelligence teams have observed in recent incidents. The attacker economics are shifting. What used to take two weeks of manual enumeration may now take hours. If that is what happened here, and Vercel’s forensic partners eventually confirm it, this incident is a preview of what the median breach will look like by the end of the year.

When your AI supplier gets breached, your defenders learn about it on your timeline, not theirs. Vercel found the compromise, identified the upstream vendor, published an IOC, and engaged Mandiant, all on their own clock. Downstream customers of Context.ai who were not Vercel are in a much harder position: they have to discover they were compromised before they can respond to it. The trust model of OAuth-connected AI tools assumes your supplier will detect and disclose quickly enough for you to act. That assumption has not been stress-tested well, and this incident is the stress test. This is a structural problem with how AI tools are integrated into modern developer workflows, not a problem with any one vendor’s communication practices.

The 72-hour action plan

If you do nothing else after reading this, do these things. The order matters.

1. Google Workspace, right now.

Open your Admin console: Security → API controls → App access control. Search your OAuth app inventory for 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If it appears, revoke it. While you are there, review every OAuth app with sensitive scopes: gmail.readonly, calendar, drive, admin.directory. Revoke anything with broad scopes and low usage. This is the single highest-leverage action in this list.

2. If you are a Vercel customer.

Check your account activity log for the e xposure window, with a conservative lower bound of April 1 through today. Rotate every environment variable containing secrets that were not marked as sensitive: API keys, tokens, database credentials, signing keys. Treat them as potentially exposed. Mark all of them sensitive going forward. If you used the Vercel-Linear integration, grep your Linear workspace for pasted secrets. Linear issues are a known place where developers paste credentials during debugging.

3. GitHub, personal and organization.

Review the OAuth apps installed on your personal account and your organization. Audit the GitHub organization audit log for the exposure window. If you stored npm tokens in Vercel environment variables, rotate them at npmjs.com immediately. If you publish npm packages, run npm view <your-package> time --json and look for unexpected versions. Compare the tarball of any recent publish to the git tag it claims to come from.

4. Enumerate every AI tool with OAuth scopes.

Across Google Workspace, Microsoft 365, GitHub, Slack, Notion, and Linear, list every AI tool your team has installed in the last twelve months. For each, ask one question: if this tool gets compromised tomorrow, what is the blast radius? If the answer is “bad,” that is a risk register item this week. Consider moving new OAuth grants from user-driven approval to an allowlist with security sign-off. This is the structural fix. Everything else is a rotation.

5. Package managers and release paths.

If you publish npm packages, freeze automatic dependency merges for seven to ten days. Diff your main branch HEAD against the last known-good commit before April 1. Check GitHub Actions run history for unexpected runs, especially manual workflow_dispatch triggers or runs from branches that no longer exist. Look at release and tag creations you did not make. This is where a Vercel-initial compromise could theoretically become a supply chain event for your product, even though Vercel has confirmed their own release path is clean.

6. Stress-test your rotation muscle.

The real gap this incident exposes is operational. If your team cannot rotate a critical secret end-to-end (including every downstream consumer that validates against it) in under thirty minutes, that is the thing to fix after you finish this checklist. Incidents happen on their schedule, not yours.

The OpenSourceMalware incident response playbook on GitHub goes deeper on each of these items and is being actively updated. Bookmark it. Juliet.sh has also published a thorough analysis that handles the epistemics carefully.

The architectural lesson

Everything above is a 72-hour fix. The architectural lesson is bigger, and it is what you should be rethinking over the next quarter. Three principles.

OAuth scope minimalism is now load-bearing. Every AI tool should have the smallest OAuth scope that lets it function. The problem is that most AI tools ask for broad scopes because broad scopes let them ship features faster. Read-only Gmail access is harder to build against than full Gmail access. Deployment-level scopes are easier to work with than project-scoped ones. Every time a vendor takes the easier path, their customers inherit the blast radius. Push back. Decline OAuth grants that demand more than the feature requires. Treat “we need broad scopes to provide a good experience” as a sales objection to answer, not a technical requirement to accept.

Secrets should be encrypted by default, not encrypted on request. Vercel’s sensitive environment variable flag is opt-in. That is a design choice, and a defensible one in 2020. In 2026, given everything we now know about how AI tools broaden the attack surface, opt-in encryption for secrets is a liability. The right question to ask your deployment platform is not “can I encrypt secrets?” Everyone says yes. The right question is “what is encrypted by default, and what does an attacker who takes over a team account get to read?” If the answer to the second question is “any environment variable not explicitly flagged sensitive,” you have a gap. Fix it, or plan for the incident.

Concentration of trust is a security property, not just a procurement preference. When the same vendor holds your deployment platform, your environment variables, your DNS, your CI, your secrets manager, and has OAuth access into your Google Workspace, one compromise cascades. The industry has spent a decade consolidating developer tooling onto fewer platforms in the name of velocity. That was the right tradeoff for velocity. It is not necessarily the right tradeoff for security. Separation of concerns across infrastructure vendors slows some things down. It also ensures that a breach at one vendor does not cascade into a breach of your entire stack. That tradeoff is worth having as an explicit conversation on your team, not an implicit assumption.

How CreateOS thinks about this

I will be direct. We cannot claim to be breach-proof. Nobody who understands security can make that claim. What we can talk about is architecture, because architecture is where the specific risks that produced this incident either get designed in or designed out.

CreateOS runs on NodeOps distributed infrastructure rather than a single centralized control plane. That is a deliberate choice about where trust concentrates. Managed services (PostgreSQL, MySQL, Kafka, Valkey) are provisioned per project, not shared across tenants in ways that create cross-customer blast radius. One-click deployment is positioned with “no configuration files to manage, no accidental API key leaks, and zero server overhead” as defaults, not opt-in hardening. Every deployment runs through automatic security scanning as part of the default path.

On the AI-native side, which is where this incident matters most: our agents interact with your infrastructure through MCP with scoped API keys. They do not sit behind OAuth tokens with broad scopes across unrelated tools. The vector that produced the Vercel incident (a third-party AI tool holding Workspace-level OAuth scopes) is not a shape we accept in our own design. That is not because we are smarter. It is because we built this after the industry learned, painfully, that OAuth scope sprawl was a problem.

What we can honestly claim is this: the specific risks that produced the Vercel incident, namely overbroad OAuth scopes from AI tools, opt-in encryption on customer secrets, and single-vendor concentration of trust across deployment, DNS, CI, and secrets, are not concentrated in our architecture the way they are in the pre-AI-native deployment stack. If you want to compare architectures point-for-point, the CreateOS vs Vercel comparison lays it out without the marketing. You should still ask us hard questions. Any vendor that tells you their architecture is safe should be answering hard questions.

If this changed how you think

If this changed how you think about deployment architecture, the fastest way to try a different one is the migration guide at nodeops.network/createos/migrate-from/vercel. Most teams finish the move in fifteen minutes with zero downtime. It walks you through configuration mapping, environment variable import, build command translation, and DNS cutover.

If you prefer to do it from your terminal, install the migration skill directly:

npx skills add <https://github.com/NodeOps-app/skills> --skill vercel-to-createos

This is not a “drop Vercel, switch to us” pitch. Vercel has great engineers and real infrastructure and the incident does not change that. It is an invitation to compare architectures seriously, so that the next time this pattern plays out (and it will) you are not the team writing your own post-mortem.

Closing

Vercel will get through this. They have capable engineers, named Mandiant on day one, and disclosed publicly with their CEO’s name attached to a thoughtful statement that distinguished confirmed from unconfirmed. That is better incident response than most companies manage. Respect the work.

The structural issue is bigger than Vercel, and it will be playing out across our industry for the next two years. AI tools are not going away. OAuth is not going away. The combination of the two is going to keep producing incidents like this one until the industry designs the risk out rather than rotating around it.

The teams that build on AI-native infrastructure from the start, with scope minimalism, default-encrypted secrets, and distributed trust baked into the architecture rather than retrofitted onto it, are the teams that will be writing someone else’s post-mortem in 2027, not their own.

Build accordingly.

Four updates this week, and a couple of them change how you’ll use the platform day-to-day. Let’s get into it.

The CreateOS CLI is live ⌨️

The big one this week. Deploy, manage, and scale from your terminal — no dashboard required. Open source, built in Go.

• Deploy from your terminal — createos deploy ships code, createos deployments logs streams logs, createos status checks health.

• Full project lifecycle — env vars, custom domains, cron jobs, and scaling (replicas, CPU, memory) are all first-class commands.

• CI/CD ready — --output json and --force flags drop straight into GitHub Actions or any pipeline.

Install and go:

brew tap nodeops-app/tap && brew install createos
createos login && createos init && createos deploy

Install CreateOS CLI

Create now builds full-stack apps 🧱

Create used to stop at the app itself — anything beyond that, you wired up yourself. Not anymore.

• Full-stack in a single prompt — frontend and backend built together, no separate flows.

• Auto-provisioned services — databases, caches, and queues spin up automatically based on what your app needs.

• Wired up and ready — credentials and env vars injected at build time, so what Create gives you actually runs.

  Create Now

Skills are here 🧠

Skills let you shape how Create builds for you; reusable context, conventions, and capabilities it picks up on every session.

• Pre-installed skills — a growing library for common stacks and workflows, on by default.

• Bring your own from GitHub — point Skills at a repo and Create pulls in your playbooks and patterns.

• Upload files directly — style guides, internal docs, custom logic, drop them in and they become part of the skill.

  Explore Skills

  

Hibernate deployments to save credits 💤

Not every deployment needs to be awake 24/7. Staging, internal tools, side projects; hibernate them instead of burning credits.

• One-click hibernate — runtime credits stop draining immediately.

• Wake it up whenever — picks up where it left off, no redeploy needed.

• State preserved — env vars, domains, and service bindings stay exactly as you set them.

  Hibernate Deployments

That’s a wrap, see you in the product :)

Sid

A packed week. We shipped four updates that have been on the list for a while; a proper redesign of how you pay for and understand credits, a cleaner way to spin up your backend services, plus something a lot of you have been asking for since we launched. Let's get into it.

Unified payment modal to rule them all 💳

The old flow had you jumping between two separate screens depending on whether you wanted to top up or subscribe. That’s gone. We’ve rebuilt the entire payment experience into a single unified modal, subscription plans and pay-as-you-go top-ups live in the same place, side by side.

Here’s what changed:

• No more redirects to the pricing page — everything you need to make a payment decision is right there in the modal, without losing your place.

• Subscription and top-up in one view — see both options at once, compare them clearly, and choose what works for you without toggling between flows.

• Clearer tooltips throughout — if you’ve ever been unsure what a credit balance covers or why a plan is priced the way it is, the answers are now built into the modal itself.

The goal was simple: getting credits when you need them should take seconds, not a series of tab switches.

Check Out Now

Global credits vs Create credits - now actually clear 🧾

This distinction has confused a lot of you, and honestly that’s been on us. The credit

system has always had two separate pools — Global Credits that power everything on the platform (deployments, VM runtime, databases), and Create Credits allocated specifically for your AI build sessions.

Here’s what’s new:

• Both balances visible at a glance — you can now see your Global Credit balance and your Create Credit balance independently, so you always know which pool is being drawn from.

• Per-service usage breakdown — the credit usage screen now shows you what’s consuming credits and from which pool, so there’s no more mystery mid-session.

• Top up Create Credits from Global — if your Create Credits run out while you’re building, you can pull from your Global balance directly without leaving the flow.

No more running out mid-session and not knowing why.

Check Out Now

The Deploy Services modal got a full redesign 🗄️

Spinning up a database, cache, or message queue on CreateOS used to involve too many steps, unclear pricing, and a modal that didn’t give you enough information to make a confident decision. We rebuilt it from scratch.

Here’s what changed:

• Cleaner configuration UI — the setup flow for all three service types (Database, Cache, Message Queue) is now simpler and more intuitive. You get to what you need faster with less noise.

• Better service overview — each service now has a proper summary of what it is and what it’s for, so you’re not guessing which one to pick.

• Pricing shown inline — no more hunting for what a service will cost you. Pricing is right there in the modal before you confirm anything.

If you’ve been putting off setting up a backend service because the old flow felt like too much, now’s a good time to revisit it.

Deploy Services Now

Cron jobs are live ⏰

This is the big one for this week. The Cron Jobs tab is now available inside every CreateOS project. You can schedule any HTTP call to run on a recurring cadence — no external service, no Zapier workaround, no cron running on a separate VM somewhere.

Here’s what you can do with it:

• Create a cron job in under a minute — give it a name, pick your environment (staging or production), set a schedule, and point it at any endpoint with optional headers and a request body.

• Quick presets or fully custom schedules — every minute, every hour, daily, weekly — or drop in a raw cron expression if you know what you’re doing.

• Full execution history — every run is logged with the scheduled time, success/failure status, HTTP response code, and full log output you can copy or download.

• Pause and resume without deleting — flip the toggle to suspend a job and bring it back whenever you’re ready, history intact.

One thing worth knowing: there’s no “Run Now” button yet, you can’t manually trigger a job outside its schedule. That’s coming. But for scheduled automation, it’s all there.

Set Up Cron Jobs Now

That's a wrap for this week, see you in the product :)

Sid

Are builders slowed down by a lack of tools, or by how disconnected those tools have become?

This week’s reads explore the shift toward unified execution environments, how infrastructure, creation, and economics come together in a single system, what real-world AI deployment looks like in production, and why shipping is becoming accessible to anyone with an idea.

One Workspace. Three Layers.

Modern applications are no longer just code, they are systems that combine infrastructure, development workflows, and economic coordination. This piece introduces the CreateOS ecosystem through three layers: the Power Layer (decentralised compute), the Creation Layer (the unified workspace), and the Economic Layer (value capture and distribution). Together, they show how execution, coordination, and incentives can exist within a single environment rather than across fragmented tools. Read full blog here.

The Single Intelligent Workspace for Builders

Building, deploying, and managing applications often requires jumping across multiple tools, each with its own interface, logic, and configuration. This article explores the concept of a single intelligent workspace where these steps are unified into one continuous flow. Instead of stitching together services, builders can move from idea to production within the same environment, reducing context switching and operational overhead. Read full blog here.

Industrial AI in Practice: Textile Case Study

AI infrastructure is often discussed in theory, but real value comes from applied use cases. This case study examines how AI systems can be deployed in industrial environments, specifically within textile operations. It highlights how data, models, and compute come together in production settings, and what it takes to move from experimentation to reliable, real-world impact. Read full blog here.

Build It Now: When Anyone Can Ship

The barrier to shipping software is shifting. This piece explores how modern tools are enabling a new wave of builders to go from idea to live application without deep infrastructure knowledge. It argues that when execution becomes simpler, more people can participate in building, leading to faster iteration, more experimentation, and a broader range of use cases emerging in the ecosystem. Read full blog here.

Where does the biggest gap between building and shipping show up in your workflow today?

If you have articles, essays, or research worth including in next week’s edition, share them with us.

More next week.

Happy reading,
NodeOps Team

Are developers slowed down by complexity, or by the operational work created around the tools they use?

This week’s reads explore tool sprawl as a form of technical debt, the hidden glue work holding fragmented stacks together, why more dashboards do not restore focus, and the unseen operational load quietly absorbed by product teams.

Tool Sprawl Is the New Technical Debt for Modern Dev Teams

Technical debt no longer lives only in code. This piece argues that modern teams also accumulate debt through the growing web of tools wrapped around delivery. As more systems get layered into the workflow, developers pay the price through context switching, coordination overhead, brittle integrations, and slower execution from idea to production. Read full blog here.

The Hidden Glue Work Holding Most Modern Developer Stacks Together

Many modern stacks depend on scripts, bots, cron jobs, spreadsheets, and one-off workflows that never appear on a roadmap but keep everything functioning. This article examines how fragmented systems create hidden glue work, why that work becomes essential, and how much delivery risk accumulates when critical operational knowledge lives in side repos and in a few people’s heads. Read full blog here.

Why Another Dashboard Won’t Fix Developer Focus

Adding another dashboard can improve visibility, but visibility alone does not repair a fragmented workflow. This piece explains why “single pane of glass” thinking often creates one more read-only surface instead of reducing the number of places where real work happens. The result is more tabs, more dashboards, and little improvement in decision-making or execution continuity. Read full blog here.

Shadow Ops: The Unseen Work Keeping Your Product Alive

Many product teams quietly operate with an unofficial ops layer inside them. This article explores the reactive work that falls onto engineers who handle incidents, manual deploys, rollbacks, config drift, and emergency scripts without formal ownership or support. The core argument is that shadow ops keeps products running, but it does so by consuming focus, reducing feature capacity, and pushing operational strain onto a small number of people. Read full blog here.

Where does hidden operational friction show up most in your workflow today?

If you have articles, essays, or research worth including in next week’s edition, share them with us.

More next week.

Happy reading,

NodeOps Team

Two big ones landed this week; a full Supabase integration that makes backend setup genuinely seamless, and a credit history view so you always know exactly where your credits are going. Let’s get into it.

Supabase is Now Live on CreateOS 🟢

This is one we’ve been excited to ship. Supabase is now fully integrated into CreateOS; no switching tabs, no copy-pasting credentials, no manual configuration. Your database is part of your deployment workflow from the start.

Here’s what you can do:

• Connect your existing Supabase account — link your account once and all your projects are immediately accessible inside CreateOS.

• Create new Supabase projects directly from CreateOS — no need to visit the Supabase dashboard to spin up a new project. Do it right from where you’re already working.

• Map your Postgres database to your project — link an existing Supabase Postgres database to any project and CreateOS automatically configures all the environment variables for you. Just start building — the connection details are already there.

• Connect Supabase services to your deployed apps — map your Supabase services directly to your running applications on CreateOS so everything stays linked and in sync.

The goal here was to remove every friction point between having an idea and having a database ready to use.

Connect Supabase with CreateOS

Credit History is Here 📊

You asked for more visibility into how your credits are being used, and we heard you. Credit History is now live under Billing & Usage in your profile.

Here’s what you’ll find:

• Full credit consumption history — see every credit transaction logged against your account, in one place.

• Date range filtering — filter your history by any time window to understand spend patterns across days, weeks, or months.

• Per-service breakdown — see exactly which services are consuming credits independently, so you can pinpoint what’s costing what and optimise accordingly.

No more guessing. Just a clear, filterable record of exactly how your credits are being used.

Check Your Credit History

That’s a wrap for this week! Both of these updates have been a long time coming and we’re really happy with how they’ve turned out. As always, if you have feedback or run into anything, we’d love to hear from you.

Sid

I want to confess something.For most of 2025, I shipped fast. Obsessively fast. I watched the tooling evolve in real time — Skills, MCPs, agentic workflows — and each wave felt like we were finally solving the right problem. We were giving AI agents hands, then legs, then the ability to run entire workflows without a human babysitting every step.

But every time I came back to a session the next day, I had to start from scratch. Re-explain the context. Re-establish what we were building. Re-set preferences. My AI agent was, in every functional sense, a goldfish. Brilliant in the moment. Gone by morning.

That gap has a name now. It’s called the Memory Layer. And I think it’s the most important thing you should be thinking about building in 2026.

The 2026 Stack Is Missing One Floor

Here’s how I see the year unfolding so far, if you squint at it from a distance:

Skills unlocked what AI can do. Modular, composable, plug-in capabilities that let any agent inherit new powers without rebuilding from scratch. The skills economy turned AI from a monolith into a marketplace.

MCPs (Model Context Protocol) defined how AI connects. A standard handshake between models and the real world — your codebase, your data, your APIs. Suddenly your agent wasn’t just smart in a sandbox; it was wired into the actual infrastructure of your product.

Agentic Workflows showed what AI can execute. Multi-step reasoning. Autonomous task completion. Agents that don’t just respond but do things — plan, iterate, deploy, and loop back.

These three layers together created something remarkable: AI that can act.

But there’s a floor missing.

Memory determines what AI becomes

.

Not just what it can do in this session. What it learns from every session. What it carries forward. What it retains about you, your users, your patterns, your product decisions, your failures.

Without memory, agentic AI is extraordinarily capable and completely amnesiac. It starts every conversation as a stranger who happens to be a genius.

What "Memory" Actually Means (It’s Not What You Think)

Most people hear "memory" and picture a database. A storage bucket you dump things into. Maybe a vector store. Maybe RAG.

That’s not what I mean. And honestly, that framing is why most teams get this wrong.

Memory is a policy, not a bucket.

There are four decisions happening every time an AI system interacts with the world:

1. What should be written to memory? (Not everything. Not nothing. The right things.)

2. Where should it be stored, and in what form? (Raw transcript? Compressed summary? A learned preference? A mistake to avoid?)

3. What should be retrieved when answering this query? (Recent context? Relevant patterns? Long-horizon episodes?)

4. What should be forgotten? (The hardest question nobody talks about enough.)

Right now, most production systems answer all four of these with heuristics. Simple relevance scores. Fixed expiry. Quota-based trimming. One-size-fits-all rules duct-taped to an otherwise sophisticated stack.

The frontier is: learn those policies instead of hand-tuning them.

This is the insight I keep returning to from a deep dive I did on this recently. The mental model that shifted everything for me: memory in AI is structurally identical to experience replay in reinforcement learning. The memory store is the replay buffer. Retrieval is a sampling policy. And you want to surface experiences based on learned importance — not just recency or keyword similarity.

→ Read the full technical breakdown here

Three Memory Layers Every Production System Needs

Let me make this concrete. If you’re building anything meant to run over multiple sessions — a copilot, an agent, a product assistant — here are the three layers you need to think about:

📼 Layer 1: Episodic Memory — "What happened?"

This is the event log. Not raw transcripts (those explode in size), but structured episodes: what was attempted, what succeeded, what failed, why. The agent needs to remember that last Tuesday it tried approach X on problem Y, and it didn’t work.

Most systems have this partially implemented as conversation history. But conversation history without episodic structure is noise. You want curated events, not raw logs.

🧠 Layer 2: Semantic Memory — "What did we learn?"

Extracted, compressed knowledge. User preferences. Product decisions. Coding patterns. Brand voice. The things that should always be true regardless of when the next session starts.

ChatGPT’s memory stack — when you reverse-engineer it — is surprisingly practical here. It doesn’t do per-request vector search over full history. Instead, it injects a compact list of long-term user facts and short summaries into every prompt. Small, curated, always-present. This gives strong continuity with predictable latency. It’s a masterclass in pragmatism: you don’t need a pipeline the size of a data warehouse to feel like the AI actually knows you.

⚙️ Layer 3: Procedural Memory — "What strategies work?"

This is the hardest layer, and the most underbuilt. Which approaches reliably produce good outcomes for this user, on this class of problem, in this product? Which tools get better results in which contexts?

Humans acquire procedural skill through accumulated experience — we learn how to do things, not just what to do. The agents we’re building right now have almost none of this. Every session, the agent re-derives its approach from scratch, because there’s nowhere to park learned strategies between runs.

This is the layer that transforms an agent from a tool into a collaborator.

Why This Is the Right Moment

I know what you’re thinking. Memory isn’t new. RAG has existed for years. Context windows keep expanding.

But here’s what’s changed:

The mode of AI interaction has changed. When AI was primarily a one-shot question-answer interface, memory was a convenience. When AI is orchestrating multi-step agentic workflows across your entire infrastructure — often running for hours, across tools, across sessions — memory becomes structural. Without it, every agentic run is cold-start.

The cost of statelessness is compounding. A chatbot that forgets you is annoying. An agent that forgets the architectural decisions you made three sessions ago — and goes off in the wrong direction for two hours — is expensive. As agents take on longer-horizon tasks, the penalty for amnesia scales non-linearly.

The tooling is finally ready. Products like Mem0, Zep, Letta, and MemOS have emerged explicitly as memory infrastructure for agents in the last few months. The category is crystallizing. Which means if you start now, you’re early. Not too early — the tooling exists — but early enough that memory-native products will feel like magic compared to the stateless alternatives most users are accustomed to.

The differentiation window is open right now. Today, almost every AI product your users interact with starts fresh every session. The team that ships genuinely persistent AI — that remembers, that improves, that feels like a collaborator that knows them — will be nearly impossible to displace.

What I’d Build Right Now

If I were starting a new project today with Memory Layer as the thesis, here’s where I’d focus:

For B2C products: User-specific semantic memory. What does this person prefer? How do they like to work? What have they already told you they don’t want? Build the "profile" that the agent carries into every session. Start simple — a compact JSON of extracted facts and preferences — and make it richer over time.

For developer tools: Procedural and episodic memory. What has this developer tried and failed? What patterns does their codebase follow? What decisions were made and why? An agent that carries codebase-level context across sessions is a fundamentally different class of tool.

For enterprise agents: All three layers, with governance. Memory in multi-tenant, regulated environments needs to be: isolated per user, auditable, controllable (users should be able to see and edit what the agent remembers), and compliant. This is hard. It’s also a real moat.

For infrastructure builders: The memory policy itself. Build the write/read/forget policies as learnable, tunable systems — not hardcoded heuristics. The teams who crack learned memory management will be the picks-and-shovels layer for every application sitting above them.

The Uncomfortable Truth About Where We Are

Here’s what I keep sitting with: we spent the last year making AI agents incredibly capable. They can deploy code, query databases, run multi-step workflows, and connect to nearly anything through MCP.

And yet — almost none of them remember.

They’re like a brilliant contractor who shows up every morning and asks you to re-explain the whole project from scratch. Every. Single. Day.

"Once an agent remembers users, policies, decisions, and past mistakes, it stops being a chatbot and becomes part of your infrastructure."

The next wave of competitive advantage in AI products isn’t going to come from the model being smarter. Models are already smart enough for most things we need them to do. It’s going to come from the model being persistent. From products that accumulate context, that get better the more you use them, that feel — genuinely feel — like they know you.

That’s the Memory Layer. And right now, almost nobody has built it properly.

I think that’s an enormous opportunity.

Build It Now

If you’re working on something in this space — whether it’s agent infrastructure, memory tooling, or a product that could be dramatically better with persistent context — I want to hear about it.

Reply with what you’re building. Let’s think through it together.

The shift is happening. Skills showed us what’s possible. MCPs connected us to the world. Agentic workflows gave AI legs.

Memory gives AI a self.

#BuildItNow

I wrote a deeper technical breakdown of memory architectures — from RAG to reinforcement learning — on Substack if you want to go further down the rabbit hole: Memory Layers in LLMs: From Retrieval to Reinforcement Learning →

Building on CreateOS? Our Skills marketplace and MCP integration make it dead simple to wire memory-native workflows into your deployments. Try it free → nodeops.network/createos

We’ve been busy building, and here’s everything that’s new on CreateOS this week. Let’s jump in.

Auto Top-Up for Create Credits

No more running out of credits mid-deployment. We’ve shipped an auto top-up feature that automatically replenishes your Create Credits from your global balance whenever it dips below a certain threshold. You’re fully in control, you can adjust the threshold, change the top-up amount, or disable it altogether if you prefer to manage things manually. Set it once and forget about it.

Create Now

Deploy Straight from GitHub

This one’s going to save you a lot of time. You can now deploy a project by simply pasting a GitHub link, that’s it. No cloning, no configuration steps, no back and forth. Just drop your repo URL in, and CreateOS handles the rest. We’re really excited about how much smoother this makes the deployment workflow.

Deploy Now

Promo Codes & Flexible Discounts

We’ve built out a full-featured promo code system, and it comes with more flexibility than you might expect:

• User Cohorting — Create and target specific user groups with tailored discount codes. Great for onboarding campaigns or rewarding loyal users.

• Tier-wise Promo Codes — Tie promo codes to specific products so you can run targeted promotions without affecting your entire catalog.

• Monthly Credit Allocation — Set up free-month promotions by automatically granting credits on a recurring basis. Perfect for trials and partner deals.

Whether you’re running a launch campaign or setting up a referral program, this gives you the tools to make it happen.

Redeem Now

Supabase Integration (Live in Days)

Big one here — we’re adding Supabase to CreateOS. This means you’ll soon be able to spin up databases, manage auth, and access more backend services directly from the platform. It’s currently in final testing and will be live within the next couple of days. Stay tuned for the announcement.

Bug Fixes & Platform Maintenance

As always, we’ve been squashing bugs and making things run smoother behind the scenes. Nothing flashy, but it keeps everything humming along nicely.

Reach Out On Discord

That’s the wrap! We’ve got a lot more in the pipeline, so keep an eye out. As always, if you have questions or feedback, we’d love to hear from you.

Sid