Procedure Library
A curated catalog of step-by-step workflows your agents have already proved out — promoted by an admin, version-controlled, and visible to the right people. Procedures make agents more reliable on repeat tasks without making the system prompt explode.
Where procedures come from
Two sources:
- Auto-extracted: after a successful multi-tool agent run, ZenSearch summarizes the workflow it just executed into a structured procedure (name, trigger pattern, ordered steps, tools used, common pitfalls, verification criteria). These start as drafts in the team's library.
- Hand-authored: admins can write procedures from scratch in the dashboard for workflows the agent hasn't naturally discovered.
In both cases, a procedure is just a piece of structured guidance the agent can pull when it recognizes the task — not a hard-coded script.
How agents use them
Future agent runs see only a short list of procedure names + trigger patterns in the system prompt (~50 tokens each, regardless of how many procedures the team has). When the agent recognizes that a stored procedure matches the current task, it pulls the full body on demand. This keeps the system prompt cacheable and cheap, even as the library grows to hundreds of procedures.
The procedure body is guidance, not a script — the agent still adapts to the specific request, available tools, and runtime context.
Curation in the dashboard
Open Procedures in the team admin dashboard. You can:
- Browse the library, grouped by procedure name. Each entry shows its current canonical version and full version history.
- Create a new draft.
- Edit any draft in place.
- Publish: snapshots the current draft into a new immutable version and marks it canonical. Future agent runs prefer canonical versions.
- Unpublish: removes the canonical mark from a version (the body is still preserved in history).
- Rollback: marks an earlier version as canonical and supersedes everything later.
- Preview: see exactly what the agent will see in its system prompt for a given procedure.
Versions are immutable once published — rollback never destroys history, and you can always inspect any prior canonical body.
Visibility scopes
Each procedure has a visibility scope that controls who sees it:
| Scope | Who sees it |
|---|---|
team | Everyone in the team. The default. |
org | Anyone in the team who has an org chart row (i.e., a known org-graph identity). |
role:<role> | Only members whose org chart job role exactly matches. Roles are IC, Manager, Director, VP, Exec. |
Role-scoped procedures are useful when a workflow is appropriate for managers but would surprise an IC, or vice versa. If a member has no org chart row, they fall back to seeing only team-scoped procedures — automation/cron runs without a user identity behave the same way.
Best practices
- Let the auto-extractor populate drafts. Review and publish only the workflows you actually want canonical — most drafts won't pass the bar, and that's fine.
- Keep procedure bodies short. The agent already has the system prompt and the user request; procedures should add the non-obvious steps and pitfalls, not restate the obvious.
- Use role scopes sparingly. Most teams are best served by
team-scoped procedures with role gating handled at the action layer (approvals, RBAC) rather than at procedure visibility. - Roll back rather than delete. Publishing a fresh version is cheap; deleting history hurts auditability.