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 [1], their 2026 enterprise search evaluation [2], the Futurum coverage of the $200M ARR milestone [3], 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 [1]. Skills is the new workflow primitive — Glean's own wording is "personalized packages of reusable execution logic" — 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. Glean describes it as "a new default mode that automatically decides how much thinking to apply to each query," matching the model to the task [1]. 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. Glean's own phrasing in the launch post is narrower than "approval" implies — write tools surface "a clear preview before any action is taken so you understand what data is targeted to be changed" [1].
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 as a founding project of the new Agentic AI Foundation [10]) is the protocol layer agent platforms speak when they want to be interoperable with the rest of the stack, and it now ships dated, single-current revisions [9]. RFC 8707 resource indicators are required by the MCP authorization spec [7][8]. 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. Glean's own documentation is the evidence on both halves: the platform is an MCP server and gateway, exposing Search, Chat, Read Document, Code Search and People plus external servers through one endpoint [4], but the page that covers exposing Glean units of work as MCP tools is scoped to agents, never mentions Skills, and rules out any agent with write tools or human-in-the-loop steps because "MCP hosts typically expect read-only operations" [5]. 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-card.json) is the standard for one agent platform to delegate work to another. The specification defines JSON-RPC 2.0, gRPC and HTTP/REST bindings over a common set of operations — send a message, get a task, list, cancel, subscribe [11] — and publishes the Agent Card at a well-known URI following RFC 8615 [12]. 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 [13]) 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.
Laid out against the dimensions that actually separate the two categories, the picture looks like this as of May 27, 2026:
| Dimension | Glean Skills as shipped | A protocol-layer agent runtime |
|---|---|---|
| Tool registration discipline | Glean-managed adapters; Skills do not register as MCP servers in the catalog-and-discovery sense | MCP-native tool registration, with RFC 8707 resource indicators mandatory since March 15, 2026 |
| Per-call audit trail | Planner output exposed in the UI; no customer I asked could confirm a structured export of the full plan | Per-call observability emitted at the protocol layer, beneath the application surface |
| Approval gate enforcement | Enforced inside the Glean application surface; consistency across external tool calls was answered two different ways in the same week | Enforced at the gateway, so the path a call takes does not change whether the gate fires |
| A2A protocol compliance | No A2A endpoints; a Copilot or AgentCore workflow reaches a Skill through Glean's REST API | JSON-RPC tasks/send and tasks/get served behind /.well-known/agent-card.json |
| Catalog discipline | Not visible from the launch post or the docs available at the time of writing | Catalog entries carrying versioning, ownership, and lifecycle state |
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 [14] — 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 — Glean's published MCP security model rests on OAuth 2.0 with dynamic client registration and per-document Knowledge Graph permissions, cites RFC 8252, and never mentions RFC 8707 or token-audience validation [6]. 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.
References
- Glean's May 2026 launch post, last updated 5 May 2026, defines Skills as "personalized packages of reusable execution logic," Adaptive Reasoning as "a new default mode that automatically decides how much thinking to apply to each query," write-tool behavior as "Every execution surfaces a clear preview before any action is taken so you understand what data is targeted to be changed," real-time voice conversations, and the Library as "a shared, searchable home for every AI-generated output" — the post uses "coworker" throughout and "agent" only once, in "open Agent Skills standard" — Glean (2026): https://www.glean.com/blog/may-2026-launch
- Glean's 2026 enterprise-search evaluation, last updated 12 February 2026, grades on correctness ("factual accuracy and logical validity relative to the query") and completeness, reports human graders choosing Glean 1.9x more often than ChatGPT and 1.6x more often than Claude, and states the platform maintains "100+ connectors" with "multiple specialized indexes over your data, tuned to the query type" — Glean (2026): https://www.glean.com/blog/enterprise-search-evaluation-2026
- Independent analyst coverage reports Glean doubling ARR to $200M and argues that "Copilot benefits from native integration with the productivity layer that most knowledge workers already occupy" while Glean's vendor neutrality across LLMs, hyperscalers and data sources is "a credible structural differentiator" — Futurum Group (2026): https://futurumgroup.com/insights/glean-doubles-arr-to-200m-can-its-knowledge-graph-beat-copilot/
- Glean documents itself as both an MCP server and an MCP gateway, exposing Search, Chat, Read Document, Code Search and People as platform tools, agents "surfaced as tools that hosts can invoke," and external MCP servers routed through the gateway — Glean (2026): https://docs.glean.com/administration/platform/mcp/about
- Glean's "Agents as tools" documentation covers exposing agents through the MCP server — "Glean Agents can be exposed as tools through Glean MCP server, allowing them to be invoked directly from MCP host applications" — never mentions Skills, and excludes any agent with write tools or human-in-the-loop steps because "MCP hosts typically expect read-only operations" — Glean (2026): https://docs.glean.com/administration/platform/mcp/agents-as-tools
- Glean's MCP security documentation covers OAuth 2.0 with Dynamic Client Registration, per-document and per-object permission enforcement, tenant-resident indexing and query processing, admin audit logs for MCP and OAuth configuration changes, and 7-day access / 180-day refresh token lifetimes — it cites RFC 8252 and makes no reference to RFC 8707 resource indicators or token-audience validation — Glean (2026): https://docs.glean.com/administration/platform/mcp/security
- RFC 8707 defines the OAuth
resourceparameter so a client can explicitly signal which protected resource a token is for, enabling audience-restricted tokens that cannot be reused across services — IETF (2020): https://www.rfc-editor.org/rfc/rfc8707.html - The MCP authorization specification requires clients to implement RFC 8707 and send
resourcein both authorization and token requests, requires servers to validate that tokens were issued specifically for them, and states "MCP servers MUST NOT accept or transit any other tokens" — Model Context Protocol (2025): https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization - MCP versions the protocol with
YYYY-MM-DDidentifiers marking the last backwards-incompatible change, maintains one current revision at a time, and negotiates version per request rather than per session — Model Context Protocol (2026): https://modelcontextprotocol.io/specification/versioning - The Linux Foundation announced the Agentic AI Foundation on 9 December 2025 with MCP, goose and AGENTS.md as founding contributions and AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as platinum members — The Linux Foundation (2025): https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
- The A2A specification defines "an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems," with JSON-RPC 2.0, gRPC and HTTP/REST bindings over SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask and SubscribeToTask — A2A Project (2026): https://a2a-protocol.org/latest/specification/
- A2A agent discovery publishes the Agent Card at the well-known URI
https://{agent-server-domain}/.well-known/agent-card.json, following RFC 8615, retrieved by an HTTP GET that returns the agent's capabilities, authentication requirements and skills — A2A Project (2026): https://a2a-protocol.org/latest/topics/agent-discovery/ - Amazon Bedrock AgentCore reached general availability on 13 October 2025 across Runtime, Memory, Gateway, Identity and Observability, with Runtime supporting eight-hour execution windows, session isolation and the A2A protocol, and Gateway connecting to existing MCP servers — Amazon Web Services (2025): https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available/
- A third-party teardown reports roughly $50 per user per month for Glean, a ~100-seat minimum at about $60,000 annually, a paid POC up to $70,000, and a $350,000–$480,000 combined annual cost — secondary reporting from a Glean competitor, assembled from buyer-submitted data and labelled as estimates, not vendor-published pricing — GoSearch (2026): https://www.gosearch.ai/blog/glean-pricing-explained/