Something changed last week that most teams haven't noticed yet. On April 22, OpenAI launched Workspace Agents — a new class of AI that doesn't wait for you to open a chat window. It runs on a schedule, operates while you're offline, and can live directly inside a Slack channel. You @mention it like a colleague. It threads its work back in when it's done.
That's a different proposition than anything that came before it.
The most significant shift is the move away from purely session-based interaction.
Custom GPTs were useful in the same way a calculator is useful: you pick it up, you use it, you put it down. Workspace Agents are an evolution of that model. Powered by Codex, they can take on tasks people already do at work — preparing reports, writing code, responding to messages — and they run in the cloud, so they keep working even when you're not. The session ends. The agent doesn't.
The concrete example OpenAI keeps citing is telling. Rather than requiring sales reps to manually research accounts, review call recordings, and compile deal summaries before weekly reviews, a Workspace Agent now handles the entire sequence automatically — researching accounts, summarising call recordings, and posting structured deal briefs into the relevant Slack channel. A process that previously consumed five to six hours per rep every week now runs automatically in the background on every active deal.
That's not a chatbot. That's a standing delegation.
Why Slack is the obvious home for this
The timing is not accidental. Slack recently unveiled a new Real-Time Search API and Model Context Protocol (MCP) server capabilities, with partners like OpenAI, Anthropic, Google, Perplexity, Dropbox, Notion, Cursor, and others building intelligent agents that live natively in Slack. The platform has been deliberately repositioning itself as the surface where agents operate, not just people.
The logic is sound. Conversational data — the informal discussions, decisions, and institutional knowledge that accumulates in workplace chat — will become the fuel that makes AI agents truly useful rather than generic. An agent that can read three months of channel history before drafting a response is genuinely more useful than one that can't. The context is already there. MCP is just the pipe that connects it.
Slack describes this as "context engineering" — the process of determining exactly which information from a user's channels, files, and messages should be fed into the model's context window — and treats it as the factor that determines the quality and relevance of every response. That's a real insight, not marketing copy. The bottleneck for most enterprise AI deployments has never been the model. It's been context starvation.
The thing nobody is talking about clearly enough
There's a real risk that gets glossed over in the launch coverage.
Enterprises deploying MCP are running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability. These aren't edge cases. They're the default experience for any team that moves from a single chatbot to a mesh of connected agents.
The security picture is genuinely complicated. Invariant Labs demonstrated that a malicious MCP server could silently exfiltrate an entire message history. The Supabase Cursor agent incident in June 2025 showed how a privileged agent processing user-supplied support tickets could be tricked into leaking integration tokens through prompt injection. These incidents happened in real production systems, not labs. They are not edge cases from poorly built experiments — they happened because the architecture of MCP creates attack surfaces that traditional security tools were not built to see.
OpenAI is aware of this. Administrators can define which data and tools an agent is permitted to use, who may create and share agents, and which actions require manual approval, and there are built-in safeguards against prompt injection attacks. But the documentation doesn't specify what those safeguards actually are. The company states the workspace agents include built-in safeguards to protect against prompt injection attacks, but did not include any specifics of what that entails.
That vagueness matters. If you're deploying an agent into a channel that handles customer data, finance requests, or HR conversations, "built-in safeguards" is not a satisfying answer to give your security team.
Shared agents are a governance problem, not just a setup problem
Here's what's actually new about Workspace Agents that most teams will underestimate: they're shared. They're designed to be shared within an organisation, so teams can build an agent once, use it together in ChatGPT or Slack, and improve it over time.
That sounds like a feature. It's also a governance question that most organisations haven't answered yet.
When one person builds an agent and shares it with a channel, every member of that channel inherits whatever access that agent has. Using a personal account to set up the agent's connections and making it available to others can inadvertently allow access to data that other users shouldn't see. OpenAI recommends scoping access to only what is required to limit inadvertent data exposure and exfiltration risks. That guidance is buried in the help documentation, not surfaced during setup.
An AI teammate like Beagle runs natively inside Slack and Teams, so we think a lot about this — what context an agent should surface to whom, and what it should stay quiet about.
The pattern that works is treating every shared agent the same way you'd treat a shared service account: minimum permissions, documented purpose, named owner, regular review. Not because agents are untrustworthy, but because the blast radius of a misconfigured agent is larger than a misconfigured human.
What this actually means for your team
The infrastructure is genuinely ready in a way it wasn't six months ago. MCP has achieved industry-wide adoption backed by competing giants including OpenAI, Google, Microsoft, AWS, and governance under the Linux Foundation.
2026 marks the transition from experimentation to enterprise-wide adoption. The tooling is converging. The pipes are standardised.
What isn't ready is most teams' thinking about what it means to have an agent that acts when you're not watching.
The useful framing isn't "what tasks can I automate?" It's "what decisions am I comfortable delegating, and to what level of confidence?" A weekly metrics report posting to a channel automatically: low risk, high value. An agent that responds to customer messages, updates CRM records, or routes support tickets without a human checkpoint: those deserve deliberate scoping before you enable them.
Many of the most important workflows inside an organisation depend on shared context, handoffs, and decisions across teams. Workspace Agents are designed for that kind of work: they can gather context from the right systems, follow team processes, ask for approval when needed, and keep work moving across tools. The approval checkpoint is the key phrase. Use it.
The most valuable thing a team can do this week isn't to build the most ambitious agent. It's to agree — in writing, in a channel where everyone can see it — on which agents exist, what they can touch, and who owns them when something goes wrong.
That conversation is five minutes. Not having it is how you end up debugging at 11pm.