General Discussions

The method that didn't survive the quarter

If you work in enterprise analytics, this pattern is familiar. A leader asks for an account health readout across the top accounts: churn signals, open escalations, which accounts have gone quiet. The team produced it last quarter, with the same sources and the same logic. This quarter, they rebuild it from scratch, because what survived was mostly a static snapshot of the answer (last quarter's deck or sheet already gone stale), and the method did not.

Not because the data changed. The method lived in no one's head but the analyst who built it the first time, and that analyst has since moved teams, or is busy elsewhere, or simply doesn't remember the dozen small decisions that made the first version trustworthy. Even when someone deliberately saves a prompt into a template library, the saved prompt rarely carries the hard parts: how to define the account set correctly, what sources to trust, how much evidence to review, and what caveats to disclose.

The analysis was good. The analytical method was flawed.

That pattern (correct output, lost method) is the gap I keep running into in enterprise analytics. It's the gap Glean's emerging programmability layer is built to close.

The real problem isn't the answer, it's the method

Most enterprise analytics conversations today focus on the answer layer. Can the model generate the right query? Can it pull from the right source? Can it explain the trend?

Those are real questions, but they aren't the hardest one. The hardest problem is repeatability. The same question comes back next quarter, asked by a different analyst, with a different prompt, against slightly different scope rules. The organization quietly re-derives a method it already solved. Each derivation costs time and introduces variance. And because the method lives in the prompt, and the prompt lives in a chat session, it evaporates.

Recent work at Glean has strengthened two important layers of enterprise analytics: making outputs durable, and making context governed. The missing piece is making the analytical method itself reusable. What matters here is not just generating an answer once. It is turning a good analytical method into something the organization can reuse, inspect, and trust.

Three layers that make the method repeatable and reliable

That reuse rests on three reinforcing layers…

. In Glean's product, Skills (Skills documentation) are packaged, governable instructions an admin or analyst can publish so agents load the right playbook—not the everyday English sense of "skill." They let an agent inherit the source selection rules, filter logic, citation standards, and scope disclosures that a strong analyst would normally carry in their head. Skills also keep the method modular and composable (small reusable pieces rather than one mammoth instruction block), so the agent loads the right analytical guidance only when it's needed rather than all at once.

The Agent File System (AFS) is where the method runs

. Some work shouldn't happen inside a model's context window: parsing files, running aggregations, reading through hundreds of call transcripts, joining one system to another. That work is more reliable when done deterministically in a sandboxed compute environment than approximated in tokens. AFS is that environment, and because its file storage persists across a session, results accumulate instead of resetting with every reply. The analytical answer lands as a durable file, not a paragraph in a chat bubble.

Programmatic Tool Calling (PTC) is the governed bridge to enterprise tools

. Instead of one expensive model round-trip per tool call, the agent writes code that calls Salesforce, Gong, Jira, and Glean Search through the same MCP-backed tool connectors, permissions, and access controls a person would hit in chat. Privileged operations stay host-mediated, user-scoped, permission-aware, and logged. The result is governed access to enterprise systems, with every call auditable.

Skills are the playbook. AFS is the workspace. PTC is the governed bridge.

Skills: institutional analytical memory as code

The clearest way to understand Skills is to look at one. Glean has an analytics skill, an enterprise customer analytics playbook, that captures exactly the method behind the scene I opened with. It defines a simple planning rubric (which sources to use, which entities to scope to, what time window applies, and how deep the analysis should go), and it sets standards for what must be cited and what a scope note should disclose.

Two principles from that skill are worth restating, because they show how a rigorous method differs from a clever prompt. First, source coverage is explicit: if a required source is omitted, the run should be treated as incomplete, not merely lighter. Second, filtering precisely matters: returning the documents that belong to an account is a different operation from returning the ones that merely mention it, and for analytics that difference is everything. A concrete rule in the same spirit might read: for Gong, read transcript bodies for the scoped accounts—do not stop at call titles or keyword-style snippets alone.

The skill even carries its own efficiency discipline—often split into smaller reusable fragments rather than one monolithic block. It defines a small caching wrapper that every tool call routes through, so a repeated or interrupted run returns completed results instead of re-querying the same systems. That wrapper isn't something the platform hands the agent for free; it's a few lines the skill itself carries and the agent reproduces. Which is precisely the point: the method, down to its efficiency habits, is the asset.

Those aren't model capabilities. They're operational rules an analyst learns over time, rules that normally live only in someone's head, or nowhere at all. That's what a Skill is: institutional analytical memory as code. Not a prompt, not a one-off instruction, but a governed, versioned, shareable package that carries the method the way a senior analyst briefs a junior one. Versioned here means the Skill is stored as an artifact the org can update, diff, and roll back—like code or policy—rather than a one-off chat thread that cannot be branched or audited the same way.

Governance matters as much as capability. Skills can be scoped to users, teams, or the whole company; governed through role-based sharing and admin publishing; and promoted from team-level use to organization-wide deployment. A prompt tells one analyst what to do today. A Skill turns an analyst's method into a governed standard that other agents can reuse consistently.

What it looks like when the layers run together

Picture a RevOps analyst asking: "What are the top 10 Enterprise accounts showing churn signals this quarter, with supporting evidence from Gong and Zendesk?"

Without programmability, this is hard to answer reliably. "Enterprise" can mean different things in different systems. For sources like Gong, reliable analysis often requires reading transcript content directly rather than relying on lighter keyword-style retrieval alone. And counting themes across dozens of accounts is exactly the kind of task where a model guessing is risky and a deterministic loop is not.

With the full stack, the path is clean. The analytics skill loads and gives the agent its planning framework and filter rules. The agent resolves the Enterprise account set from Salesforce (structured and exhaustive, not a keyword search), filters Gong and Zendesk to those specific accounts, and reads the underlying records. The aggregation runs deterministically, so the output is computed rather than guessed, and it lands as a file with full citations and a scope note.

Every tool call in that chain is logged and bounded by the same access controls as chat. The result is reproducible when the method lives in a Skill and is run by a Glean Agent configured to use it: run it next quarter, same method, consistent output. Not every analysis needs all of this, and simple questions can stay simple. But when the question is hard, the dataset is large, and the answer has to be trusted the same way next quarter, the difference between a prompt and a Skill becomes the difference between a one-time delivery and a lasting capability.

Many of these workflows can be operationalized without standing up a bespoke pipeline or waiting on a larger data-platform project. The work is capturing the analytical method once (the sources, the filters, the coverage rules, the citations) and packaging it as a Skill that other agents can reuse.

This builds on a larger theme. Earlier in this series, Rob Barker showed how to make analytical outputs durable, and Henry Tang showed how to make context governed. The programmability layer adds another move: making the capability itself compound, so the organization gets a little smarter every time a Skill is written, shared, and refined.

The deliverable isn't the chat reply. It's the reusable capability the org keeps.

Make the output durable. Make the context governed. Make the capability programmable.

The Programmable Analyst: how Glean turns one-off analysis into reusable, governed capability

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Tools

Help

Welcome to the Gleaniverse. Empowering work with AI. Connected by knowledge. Growing together. Search Where would you like to start? Join the discussions.

Glean Community

Gleaniverse Community

Copyright

Terms of Service

Privacy Policy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via community@glean.com if you need support.

Pending Approval

Login to the Glean Community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community and get the best experience, complete your profile.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Glean Community.

Thanks for your interest in joining Glean Community. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via community@glean.com for any questions.