Transcription
OpenAI just launched ChatGPT workspace agents, and after spending the week around the research preview with teams that are actually trying to use it, I think the headline is being underplayed. This is not just custom GPTs with better connectors. These are not just projects with a schedule button for a very specific kind of work. Workspace agents is a direct competitor to the lightweight automation layer companies have been stitching together with Zapier, Make, Workato, N8N, C-pilot Studio, and a lot of internal glue. And the reason that matters is simple. The first useful build is not a six-month transformation project. It's probably just an afternoon.
So, I'm going to walk through six things in this video: What is actually in the product? Why this is different from earlier versions like custom GPTs and projects? The pattern of work where it works, the pattern where it doesn't work, the governance piece that makes this real for enterprises, and the one agent I would build first. The short version is this: If your team has a job that repeats every week, crosses two or three tools, and already has a recognizable good versus bad output, this is probably the cheapest agent experiment you can run right now. But that sentence has a lot hiding inside it.
Here's what's actually in the box. So on April 22nd, OpenAI introduced Workspace agents and ChatGPT as a research preview for business, enterprise, education, and teachers plans. The rollout is gradual and enterprise admins have to enable it. So, this is not an everybody has it today situation, but the direction is clear. You click agents in the sidebar. You describe a workflow your team does often, and ChatGPT helps turn that description into an agent. So, the builder drafts the profile, helps select tools and connected apps, generates or attaches skills, writes out the instructions, and gives you a preview surface before you publish. You can start from scratch or you can start from templates and examples for things like product feedback routing or weekly metrics reporting or lead outreach or software review and other, you know, similar repeatable team workflows.
That build experience is the first thing that changes the category. So, three weeks ago, if you wanted a shared team agent that lived in Slack, looked across SharePoint or Google Drive, understood your calendar, ran on a schedule, and produced a recurring output, you basically had two options. You could get an engineer involved, or you could commit the team to a low-code automation platform. Now, for eligible workspaces, you can describe the workflow in plain English, wire it up to apps like Google Calendar, Google Drive, Slack, and SharePoint. You can add custom MCP servers if you need something beyond the built-in tools, and you can publish the result to the people who actually need it. That does not mean every non-technical person is suddenly a great automation architect. I want to be clear here, but it does mean that the first draft of the automation does not any longer require a whole separate software project. That's the product shift.
Workspace agents run in ChatGPT. They can be shared inside a workspace. They can be scheduled and they can run in Slack through the ChatGPT agent app, which means they show up where work is already happening instead of forcing the team into a separate surface. That Slack point sounds small until you use it. Most internal AI tools tend to fail for very boring reasons: people don't remember to open them. The workflow lives adjacent to the place where the work actually happens, and anything adjacent eventually becomes optional. We're lazy. If the agent is in the Slack channel where the request appears or the escalation lands or the deal is discussed, it becomes part of the work instead of living in a separate tab.
There are also a few environment details worth knowing before anybody goes out and decides to sell this internally. Workspace agents is not available on ChatGPT Plus. It is for workspace plans only. It is off by default at launch for enterprise workspaces. It is not available for enterprise customers running enterprise key management. Also, it's free until May 6th, after which OpenAI says credit-based pricing starts. So, if you have access and you want real signal, the window to try it without thinking too hard about it is quite short.
Now, that's just part one of six here. The product is not just a chatbot. It's a cloud agent builder for repeatable team workflows. The next piece we're going to get into is why that matters because this is the thing that custom GPTs and projects were trying to become and never really got to.
Now, some context before I go further. I'm sure this is not a surprise to you. I am not an enterprise. So, the serious builds I'm talking about here are not my personal internal workflows. They belong to small and large teams I'm connected with who are chatting with me privately about what's working and what's not. What I've been doing this week is sitting next to those teams as they stood up their first workspace agents and comparing the outputs to what those same teams were getting from custom GPTs and projects just a month ago. And that distinction matters because workspace agents are not really built for solo productivity. They're built for shared work. It's built for the messy middle where a process lives across multiple people, multiple systems, a bunch of repeated judgment calls. And in that context, the comparison is stark.
A custom GPT is basically a prompt in a suit, right? You write instructions, you upload files, maybe you attach an action, then you ship it, and you hope people use it. Sometimes that works, but I found the quality is really dependent on the skill of the person writing the prompt. So, I've tried custom GPTs for customer service ticket triage for other use cases more than once inside teams that I've been advising. It's not been great. Not a little bad. The kind of bad where the team stopped using it within a couple weeks because the marginal lift over a rep reading the ticket themselves was negative once you counted the time that was spent second-guessing the output. The same shape of task moved into a workspace agent is producing drafts that ticket owners are actually willing to send. The difference is not that someone wrote a magic prompt here. The difference is that the agent can operate against the surrounding workflow, right? It can use tools. It can follow multiple steps. It can work with files. It can run where the ticket owner already works and be governed in a way an admin might actually allow near customer data.
Projects were really the next step after custom GPTs and projects were better. They gave you a shared workspace. They gave you files. They gave you instructions. They gave you memory. They gave you continuity. If custom GPTs were prompt-first, projects were context-first. That was a real improvement. But projects still assume a huge human lift. Someone has to curate the files, keep the context coherent, start the session, decide what matters, and drive the work forward. I've used projects for incoming RFP response work. I've watched sales teams try the same thing. Projects can help. They beat custom GPTs by a mile, but they do not make the work autonomous. The new RFP still needs a person to drive it, right?
One of the teams I've been talking with moved that same kind of RFP workflow into a workspace agent this week. The agent reads the inbound RFP, pulls similar prior responses from SharePoint, drafts a first pass against the company's playbook, flags the fields it can't answer, and then posts the draft with the missing pieces into the AE's Slack DM. That turns several hours of assembling into like 20 minutes of editing. It's a big jump. It's not "this tool helps me do the work." It's "this tool does a first pass on the work and I review," and it's a good enough first pass that it really saves me time. And that's where the category starts to change, right?
Across the teams I've been watching, the workflows that failed under custom GPTs are mostly the same workflows that are starting to work now: ticket triage, RFP response, inbound lead qualification, recurring reporting, product feedback summaries, sales prep. And the reason, it's not that mysterious. Those jobs were never just about generating text, were they? They were about coordination. They required finding the right context, moving between systems, applying a known rubric, and then putting the output back where the team needed it. Custom GPTs made the team carry the product. Projects made the team carry the context. Workspace agents, at least in the workflows where they fit, they actually lift the load. They carry more of the process. And that matters because it moves the prompt surface out of sight where you don't have to think about it, and you start to focus on managing recurring work. So that's the second of the six parts here in this video.
The next point is the most important one if you are deciding what to build because workspace agents are not good at everything. The use cases that work tend to have a similar shape. The work repeats. It's usually weekly. Often, more often, maybe daily or hourly. The output has a clear good and a clear bad. The steps can be described in a paragraph or so. And the work crosses at least two or three tools that used to require a person to coordinate manually. That's a pattern, right? It repeats often. It has clear output. It's simple enough to describe. It crosses tools. If your work fits that shape, workspace agents are interesting. If your work does not fit that shape, it might be useful, but I wouldn't start there.
The public reference build I keep coming back to is the Rippling example OpenAI highlighted at launch. A sales consultant built a sales opportunity agent without an engineering team. It researches accounts, summarizes Gong calls, and it posts deal briefs into the team's Slack room for active opportunities. The quoted result was 5 to 6 hours a week of rep work moving into the background on every deal. That's the shape you want to copy. The reason is the structure, not the sales context, right? There's a recurring object of work, the opportunity. There are known inputs: account research, call notes, deal context. There's a useful output, which is the deal brief, and there's a place to deliver it: Slack. And of course, there's an obvious reviewer: the rep who owns the deal. That is a good agent workflow.
If you're in sales, the first builds are really obvious, right? An inbound lead qualifier, a pipeline hygiene agent, a post-call CRM updater, or a competitive intel agent that watches target accounts and posts useful context to Slack. Those work because sales already has a strong operating rhythm. Leads come in, calls happen, deals move or stall, reps know what a useful summary looks like, and managers know what bad pipeline hygiene looks like. That gives the agent a narrow job and a very clear evaluation bar.
Now, if you're in a coordination-heavy role, the build I would copy is a bit different. It's an overnight feedback synthesizer. Have it read the last day of relevant team channels. Have it pull out emerging themes, open questions, blockers, and decisions that seem to be forming. And then have it deliver a morning brief to the chief of staff, to the exec assistant, or the ops lead who already spends the day turning scattered conversation into something like usable context. The reason this one works is visibility. The output shows up every morning, and the failure modes are really obvious. If it misses the most important thread, you know right away. If it summarizes noise as signal, you know right away. If it saves an hour before the first meeting, you're going to feel that. That is a good first agent because you do not need a quarter to know whether it worked.
Now, if you're in product or product ops, the reference build is something like a product feedback router. It will monitor your Slack for you. It will look at your support tickets. It will look at public feedback channels and extract product feedback from the noise. It'll dedupe repeated asks. It will group the signal by product area, and it will publish a weekly digest with links back to the underlying tickets or the threads. That's one of the places where synthesis is not a nice-to-have, it's actually the work. Every product team says it wants to be close to the customer, and then the feedback arrives in like 18 places with duplicate reports and no clean path into the roadmap conversation, and no one has time to dig through it. The agent doesn't replace the PM's judgment here. It clears the pile so the PM can use judgment on the right thing. And that distinction matters because the best agent workflows do not try to automate high-value judgment. They automate the coordination layer around that judgment.
Now, if you're in a customer success or support role, the highest leverage first build is probably a support ticket router. Incoming tickets can get deduplicated against the existing queue, tagged by product area, checked against known issues, and either drafted for a first response, or escalated with context. Adjacent builds are easy to imagine, right? A weekly customer health digest or a renewal prep agent that starts 60 days out and builds a retention brief with usage trends and support history and open issues. Customer success is full of workflows that already have structured data and narrative outputs. That's why agents can be useful there quickly. The connective tissue across all of these is the same. The agent is not being asked to invent a strategy, right? It's being asked to run a known process across known systems on a known cadence and deliver something a human already knows how to judge.
Now, the important inverse that we're going to get into in the next part of this video is why a lot of people are going to try workspace agents, point at the wrong work, and decide the product is the problem. And that's part four.
So, workspace agents are an automation and coordination platform first. It's not the tool I would reach for first if you want novel research. It is not where I would start for a one-off polished artifact. And it is not, at least from what I've seen so far, the product I would trust with long-horizon autonomous work where the path changes over multiple days. I've talked about complex agent harnesses that do that work before. That's not what workspace agents are for. For those jobs, I would use tools built for depth, for artifact quality, or for long-running autonomy. Workspace agents are strongest when the path is known. And that's the phrase I would keep in your head. If the path is known, it gets really interesting, right? If the path is unknown, you should be careful.
The temptation with every new agent product right now is to test it on the hardest thing you could imagine, right? Can it figure out our entire Q3 strategy? Uh, can it run a market map for a category we don't understand yet? Can it independently manage this open-ended cross-functional initiative for the next month? That's the wrong eval. You will get a messy answer, and you will not know whether the failure came from the model, the workflow, the prompt, the context, the permissions, or the lack of a stable definition of done. A better eval is narrower. Take one job that already happens every week. Take one output that exists. Take one person who reviews that output and have the agent produce the first draft for a week. Now you have signal. You can compare it to the human baseline. You can see where it saves time. See where it creates review burden and decide whether it's worth it. That's a test, right?
So, saying this really bluntly: If the work is novel, if it's one-off, if it's judgment-heavy, this is probably the wrong product for you. If the work repeats, if it crosses tools, it can be described in a paragraph. Now we're talking.
And that brings us to the part that I think enterprise buyers are going to care about more than the agent demos. The next part here, part five, it's about governance, right? Enterprises need a product that is serious about governance to allow agents like this across multiple tools in the enterprise. And the governance story is the reason I think workspace agents will win enterprise seats this quarter. Admins can control who can use agents, who can build them, who can publish them, which apps and tools are allowed, and what kinds of actions require approval. There's version history, analytics for runs and users, compliance API coverage, and the ability to suspend agents if needed. That sounds like a super boring list if you're thinking about consumer AI. It is not boring if you've ever tried to get an agent approved inside a real company. Most agent products don't fail because the demo is bad. They fail because the security and the governance story are thin for the system of record that they need to touch, and they're not trusted. The CIO does not want a demo. The CIO wants to know who can build the thing, what it can access, what it can write to, where the logs are, how approvals work, and how quickly the company can shut it down if something goes wrong. OpenAI is building to that checklist.
One setting deserves special attention because it is exactly the kind of thing teams will get wrong if they move too fast. There is a role-based control for publishing agents with personal connections. In plain English, the person who built the agent may use their own authenticated app connections, and other people running the agent may be able to access data or perform actions through those connections as the creator. That's powerful. It's also risky. If your best sales consultant builds a useful agent and publishes it with a personal account connected to a sensitive system, you need to understand what everyone else can now do through that connection. I think the right posture is least privilege here. Use service accounts where possible. Scope access down to what the agent actually needs. Limit the audience. Avoid sensitive or high-impact connectors until the workflow has been tested, and then audit that configuration regularly. And the wrong posture, of course, is just to assume the demo works and we should roll it out to everyone without checking on it per team, per use case, per access first. And this is the bitter lesson every company learned with SAS automation, except that the blast radius is of course larger because the agent is not just moving fields from one app to another.
Underneath the hood, workspace agents are powered by code execution in the cloud. So they can use tools, work with files, run code, remember what they learned, and continue across multiple steps. That's why they're useful. But it's also the difference between a prompt template and an execution system. And it means your review workflow has to assume the agent can do things. That sounds really obvious, right? Most companies still treat AI output as if it's text on a screen. But with agents, text is just the visible bit. The important bit is that the system can touch a lot more than it used to. That's why governance is not an enterprise afterthought here. It is the product. The value is not just "an agent can update the CRM." The value is "an agent can update the CRM inside a permission model the company can live with." And that's the fifth part.
The last point is the strategic read because once you understand what this replaces, I think the competitive picture in the AI agents landscape looks very different. So, the company that's launched this is not mainly Claude. I know you might have thought that. It's also not Perplexity. It's not even mainly ChatGPT's old custom ChatGPT product. No, the thing workspace agents competes with most directly is the lightweight automation layer. So, Zapier, Make, N8N, pieces of Copilot Studio, pieces of Retool, and the internal ops workflows that companies have been gluing together for the last 5 years or so. Now, that doesn't mean those companies disappear. They have deeper features. They have broader integrations. As they've matured customers and use cases that workspace agents will not touch for a bit. But the first question you ask is changing because if a team wants to automate a recurring workflow that starts in Slack and touches shared docs and checks a calendar and summarizes a call and updates a ticket or drafts a report, the default answer is no longer obviously "go build a Zap" or "ask ops to wire it together." The default answer might be "build the workspace agent first," and only move to a dedicated automation platform if the agent hits a wall. And that is a big change.
It also changes the job of the ops person. If your company was about to hire someone to manage a pile of brittle automations or build them, maybe you now need fewer brittle automations. If you already hired that person, their job probably gets better and more complicated. They become the person who designs, tests, governs, and improves agents for the company, which is a real role that is growing really fast. And it's a role that's much higher leveraged than the old ops role.
There's also a much bigger industry pattern underneath all of this. In February 2026, Peter Steinberger, the creator of OpenClaw, joined OpenAI to work on personal agents and OpenClaw moved toward an open-source foundation model with OpenAI support. Now, whether you care about OpenClaw specifically or not, that pattern matters. The independent agent framework builders are getting pulled into the major AI platforms. The things that looked experimental six months ago are becoming default product primitives. Things like persistent execution, proactive runs, deep tool integration, skills, memory, shared surfaces, and agents that operate where work already happens. Workspace agents looks like that pattern arriving in an enterprise ChatGPT product. And this is why I think that the launch is a little bit easy to underestimate. If you evaluate it as a chatbot feature, it just looks like an upgrade. If you evaluate it as an automation layer, it looks like the thin end of the wedge. And if you evaluate it as a sign of where enterprise AI is going, it looks like one more step away from "ask a model a question" and toward "delegate a process to the agent."
And that's a more thoughtful read, right? Because the strategy that you need to keep an eye on is the overarching picture of ChatGPT as an LLM tooling solution eating up more and more and more of enterprise workflows. The vision for OpenAI is really clear and it's really obvious at this point. They want to turn code execution and the agents that run powered by code execution like workspace agents into the default OS for the entire work of the corporation. And they want to make sure that they tie everything into a context layer that enables you to do that work seamlessly across your existing tool sets. Now, that's a little different from Claude's strategy because when Claude is launching new stuff, a lot of what they're launching is more vertical. Right now they're launching Claude Design, which was positioned as a Figma killer, whether or not it is that, that's sort of how the positioning has worked out, and their hiring patterns show that they're going after other applications as well: finance, HR tech, etc. So they are looking at work as a series of functions. And OpenAI, with their product releases, is looking at work right now more as a series of cross-departmental workflows that they want to eat up and pick up with code execution, with workspace agents, etc. That's how to read the tea leaves, and that's where this race is going next.
Now, I want to leave you with what you build first. If you have access to workspace agents, here is the move I would make before that May 6th free window closes. Pick one job your team does every week. Don't make it the most important job in the company. It's not the complicated workflow. It's not the thing that would be amazing if an agent could do it perfectly. Pick a job that eats five or six hours. It has a clear output. It crosses two or three tools. It has a human reviewer. And write that workflow down really clearly. Make sure you understand it. For example, every Monday morning, read the last week of customer support tickets, group them by product area, deduplicate repeated issues, flag anything tied to high-value accounts, and then post a summary with links in the customer success Slack channel. Or, every time a new opportunity hits stage, pull account research, summarize the latest Gong call, check whether the CRM has a next step, and post a deal brief to the AE and the manager. Or, every Friday afternoon, pull the week's product feedback from Slack and support, group it by theme, identify the top five emerging issues, and draft a digest for the product leads.
The paragraph matters because if you cannot describe the workflow really simply, the agent will not save you. You are probably asking it to solve ambiguity you have not resolved as a team. Once you have the paragraph, open up the builder and let ChatGPT draft the scaffolding. Connect only the tools the agent needs. Spend an hour tightening up the instructions, preview it, and then ship it to the Slack channel where work already happens. Let it run for a week. At the end of the week, do not ask the vague question, "Is it impressive?" Ask these questions instead: Did it save time against the old workflow? Did the review burden stay below the time saved? Did the output improve enough after one or two iterations that the team would miss it if you turned it off? That's a good eval. If the answer is yes, you've got a real agent. Congratulations. Build the next one. If the answer is no, you learned something cheaply. Maybe the workflow was ambiguous. Maybe the connectors were wrong. Maybe the output rubric wasn't clear. That's all still useful information. The habit that matters is measuring agent work against real work. That is the difference between teams that are getting compounding value from all this AI stuff and teams that churn off of them after a few weeks and get frustrated.
So, the first draft, honestly, it might only get you 60% of the way there, right? And that's fine. The question is whether the second or third draft that you build move you toward more of an operating rhythm. Now, remember, the free window closes on May 6th. So take advantage of it while it's there. Make sure you know what you're getting into before they turn on per-token pricing, and make sure that if you are building a process for your team, you are building it in a way that deliberately seeks to lift load from the team. One of the biggest barriers to AI adoption is when leaders and executives promise that a new agentic workflow is going to make things easier, and teams actually try it and they find it's heavier. There's more work to do. They're more stressed as a result. So, make sure that you are laser-focused on lifting the load on the team as you work through this process. And then you're going to get much, much higher enthusiasm, much, much higher willingness to adopt agents as a result. I'll leave you with that. Best of luck.