Seven days after the May 20 launch. A practitioner's read on what Glean actually shipped, where Skills earns its keep, and where the runtime-versus-runner question still matters.
Publisher disclosure: This site is published by ASCENDING, which builds Jarvis AI — a competing agent platform. The read below comes from working through Glean's May 20 launch post, their 2026 enterprise search evaluation, the Futurum coverage of the $200M ARR milestone, and conversations with a handful of Glean customers who got the briefing. Comparisons to Jarvis Registry, MCP, A2A, and AgentCore Runtime appear in one section, flagged.
On May 20, 2026, Glean shipped what they're calling the "enterprise AI coworker." Skills workflows. Adaptive Reasoning. Approval controls. Voice conversations. A shared Library for prompts and Skills across the company. The press hit. Customer briefings went out. By the end of the week, I'd had three separate conversations that all started the same way: "is this an agent platform now, or is it search with a workflow builder bolted on?"
Honest answer: it's neither, exactly. And the precise way it's neither is what this article is about.
What Glean shipped on May 20
The launch surface, drawn from the May 20 launch post and the partner briefing that followed, breaks down to five pieces. Skills is the new workflow primitive — a named, reusable instruction set that an end user or admin can author, attach to data sources and tool calls, and run on demand or on schedule against the Glean corpus. Adaptive Reasoning is Glean's name for the planner that decides which retrieval and which Skill to invoke in response to a user query, with the planner output surfaced in the response so the user can see what was decided. Approval controls let an admin require human sign-off before specified Skills execute write actions against connected systems like Salesforce, Jira, or Slack. Voice conversations is the obvious thing: speak a query through the Glean app, get the same Glean answer back as audio with the citations attached. And the shared Library is the org-wide repository for prompts, Skills, and (per the launch post) saved Adaptive Reasoning chains the team has refined into reusable artifacts.
The framing in the launch post leans hard on "coworker." The framing in customer briefings, when I asked, leaned harder on "AI agents." Both frames are partially true. The product surface that shipped is closer to a knowledge-grounded workflow runner with planner-driven retrieval than to a general-purpose agent runtime. That's a sentence that took me a day to write because the line between those two categories has been smudging for eighteen months.
Skills: workflows or agents? (the runtime-versus-runner question)
A workflow runner takes a defined sequence and executes it. An agent runtime takes a goal and lets a reasoning loop pick the steps. The two categories converge as workflow runners add planner steps and as agent runtimes add deterministic guardrails, but the underlying contract with the developer is different — and the audit posture flows from that contract.
Skills, as shipped, behave like a workflow primitive with optional planner assistance. You define the Skill: instruction, attached data sources, allowed tool calls, optional approval gate. Adaptive Reasoning may decide which Skill to run for a given query, but inside the Skill, the path is mostly fixed. That's a workflow runner. A useful one — knowledge-grounded, identity-aware, sitting on top of the Glean corpus that already indexes your SaaS sources — but a workflow runner.
This is not a criticism. A workflow runner that runs against a well-governed corpus is the right primitive for most "summarize this account history, draft a renewal email, attach the three relevant docs" use cases inside the enterprise. It's also less terrifying to a CISO than a full agent runtime. The category confusion only becomes a problem when the product is sold as the latter and bought against the latter's evaluation criteria.
Where it stops being a workflow runner is the moment a Skill chains to another Skill and Adaptive Reasoning starts picking between them at runtime based on intermediate state. That's agent-runtime territory. Whether the audit trail keeps up at that boundary is the question I'd ask in the demo, not the question the demo will surface.
Adaptive Reasoning: what it actually does
Adaptive Reasoning is a planner. It takes a query, decomposes it into retrieval steps and Skill invocations, runs them in sequence (sometimes in parallel — the launch post is ambiguous on concurrency semantics), and synthesizes the result. The planner's choices are exposed in the response so the user can see what was decided.
The honest part of the pitch: this works well for the queries Glean has always been good at. "What did the team decide about the Q3 pricing model?" gets a better answer when the planner can route across Slack, Confluence, and Salesforce, run a Skill that summarizes the latest commit thread, and stitch the citations together. The transparency in the response — showing which sources fired — is a meaningful upgrade over the older "here's an answer, trust me" pattern.
The less-honest part: a planner that's exposed in the UI is not the same artifact as a planner that's exposed in the audit log, and the difference matters for any team whose compliance posture requires structured evidence. I've asked three Glean customers in the week since the launch whether they can export, as a structured record, the full plan that Adaptive Reasoning generated for a given query — including which Skills were considered and rejected, which tools were available at the moment of planning, which policy version was in force, and which sources got de-prioritized by the planner before the model ever saw them. Two said "not that I'm aware of." One said "I think you can get it through the API but I haven't tried." None said yes. That's not damning — it's a new product launched seven days ago — but it's the gap to size in your evaluation, not after you've already deployed against it.
For a corpus-search assistant, "I think you can get it through the API" is a fine answer. For an enterprise AI coworker doing write actions on the user's behalf, it isn't.
Approval controls: governance or guardrail theater?
Approval controls are the feature most likely to be misread in a demo. The pitch: name a Skill, mark it as requiring approval, and any execution against a write-capable connector will pause and route to a designated approver before completing.
This is real governance investment from Glean. The pre-launch posture was "let it run, log it, hope for the best." The post-launch posture is "block the call, queue the approval, audit the decision." That's not nothing, and CISOs who pushed back on Glean's agent ambitions in late 2025 are going to find this materially more comfortable.
Where it's guardrail theater, if you're not careful: the approval gate is enforced inside the Glean application surface, not at a protocol layer beneath it. If a Skill invokes a Glean-managed connector, the gate fires. If an admin authorizes the same Skill to call an external MCP server through an approved tool catalog, the launch post doesn't make clear whether the gate enforcement is consistent across both paths. I asked. I got two different answers from two different sales engineers in the same week. That ambiguity is the answer until the docs say otherwise.
The sharper question, the one to bring to the procurement call: can the approver, after the fact, query "show me every Skill execution that was gated, who approved it, what policy version was attached, and what the tool catalog looked like at that moment"? If yes, the gate is a control. If the answer is "we have an approvals dashboard," that's not the same artifact.
Where this fits in the broader agent landscape
Now the section where I'm comparing Glean to platforms my employer competes with, so read accordingly.
MCP (Model Context Protocol, moved to the Linux Foundation on December 9, 2025) is the protocol layer agent platforms speak when they want to be interoperable with the rest of the stack. RFC 8707 resource indicators became mandatory on March 15, 2026. As of May 27, 2026, Glean Skills do not register as MCP servers in the catalog-and-discovery sense, and Glean's external tool-call story leans on Glean-managed adapters rather than MCP-native tool registration. That's a choice, not a flaw. It's the choice that determines whether a Glean Skill is portable across runtimes or anchored to Glean.
A2A (the Agent-to-Agent protocol, the JSON-RPC tasks/send and tasks/get flow served behind /.well-known/agent.json) is the standard for one agent platform to delegate work to another. Glean does not currently expose its Skills as A2A endpoints. If you want a Microsoft Copilot agent or an AgentCore Runtime workflow to invoke a Glean Skill, you're doing it through Glean's REST API, not through the spec-compliant agent-to-agent path. Again, a choice, not a flaw — but it shapes integration cost.
AgentCore Runtime (AWS, Gateway GA October 13, 2025) and Azure AI Foundry (GA June 16, 2025) are the hyperscaler-side answers to "where do agents run." They're agent runtimes in the strict sense: goal-oriented loops, tool registration discipline, per-call observability at the protocol layer. Glean is not in that category and isn't trying to be. Glean's category is "knowledge-grounded application surface that calls into agents and tools," which is a different product.
Jarvis Registry (ours, disclosure stands) treats Skills-equivalents — we call them registered agents and MCP-exposed tools — as catalog entries with versioning, ownership, lifecycle state, and a per-call audit emitted at the gateway underneath. The closest reading of Glean Skills as a comparable artifact is "if every Skill were a registered agent in our catalog and every Adaptive Reasoning decision were logged with a policy snapshot at the moment of the call." Glean has shipped the application surface. The catalog discipline underneath, as of May 27, isn't visible from the launch post or the docs we have.
For the deeper architectural read on what an orchestration layer above the registry-and-gateway pair has to enforce, the Agent Orchestration Layer field guide covers the five factors that decide whether a workflow surface is enterprise-ready. The registry-vs-gateway breakdown covers the split between the catalog plane and the data plane — and why a vendor that ships only one is a vendor whose audit story still has gaps.
What this means for your stack
If you're a Glean customer evaluating whether to roll out Skills broadly: yes, do it, for the read-mostly knowledge-grounded workflows. Voice and the shared Library are genuine quality-of-life upgrades. Adaptive Reasoning improves the answer quality for cross-source queries in a way that's measurable on the first day.
If you're a Glean customer evaluating whether Skills replaces your agent platform project: probably not, depending on what your agent platform is supposed to do. If the project is "give knowledge workers an assistant that can run Skills against our corpus and occasionally write back through a connector," Skills with approval controls is a credible answer at the per-seat price (Glean's pricing in 2026 sits at roughly $45-50 base plus a $15 agentic add-on, with a 100-seat floor and total three-year TCO landing around $350K-480K for a 500-seat deployment — see Glean pricing alternatives for the full teardown). If the project is "give multiple teams autonomous and supervised agents that span the enterprise, with per-call audit, MCP-native tool registration, and protocol-level interop with Copilot and AgentCore," Skills isn't that and isn't trying to be.
If you're not a Glean customer and you're evaluating Glean against an agent platform: evaluate the architectures at the layer where they actually differ. Glean is best in class at corpus-grounded retrieval with a workflow surface on top. The agent-platform vendors are best in class at runtime governance with corpus integration on top. Those are different products solving overlapping problems, and the right choice depends on which problem dominates your roadmap.
The relabel question I opened with — is this an agent runtime, a workflow runner, or a marketing relabel? — has a three-part answer. It's a workflow runner. It's not a marketing relabel; the engineering is real. And it's not an agent runtime, but it doesn't need to be to be useful. The risk is buying it as one.
For the broader competitive shortlist, the Glean pricing and alternatives comparison covers Microsoft 365 Copilot, AgentCore-anchored builds, Jarvis Registry, and the federated options, with the price math each one carries.
FAQ
Is Glean Skills an MCP server? No. As of the May 20 launch, Skills are application-level workflow primitives invoked through Glean's own surface and API. They do not register as MCP servers and do not enforce RFC 8707 resource indicators at the protocol layer. If MCP-native tool registration matters for your stack, that's a gap to size against your roadmap rather than a deal-breaker on its own.
Does Adaptive Reasoning produce an auditable plan trace? The plan is exposed in the UI for the user. Whether the full plan — including rejected options, policy version, and the moment-in-time tool catalog — is exportable as a structured record varies by what you can get out of the API. Ask for an example export in the procurement call before you assume yes.
Are approval controls enough for a CISO sign-off on agent write actions? For Glean-managed connectors with the approval gate on, the posture is materially stronger than pre-May 2026. The two open questions are consistency across external tool calls (Glean's response was uneven the week of launch) and whether the approval audit is queryable per-call with the policy snapshot attached. Both are reasonable procurement asks.
How does this compare to AWS AgentCore Runtime or Azure AI Foundry? Different category. AgentCore and Foundry are agent runtimes where goals drive reasoning loops with tool registration discipline. Glean Skills is a workflow runner with planner-driven retrieval on top of the Glean corpus. If you need both, you're integrating them; if you need to pick one, the choice depends on whether corpus-grounded knowledge work or general-purpose agent execution is the dominant use case.
Is there a price uplift for Skills? The Skills surface itself is part of the platform; the agentic add-on at roughly $15 per seat covers the higher-end execution patterns including approval controls and the Adaptive Reasoning chains that span Skills. Confirm the SKU mapping in your specific quote — the line between "included" and "agentic add-on" moved twice between the briefing version and the GA pricing sheet for at least one customer I talked to.
About ASCENDING
ASCENDING is an AWS Advanced Consulting Partner founded in 2018 in Fairfax, Virginia. We build Jarvis AI — a governance-first, MCP-native agent platform — and publish this site as an independent industry resource. When a piece compares Jarvis to a competitor, the disclosure stays on the page.