Internal AI Workspace: Why Ramp Glass and Shopify River Exist

Ramp's AI tool spending reportedly reached $1.5 million in a single week, and the company's answer was to build Glass, an internal workspace meant to make every employee an AI power user. Shopify has been doing something similar for longer through a set of internal systems with water-themed names. Both companies already had access to the best commercial models. Both decided that model access alone wasn't the bottleneck.

This guide answers the question a COO or platform lead will ask after reading those announcements: why build a company AI workspace at all, and what does it need beyond a chat box? It ends with a buy-versus-build checklist and one workflow you can scope this quarter.

Why private AI chats stop paying off inside a company

Most companies roll out AI the same way. They buy seats, run a lunch-and-learn, and wait. Some employees become very good. They write long system prompts, paste in the right documents, and build personal routines. Most don't, and the gap between those two groups keeps growing.

The issue is structural. A private chat holds everything that makes AI useful at work (the prompt, the context, the procedure, the result) inside one person's history. When that person finds a good way to reconcile vendor invoices, nobody else gets it. When they leave, it's gone. When the output is a spreadsheet, it sits in their downloads folder and nobody else can see it.

A company AI workspace moves those pieces into shared infrastructure:

• Procedures become shared skills that anyone can run.
• Context comes from company systems, so nobody has to paste it in.
• Actions run through governed connectors and sandboxes, so the AI does work instead of describing it.
• Outputs become artifacts that others can open, edit, and reuse.

That's the move from "AI as a personal assistant" to "AI as a utility." The economics change too. Under the per-seat model, value depends on each person's skill. Under the workspace model, one well-built skill raises the floor for everyone who uses it. Our post on agent skills over prompts covers the mechanics of packaging procedures this way.

What Ramp and Shopify have published

Keep what each company has documented separate from what commentators and vendors infer about them. Neither company has published a full architecture, and their designs shouldn't be treated as interchangeable.

Ramp Glass. Ramp's announcement of Glass presents it as an AI workspace for the whole company. The goal, as described in coverage and in an independent playbook write-up from AI Catchup, is to give every employee a capable setup without making each person configure their own tools, prompts, and integrations. The focus is on adoption: the people who would never write a system prompt should get the same benefit as those who would. Employees have also described Glass in their own words. One Ramp employee's LinkedIn post describes using Glass heavily from their first weeks at the company, which suggests onboarding is part of the pitch. Ramp's announcement is the source to check on whether Glass is internal-only or offered to customers. We don't make that claim here.

Shopify River, Aquifer, and Quick. Shopify Engineering has written about several layers. Under the River covers the infrastructure beneath River, Shopify's internal agent system, including the execution layer called Aquifer. A separate post on Quick describes a way for employees to publish small internal tools and pages. Taken together, Shopify treats running agent work and sharing what employees build as separate problems, each with its own platform.

The common thread. The New Stack's reporting notes that Coinbase, Shopify, and Ramp all built their own agent harnesses and all still pay a frontier model provider. That's the key fact for buyers. These companies didn't build workspaces to avoid paying for models. They built them because the harness around the model (context, tools, permissions, execution) was where their own requirements lived.

Don't assume Ramp runs anything like Aquifer, or that Shopify's adoption approach looks like Glass. The two examples are useful because they stress different layers.

The nine layers a workspace needs beyond chat

The list below is our suggested architecture, drawn from the published examples and from general agent engineering practice. It isn't a description of either company's internals. Use it as a requirements checklist when you evaluate a vendor or scope a build.

A few of these deserve more detail.

Permissions are the hardest layer to retrofit. If the workspace's retrieval index was built with a service account that can read everything, an intern can ask about the board deck and get an answer. The fix is to enforce access at query time based on the requesting user's identity, which we cover in permission-aware AI agents. Commercial workspaces vary widely here, so test it directly during evaluation.

Execution is what turns a chat tool into a workspace. Once the AI can run a query or a script, it can produce a reconciled spreadsheet instead of instructions for making one. It also creates a new attack surface. Where that code runs matters, and the tradeoffs among containers, microVMs, and hosted sandboxes are in where agent code actually runs. Shopify's choice to write publicly about the layer beneath River shows how much engineering this takes.

Durable sessions matter more than they seem to. A finance close task that pulls from three systems and takes twenty minutes will hit a timeout or a rate limit at some point. Without checkpointing, the user starts over and stops trusting the tool. Durable agents explains the pattern.

Connectors should be curated, not exhaustive. You'll be tempted to connect everything on day one. More tools can make agents worse at choosing the right one (details here). Start with the three or four systems your first workflow touches.

Shopify's own guide to leading AI transformation stresses governance and culture alongside the tooling. That matches the layer list. Skills, permissions, and cost controls are as much about organizational policy as about engineering.

Buy, extend, or build: a decision checklist

Ramp and Shopify have large engineering teams and strong internal platform cultures. Most companies have neither, and copying the "build" decision without those conditions is how a workspace ends up half-finished and maintained by one engineer who'd like to work on something else.

There are three realistic paths:

1. Buy. Adopt a commercial AI workspace from a model provider or productivity vendor, then configure shared projects, connectors, and admin controls.
2. Extend. Keep a commercial workspace as the front end and build your own skills, MCP servers, retrieval services, and sandboxes behind it.
3. Build. Own the interface, harness, execution layer, and integrations, and call model APIs directly.

Work through these questions in order. The first "no" usually tells you where to stop.

Questions that point toward buy:

• Do our core systems (email, docs, CRM, ticketing) already have supported connectors in the commercial products we're considering?
• Does the vendor enforce per-user permissions on retrieval and actions, and can we verify it with a test account?
• Can admins publish shared skills or projects that every employee sees by default?
• Do we get usage and cost reporting broken down by team?

If you answer yes to all four, buy. Spend your engineering time on skills and adoption.

Questions that point toward extend:

• Do we have one or more internal systems (a custom ERP, a proprietary data warehouse, a homegrown ops tool) that no vendor will ever connect to?
• Do we need code execution against internal data that can't leave our network?
• Do we have specific approval or audit rules for certain actions?

If yes, keep the commercial front end and build the missing connectors and sandboxes as services it can call. This is where most mid-market companies end up, and it keeps you portable if you switch vendors. Our build vs. buy framework goes deeper on the cost side.

Questions that justify build:

• Do we have a platform team that can own the workspace as a product for years, with on-call?
• Is our usage high enough that per-seat pricing costs more than running our own harness and paying for API tokens directly? (Measure first; know your token mix explains how.)
• Is the workspace itself a competitive advantage, the way Ramp's product sits close to the work of finance teams?

If you can't answer yes to all three, you're probably not in Ramp's or Shopify's position, even if the announcement made you want to be.

Generic "AI workspace" guides, such as this overview from Aiwork, tend to list features without addressing who maintains them. Ask that question about every layer in the table above. Each layer you build is one you're responsible for indefinitely.

One practical first workflow: the weekly account brief

The fastest way to test any of the three paths is one recurring workflow that produces a clear artifact. Here's a hypothetical example to use as a template.

The workflow. Every Monday, each account manager needs a one-page brief for their top ten accounts: open support tickets, recent usage changes, upcoming renewals, and anything unusual in billing. Today, a composite account manager at a mid-sized B2B company spends part of Monday morning pulling this together from four tools.

What the workspace has to do:

The workflow is small, but it touches eight of the nine layers. A workspace that can't run it cleanly will struggle with anything bigger. A workspace that can gives you a reusable skill, a cost baseline, and a permissions test you can repeat each time you add a connector.

Scoping rules for the pilot:

• Keep it read-only at first. Writeback to the CRM comes later, after the briefs are trusted.
• Write the anomaly thresholds down as rules. "Usage down more than a set percentage week over week" belongs in code, not in a prompt.
• Pick five account managers, not fifty. Compare their briefs against ones they assemble by hand for two weeks.
• Log every run: inputs, tool calls, cost, and whether the account manager edited the output.

The edit rate is your metric. If account managers rewrite most of each brief, the context or the skill is wrong. If they send it largely as is, you have a pattern to repeat for the next team. Embedding the brief in tools people already use (a Slack message, a CRM tab) usually beats asking them to open a new app, a point covered in launching AI workflows inside existing systems.

Scoping your first workspace pilot with OpenNash

The extend path is where an outside team adds the most value. The commercial front end is already chosen, and what's missing is the custom layer behind it: connectors to internal systems, a sandbox that keeps data on your network, permission checks tied to your identity provider, and skills written for your actual procedures.

OpenNash works on that layer. An engagement starts with an audit of which workflows have clear artifacts and stable source systems. Next comes a design pass that defines permissions, approval points, and cost limits before anything ships. The build delivers connectors and skills as services your team owns and can point at a different front end later. If you build instead, the same pieces become the foundation of your own harness.

If you're deciding between buy, extend, and build, bring one candidate workflow, like the account brief above, to a scoping call with OpenNash. In it, we'll map that workflow onto the nine layers, mark which ones your current tools already cover, and estimate what the remaining gaps would take to build and maintain.