How to build Glean agents with clear review points

Build Glean agents by giving each one a focused job, then connecting a trigger, tool steps, and a response in Agent Builder↗ (opens in a new tab). Open Agents → Create agent → Start from Scratch to configure the workflow yourself, or choose Build with Natural Language to draft it from a description. Test the inputs and results before treating the workflow as ready for others. fenbs can keep the agreed boundaries and review findings available when another assistant helps improve it.

A good first agent does something you can inspect, such as summarizing one approved document for a weekly review. A request to “handle the weekly review” contains too many hidden choices. Define the input, the allowed work, the expected output, and the person who will decide whether it is ready.

What should you decide before opening Agent Builder?

Write a one-sentence goal and a stopping point. For example: “Read the supplied process document and draft a checklist for the operations lead to review.” The word draft matters. It tells everyone that a generated checklist is awaiting judgment and should not silently become the approved process.

• Input: the document or information the user must supply.
• Allowed work: the reading, comparison, or drafting the agent may perform.
• Output: the format and evidence a reviewer needs to inspect.
• Boundary: what the agent must not infer, change, or send.
• Review: who accepts the result and what happens when information is missing.

Confirm that your organization has enabled Glean Agents, that you can create agents, and that you can access Agent Library. These are the prerequisites in Glean’s creation guide↗ (opens in a new tab). If you cannot reach the builder, ask the administrator about those requirements instead of looking for an undocumented workaround or assuming a particular subscription explains it.

How do you connect the first inputs and steps?

Use the simple Input form → Read document → Respond pattern described in the first-agent guide↗ (opens in a new tab). It keeps the source and output visible while you learn the builder. Start with a document you are permitted to use and whose contents you can check yourself.

1. Open Agents, select Create agent, and choose Start from Scratch.
2. Configure an Input form to collect the information the workflow needs.
3. Add a Read document step that uses the supplied document input.
4. Add a Respond step with a narrow instruction, such as drafting a checklist and identifying missing information.
5. Use Preview and turn on Debug mode to inspect the actual inputs and outputs before adding more work.

Check the handoff between steps. Did the reading step receive the intended source? Did the response use the material that was actually read? If a result looks wrong, find the first step where the expected and actual information differ. Rewriting the final prompt cannot repair an incorrect input you never noticed.

How should native action inputs and permissions be reviewed?

For each action you add, write down the intended destination, the information it may use, and the result you expect. Match those expectations to the step’s configured inputs. A natural-language goal is not a substitute for checking what the tool will receive. Prefer a read or draft during early testing when that is enough to establish the workflow.

For example, a proposed task-creation action needs a reviewed destination and title, not merely “create the right task.” Have a person inspect those details before a run that would change an external system. This is a review practice you set for the workflow; do not assume that adding a sentence creates a particular approval control in the builder.

Glean’s remote MCP documentation↗ (opens in a new tab) says downstream permissions still apply. It also distinguishes published MCP tools, which work in Plan and execute steps and autonomous agents, from individually selected single steps. Agent MCP support is beta. If outside tools are involved, use the separate Glean MCP connection guide to settle the setup before extending the workflow.

What should you test in Preview?

Run more than the easiest example. Use an ordinary input, an incomplete one, an irrelevant document, and a source with a statement that is easy to misread. Decide beforehand what a useful result looks like for each. A reviewer should be able to distinguish an acceptable refusal from an unhelpful answer.

Save the exact input, expected behavior, actual outcome, and review result. When you change a step, rerun the examples most likely to be affected. This creates a small set of repeatable checks instead of relying on the memory of a convincing demonstration. AI at work covers the same habit for other practical AI workflows.

When is the agent ready to publish?

Treat publishing as a distinct, permission-dependent action. Glean’s draft and version guide↗ (opens in a new tab) distinguishes drafts, ready-to-publish versions, and published versions, including approval where required. Do not assume Save always makes every change immediately live. Check the actual state and the person responsible for approval in your organization.

Before that decision, give the reviewer a short change summary, the tests run, known limitations, and any actions the workflow can take. Review access and sharing as well as the core steps. A correct response does not establish that the right people can use the agent or that its external actions have an appropriate scope.

Version history is useful for the workflow, but the same Glean guide says it does not version permissions, sharing settings, or publishing options. Restoring a workflow is not undoing an operation already performed elsewhere. If testing changed an external system, inspect and handle that change in the system itself.

What should you keep between improvements?

Keep the agreed purpose, source references, action boundaries, test examples, and the result of the latest review. Add the next improvement as a separate task. Save one sentence explaining why an important boundary exists; otherwise the next session may remove it while trying to make the agent more helpful.

Finding and checking enterprise information is a different job from building the workflow. Use Glean enterprise search when that is the part you need to improve. For work that continues across assistants, a saved handoff in fenbs can preserve what passed review and what remains unfinished without copying every run.

How to keep Glean agent review findings with fenbs?

Keep the limits people agreed, the tests you ran, and what still needs review. Save that record so you can carry on from the same point on any device and in another connected AI.

1. Create a free account.
2. Add a task for the agent you are building. Write what it should do, what it must leave alone, and who will review it.
3. Connect Glean to fenbs using Integrations, with your administrator setting up and publishing the permitted tools first.
4. Save the test examples and checked outcomes. Save the rules a person agreed so the next AI knows what to follow.
5. Save where you left off and the next review, so you can continue on any device with another connected AI.

fenbs keeps the work and human decisions between sessions. It does not publish a Glean agent, replace your organization’s approval process, or reverse actions in another service. If the workflow is a disposable experiment with no continuing work, a separate record may be unnecessary.