Glean 推出程式碼建置智能體功能，支援 Claude Code、Cursor 和 Codex

Glean introduced headless agent building on October 21, 2026, a generally available feature that lets developers create, test, and publish agents as code from coding environments such as Claude Code, Cursor, and Codex, with the finished agents running on Glean’s managed runtime.

The company announced the feature in a blog post authored by Kelly Huang, a product marketing manager at Glean. Glean said agents authored in code run on the same foundation as agents built in its visual agent builder, including the company’s knowledge graph, permissioned access across more than 275 enterprise sources, and its audit trail, with Glean’s enterprise permissions, security, and governance intact. Customers who prefer natural language or a visual, low-code canvas for configuring agents without writing code can continue to use Glean’s agent builder, the company said.

In the announcement, Glean said that as agents take on more consequential work, teams need to build and manage them with the rigor they apply to software: version control, testing, collaboration, deployment, and security. The company said certain workflows also call for more deterministic control over the steps, guardrails, and integrations an agent uses, and that authoring agents as code provides that control while letting developers apply familiar testing, review, and rollback practices. Glean said the feature gives developers the flexibility of a code-first workflow without requiring them to build the enterprise and context foundation themselves.

Defining, Testing, and Publishing Agents as Files

Under the new workflow, the Glean plugin creates an agent inside the developer’s coding workspace as a set of files: a spec.yaml file holding the agent’s configuration and an instructions.md file holding its behavior. The files can be kept alongside a team’s code, and the agent can be extended with skills or subagents when needed.

Developers can run the agent with representative inputs directly from the coding environment, review its output, and run evaluations, using the results to refine the agent’s instructions and configuration. Builders can monitor a run’s progress and inspect its output from the same environment. Changes can be reviewed in the coding assistant or through pull requests in Git, and a change that does not work as expected can be rolled back.

When an agent is ready, the developer publishes it to Glean rather than to a separate runtime, and can share it with the team. Glean said the published agent runs on its managed runtime with the same knowledge graph, permissions across more than 275 enterprise sources, and audit trail as agents created in Glean. Published agents can be shared, managed, or disabled by admins and builders in the Glean console. The feature supports Auto mode agents; Workflow mode agents still need to be built in Glean’s agent builder.

Plugin Setup and Agent File Structure

Glean’s documentation lays out a setup sequence: install the Glean plugin for the coding environment, authenticate, confirm the local agent directory, build the agent, test it with representative inputs, and save or publish it and share its generated link.

Installation differs by environment. In Claude Code, the developer adds the gleanwork/claude-plugins marketplace, installs the glean@glean-plugins plugin, and reloads plugins. In Codex, installation runs through terminal commands that add the gleanwork/codex-plugins marketplace and the glean@glean-codex-plugins plugin. In Cursor, the developer opens Cursor Settings, searches the Marketplace for Glean, and selects Add to Cursor. After installation, the developer connects the plugin to the company’s Glean instance by entering a work email and completing Glean OAuth in the browser. If setup fails with a message that company policy blocks the plugin, the documentation directs the user to ask a Glean administrator to enable it.

The documentation states that the headless builder works only through the plugin’s /glean_run chat command, typed as $glean_run in Codex, and that there is no Glean MCP server for this flow. It warns users not to substitute a Glean MCP server or any of its tools for the command, and not to reuse beta marketplace or plugin names.

By default, the builder stores each agent in its own folder under.glean/agents/ in the current workspace. The folder contains spec.yaml, which carries the agent’s id; instructions.md; and optional skills/ and subagents/ folders. The documentation warns against editing the id field in spec.yaml because it links the folder to the live agent in Glean. A published agent’s URL takes the form https://<your-domain>.glean.com/chat/agents/<agent-id>, with the agent id matching the id field at the top of spec.yaml.

The documentation’s walkthrough has the developer create a question-and-answer agent that summarizes new support issues from Slack and Zendesk, run it with a representative input, and save the created agent.

A Customer Support Example

Glean’s announcement walks through a customer support engineer who wants to catch urgent escalations early. Working in Codex, the engineer asks Glean to create an agent that summarizes support conversations from Slack and Intercom, then refines the agent’s instructions, tests the agent against a real support scenario, and runs an evaluation to identify where it can improve. When the results look right, the engineer publishes the agent to Glean and shares it with the team. Glean described the result as a reusable agent for a recurring support task, created in the tools the engineer already uses and backed by the company’s enterprise context and controls.

The company said the headless building capabilities are generally available, and that developers can use Claude Code, Codex, Cursor, and Git to build, test, version, and publish governed Glean agents.