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

What actually slows builders down: complexity or the number of tools they have to navigate?

This week’s reads explore the daily cost of context switching for solo founders and small teams, the learning tax imposed on vibe coders by fragmented stacks, and what a more unified developer day could look like.

A Day in the Life of a Solo Founder

Solo founders rarely lose time in one dramatic failure. They lose it through repeated shifts between support, code, logs, billing, analytics, and infrastructure. This piece shows how those constant role and tool changes create execution drag, turning attention into a hidden runway cost rather than focused product progress. Read full blog here.

A Day in the Life of a Small Dev Team

Small teams often move quickly on paper, but a surprising amount of time disappears into coordination work between tickets, PRs, chat threads, dashboards, and incident tools. This article breaks down how modern team workflows generate meta-work, where information has to be continuously moved, re-explained, and stitched together across systems. Read full blog here.

A Day in the Life of a Vibe Coder

For vibe coders, fragmented tooling is not just an operational problem. It is a learning problem. Instead of focusing on core concepts like requests, state, and application logic, beginners often burn energy navigating logs, dashboards, configs, and troubleshooting loops that sit outside the actual act of building. Read full blog here.

What a Truly Unified Developer Day Could Actually Look Like

This piece flips the question from what slows developers down to what a more coherent day could look like. It outlines a workflow where code, deploys, observability, incidents, and configuration live in one connected environment, reducing the mental overhead of switching tools and making execution feel continuous rather than fragmented. Read full blog here.

Where does fragmentation 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

Are builders really slowed down by a lack of tools or by how those tools interact?

This week’s reads explore context switching, fragmented tooling, deployment myths, and the concept of a unified execution environment.

1. Why Context Switching Is Killing Modern Builders

Every time a builder jumps between IDEs, dashboards, logs, and deployment panels, there is a cognitive reset cost. These micro interruptions compound throughout the day, reducing deep work and slowing execution. The article breaks down how context switching silently erodes productivity even when teams feel “busy.” Read full blog here.

2. The Cost of Fragmented Tooling

Best in class tools do not automatically create a best in class workflow. When development, infrastructure, deployment, and monitoring live in separate systems, coordination becomes the bottleneck. This piece examines how fragmented stacks increase overhead and slow delivery despite individual tool quality. Read full blog here.

3. Deployment Isn’t the Bottleneck Anymore

Speeding up deployment pipelines alone does not increase development velocity. The real bottleneck often appears earlier in the flow, in handoffs, environment configuration, and execution continuity. This article reframes the common assumption that faster CI/CD equals faster shipping. Read full blog here.

4. What Is a Unified Execution Environment?

A unified execution environment brings creation, deployment, infrastructure, and iteration into a single coherent workspace. Instead of stitching tools together manually, builders operate within an integrated system designed to reduce friction across the entire execution layer. This piece outlines the architectural and workflow implications of that shift. Read full blog here.

Where does 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

Big week over at CreateOS. Here’s everything that just shipped:

1. Free deployments & vibe-coding sessions

No more worrying about session limits. Deployments and vibe-coding are now completely free — you only pay for LLM usage (input/output tokens, model-dependent). Build and ship as much as you want.

Create on CreateOS

Deploy on CreateOS

2. OpenClaw got a serious upgrade

Several quality-of-life improvements landed this week:

• Live terminal now embedded directly in the app (no more tab-switching)

• Customisable bot names

• Choose your preferred LLM

• Deploy multiple bots — the single-bot restriction is gone

Deploy OpenClaw

3. CreateOS Skills — ship anything from your AI agent

CreateOS is now available as an MCP skill. Your AI agents can deploy to production directly — no API key needed. Supports GitHub auto-deploy, Docker images, and direct file upload. Works with Node, Python, Go, Rust, Bun, and frameworks like Next.js, FastAPI, Express and more.

Install it with:

CreateOS Skills.sh

CreateOS Skills Doc

4. Upload files & images in Create

You can now attach PDFs and paste images directly into your prompts. Drop in your PRD, a design spec, or a screenshot — and let Create build from it. No more copy-pasting walls of text.

5. Preview loads 10x faster

We’ve significantly optimised preview load times. Your vibe-coded apps will now appear almost instantly. Less waiting, more building.

6. In-app guidelines

We’ve published a full set of guides inside the app covering:

• How credits work and how to manage them

• Project structure tips for better vibe-coding results

• Choosing the right model

• Version control & session management

• Prompt length limits

7. Prompt best practices

New in-app docs on writing prompts that actually work — what to do, what to avoid, and specific guidance on themes, frameworks, and app types. Worth a read before your next session.

That’s a wrap for this week. More coming soon — stay tuned.

The CreateOS Team

We have spent years observing the same friction in how tools get made. Most people who feel a problem most acutely are the ones least equipped to build the solution. They can describe the frustration of a manual workflow or the gap in their team’s coordination with perfect clarity. The path from that clarity to a working application has been blocked by the high walls of technical execution. Many assume they need to hire a team or learn years worth of infrastructure management before they can even begin.

Build It Now is a global series we designed to challenge that assumption in public. The premise is simple. We sit down with someone who has an idea but no technical label, and we do not leave the table until that idea is a live, functional application. CreateOS demystifies the entire path from idea to production by bringing everything into a unified execution environment, so with CreateOS all you need is an idea. We take care of the rest.

Why the distance between ideas and apps is collapsing

The reason most ideas stop at the “I wish this existed” stage is rarely a lack of imagination. It is the sheer weight of what comes after the initial spark. Building usually means stitching together separate tools for design, logic, and hosting, each with its own learning curve and potential for failure.

CreateOS exists to remove that burden. It is a unified execution environment that absorbs this complexity so the builder does not have to. In one workspace, they can describe the problem, shape the interface, connect the logic, and ship a live version without juggling multiple stacks or tools.

During Build It Now sessions, we use the platform’s natural language configuration to turn a verbal description of a problem into a structured data model and interface. Instead of worrying about server provisioning or API pipelines, the builder focuses on the logic of their specific use case and the outcomes they care about. Because deployment and operations are built into the workspace, the first version of their tool is live the moment the logic is connected.

Moving beyond the “technical gatekeeper”

We believe that starting is no longer reserved for people who can navigate a command line. In city after city, we’ve seen the same transformation. Once a person realizes they can describe a flow in plain language and see it appear as a shareable link in a single sitting, their relationship with technology shifts. They move from being a passive consumer of software to an active architect of their own efficiency.

CreateOS handles the heavy lifting under the hood, from integrating with external systems to running verifiable compute, so the builder can iterate in real time. When a prototype is minutes away instead of months away, the fear of “getting it wrong” gives way to a habit of constant improvement. It becomes normal to try, ship, learn, and refine.

What the series will show you

In the Build It Now series, we are documenting these builds in the open. From Delhi to Rome to New York and beyond, we will sit down with people who have held onto an idea because they thought they were not the “right person” to build it. We will ask a simple question: what is one idea you have always wanted to take live. Then we will build it with them, right there, using CreateOS.

Each episode will follow the same pattern. A clear problem. A conversation in plain language. A workspace that turns that description into a real application. By the end, what started as a thought becomes something they can open, share, and use.

This series is not a performance of what we can do. It is an invitation to see what you can do. Whether you are managing a small team, running a business, or trying to automate a repetitive part of your day, these episodes will show how the tools of creation are now within reach.

An invitation to start now

If you have an idea you have been holding back because you did not think you were the right person to build it, we invite you to follow along as the first episodes of Build It Now go live. Watch as a thought becomes an application.

The starting line has moved. Build it now, launch it with CreateOS, and turn your ideas into reality.