Build Fast, Ship Smart: A Cleaner Model for Glean Agent Deployments
Every technology leader deploying AI agents inside their organization eventually runs into the same wall. Business teams want faster deployment. Risk and compliance want tighter controls. And somewhere in the middle, the people actually building agents are either moving too fast for anyone's comfort or waiting too long for approvals that slow everything to a crawl.
The instinct is to add more process. More sign-offs. More review gates. But that instinct usually makes things worse. The real answer isn't more process applied uniformly to every change — it's structural separation between the act of building, the act of testing, and the act of releasing.
What follows is not a native promotion workflow built into Glean. It is a practical operating model built on top of Glean's existing controls: drafts, preview, version history, duplication, sharing permissions, and moderator or admin oversight. That distinction matters because good governance in Glean comes from how you structure ownership and release practices around the product, not from a built-in multi-stage deployment system.
The Tension Every AI Leader Recognizes
The dual mandate at play: enable builders to experiment and iterate quickly, while protecting production environments from unreviewed or untested changes reaching real users at scale.
These two goals feel like opposites, but they aren't. They just require different environments. A common approach companies take is trying to manage both goals inside the same object, at the same time, with the same set of controls. That's where discipline breaks down because the structure doesn't support it.
The One Product Behavior That Changes Everything
Before designing any deployment model for AI agents, there is one platform behavior worth understanding clearly because it shapes everything that follows.
In Glean, changes are auto-saved as a draft while a builder works. Those draft edits do not affect the live agent until the builder clicks Save. Once Save is clicked, the current draft replaces the published version.
That distinction matters. A draft is useful for iteration. It is not, by itself, a release approval mechanism. If someone has edit access to a production agent and clicks Save, the production agent changes immediately.
The practical consequence is that you cannot use draft states as your pre-production gate. Development, UAT, and production are three separate operating lanes, usually represented by separate agents or duplicated release candidates.
What Version History Can and Can't Do
Version history is valuable insurance, but it is post-change insurance. It helps you restore a prior workflow state after something has gone live. It does not stop a bad change from becoming live in the first place, and it does not version permissions, sharing settings, or publishing options.
These require their own operational discipline, separate from prompt tuning and workflow iteration.
The Three-Lane Model
The cleanest governance structure in Glean is not a built-in promotion pipeline. It is an operating model you can apply on top of the product and manage intentionally.
The Author Lane — Optimized for Speed
This is where builders live. They create, iterate, test edge cases, and troubleshoot. They use preview to validate behavior privately before saving. They use drafts to iterate without committing. They use version history to recover from missteps.
Builders should use Preview aggressively because it gives them a private way to validate behavior, troubleshoot responses, and test edge cases before saving or sharing more broadly.
The key design principle here is that builders own development agents, not production agents. Development agents are explicitly named as such (a suffix like -DEV removes ambiguity) and are never the agents that broader business users depend on. This gives builders genuine freedom to move fast, because the blast radius of any mistake is contained.
The UAT Lane — Optimized for Confidence
User Acceptance Testing is the stage where a small, designated group of real users validates that an agent is ready for broader release. It's more of a business fit check rather than a technical QA pass. Does the output meet the intended need? Are instructions followed consistently? Are there failure modes that only appear with realistic inputs from real users?
The UAT lane uses a separate copy of the agent — duplicated from the development candidate and shared only with the designated test group. This gives testers a stable release candidate to evaluate without touching the live production version at all.
Scale UAT to match the reach of the agent. For a small internal team tool, three to five testers may be sufficient. For a departmental agent, five to twelve testers across representative roles is more appropriate. For anything with enterprise reach, testers should come from multiple functions beyond the builder's own team.
The Production Lane — Optimized for Stability
Production agents should not be treated as open build space.
They should be controlled by a small review group made up of the people in your deployment who have the authority to manage sharing and release safely. Typically these are Owners of the agent, Agent Moderators, or Admins depending on how your environment is configured.
Broader sharing should happen only after UAT findings have been reviewed and a deliberate release decision has been made.
The production lane is where governance is most visible to end users, and where the cost of a mistake is highest. Keeping production ownership centralized is the single most important structural decision in this model.
The Group Structure That Makes It Operational
Four groups translate this model into something that can actually be administered.
| Group | Role | Access |
|---|---|---|
| Agent Authors | Build and iterate in DEV | Editor or Owner on DEV agents only |
| UAT Testers | Validate business fit and output quality | Viewer on UAT agents by default |
| Publishers / Reviewers | Control release and broad sharing | Owner, Agent Moderator, or Admin-controlled access on production agents |
| Production Consumers | Run approved agents | Viewer on production agents |
One nuance matters here: general agent creation rights and per-agent edit rights are not the same thing. In Glean, a user can collaborate on a specific agent if they are granted Editor or Owner access to that agent, even if they are not broadly allowed to create new agents on their own.
On the admin side, the default posture should keep broad distribution narrow. In practice, that means limiting default-member sharing beyond individual teammates and requiring elevated roles or explicit governance decisions before agents are shared to departments, identity provider groups, or the whole company.
This model scales best when it is mapped to identity provider groups, but teams should note the product limits. Today, Glean supports these patterns with Microsoft 365 / Azure AD groups and Google Groups. Okta group-based role assignment is not currently supported, and only one identity provider source can be active at a time for agent group sharing.
Five Anti-Patterns That Break This Model
Even with the right structure in place, a few common mistakes undermine it.
Using one agent for everything. When the same agent object serves as build space, test environment, and production system, there's no meaningful separation. Any save is a production change.
Too many editors on production. Editors can modify agents. If production edit access is distributed broadly, the approval process has no teeth. Reserve production edit capability for the publishing group.
Broad sharing before ownership is defined. Sharing an agent widely before establishing who owns it, who reviews changes, who monitors performance, and who can roll it back is a governance gap waiting to become an incident.
Ignoring version history as a rollback mechanism. Version history exists for a reason. Teams that don't build rollback into their operating model discover its value at the worst possible moment.
Treating permissions as part of prompt tuning. Because permissions and publishing settings aren't versioned, they need separate operational discipline. Access configuration is an administrative control, not a byproduct of workflow iteration.
How to Get Started Without Overbuilding
The model described here doesn't require a large implementation effort. Most organizations can stand it up in four phases.
Start by defining the structure: which groups exist, who gets which roles, and what the default member permission baseline looks like. Then establish naming and lane conventions so DEV, UAT, and production agents are unambiguous to anyone who encounters them in the library.
From there, pilot with two or three meaningful agents rather than trying to operationalize the entire agent library at once. Starting small and iterating quickly is almost always faster than designing a comprehensive framework before anyone has used it in practice.
Finally, measure. Do not stop at "is the agent live?" Track whether it is being adopted. Glean's insights can help you monitor active agent users, shared agents, run volume, department-level adoption, top agents, top users, and feedback trends. That gives leaders a way to decide which agents should be expanded, revised, contained, or retired.
The goal of this model isn't to slow AI agent deployment down. It's to make fast deployment sustainable by giving builders the room they need to experiment and leaders the confidence that what reaches production has been deliberately reviewed and tested. Speed and control, in the right structure, reinforce each other.
Oida specializes in ROI-proven Glean implementations for mid-market companies. If you want help designing a governance model for your agent deployment, schedule a discovery call.