Skip to main content
A Procedure is a small, tested program that does one recurring connector workflow for an agent: fetch data, filter it, compute something, return a compact result. The agent calls it as a single tool instead of making the same dozen connector calls, or rewriting the same code, on every run. Procedures fit tasks an agent does again and again, such as a scheduled report, a triage pass or a weekly digest. The agent keeps the judgment, the writing and any high-impact actions in its own turn; the Procedure does the mechanical fetching and computing.
Procedures are rolling out. If you don’t see a Procedures tab on your agents or Settings → Procedure reviews, ask your Runlayer contact to turn them on for your workspace. Self-hosted deployments also need the agent runtime (enable_runlayer_agentcore_runtime = true, see agent runtime), because Procedures are validated and run there. enable_runlayer_agents is not required.

​
How an agent uses a Procedure

Each live Procedure linked to an agent appears on every run as a tool named procedure_<slug>, next to the agent’s normal connector tools. Code mode is not required. The agent passes the Procedure’s inputs, the Procedure runs its connector calls in the sandbox, and the agent gets one result back.
  • Same access as the agent. A Procedure can only call tools the agent can already call directly. If the agent is missing a grant a Procedure needs, Runlayer doesn’t serve that Procedure to it.
  • Same policies and audit trail. Every connector call a Procedure makes goes through the Runlayer gateway like any other tool call, so your policies, scanners and audit logs apply.
  • Bounded. Each call has a time limit of 15 minutes, and a Procedure fails loudly on a connector error instead of returning partial data as if it were complete.

​
Where Procedures come from

Procedures start as drafts. A draft never runs on real work until it goes live (see Testing and going live). Drafts come from three places:
  • The Procedure Optimizer. On an agent’s Procedures tab, click Analyze. The Procedure Optimizer reads the agent’s recent successful runs, finds workflows it repeats, and drafts Procedures for them. It doesn’t change the agent or approve anything.
  • The agent itself. An agent with Self-improving agents and Code mode on can save code that already worked in a run as a draft for its own recurring task, where your workspace has agent-saved Procedures enabled. Saving the same Procedure again proposes its next version; the live version keeps serving until the new one passes.
  • Builders. People with the Manage procedures permission can write and update drafts, for example from an AI client through the Runlayer MCP.

​
Testing and going live

Runlayer measures every draft before it can serve a real run:
  1. Replay. Runlayer replays a real run of the agent’s task with the draft. Read actions are real; write actions are simulated, so nothing changes in your tools.
  2. Compare. The replay’s duration, tokens and cost are compared with the agent’s own recent real runs of the same task (the median of up to three from the last 30 days, on the agent’s current configuration). If there are none, Runlayer runs a control replay without the draft instead.
  3. Go live or wait for review. By default, a draft goes live when every benchmark run succeeds and it costs no more than the baseline. It waits for a reviewer instead when the Procedure is shared or another agent uses it, so code other agents depend on is never swapped out without a person looking at it. Your workspace can also require a review for every version; ask your Runlayer contact.
Drafts with evidence runs are benchmarked automatically. A draft a person edited by hand has no runs to replay, so it waits for a manual benchmark; the review panel says so.

​
Reviewing Procedures

People with Manage procedures review drafts in two places:
  • Settings → Procedure reviews lists every draft waiting for a person across the workspace, with the organization’s savings over the last 30 days.
  • An agent’s Procedures tab shows the savings Procedures brought that agent over the last 30 days, the Procedures linked to it, and the drafts it proposed.
Open a draft to inspect its code, input and output schemas, the connectors and tools it calls, and its benchmark. Approve makes it available to the agent; sending feedback returns the draft to its author with your notes.

​
Permissions

Managing Procedures takes the manage_procedures role permission (Manage procedures), which the Super Admin and IT Admin roles have by default. It lets a person see an agent’s Procedures tab and Settings → Procedure reviews, write drafts, and approve, link and share Procedures. Without it, a person can’t see Procedures at all, but their agents still use the live Procedures linked to them. The use_procedures permission is a legacy entry and grants nothing on its own. See Access control resources for how role permissions and organization policies combine.

​
Limits

  • 100 versions per Procedure.
  • 1,000 Procedures per organization (self-hosted deployments can change this).
  • 10 Procedures an agent saved for itself, per agent.

​
Procedures, skills and memory