Skip to main content
Mole Agent helps from the first chat, but trust in it rests on two things: knowing what it can reach, and seeing it be right. Roll it out in steps: limit the data and the actions first, teach it the environment, then hand it routine work, and watch cost and quality as usage grows.

​
Decide what reaches the model

Mole Agent sends the conversation to the model provider, the results of its tools included. Settle these controls with the people responsible for data protection before the first chat. Enter the prices of each provider as well, so usage shows the cost.

​
Advise first, change later

Keep chats in Advice mode, the recommended mode, while people learn what Mole Agent proposes: it queries data and suggests changes without making them. Move to Execute with approval once its proposals hold up; a change then asks first or goes to approval, as the execution mode of the tool says. See Execution modes.
  • Keep Allow Bypass permissions off in the Approval policy of shared agent profiles.
  • Keep the default policy by risk, from L0 automatic to L4 disabled. With Configure tool policy under Tools & capabilities, make Production stricter than the other environments, for example single approval for L1 changes.
  • Approving requires agent.approve, which Owner and Admin hold. Give it through a custom role to the people who would make such a change themselves.
  • New tools of an MCP server stay off until someone turns them on. Turn on the read-only ones first, with Enable all read-only tools. Skills and MCP tools never widen the policy.

​
Teach it the environment

An answer is only as good as what Mole Agent knows about the services.
  • Write the organization’s knowledge in MOLE.md, or run /init to have it written: the services and their owners, the environments, the important streams and dashboards, and where the runbooks are. Point to longer files with @path, such as runbooks/checkout.md. See Knowledge and memory.
  • Let each team keep its own knowledge, which its team chats read, and handle incidents in team chats, so the people on call read and continue the same investigation.
  • Turn on Distill memories after chats to keep what chats learn, and look through Memory from time to time to delete what is wrong.
  • Turn procedures that repeat into skills, kept in a skill repository with Synchronize every day, so a change to a procedure is reviewed like code.

​
Hand it routine work

Automations let Mole Agent work with nobody in the chat. Start from the templates: An automation runs as the person who saved it last, with that person’s permissions. When that person leaves, its runs fail until someone saves it again, so record an owner for each shared automation. Nobody can answer during a run: a tool that needs a confirmation is not run, and the run is marked Needs someone. Use automations to read and report, and leave changes to chats.

​
Keep cost in view

  • Set the daily budget in Mole Agent → Settings → Usage, from the instance default [agent].daily_token_budget or as a Custom limit. Size it from the usage by source of the last 30 days, with room for incident storms: once the budget is used up, automatic root cause analysis waits for the next day, log inspections fail, and LLM functions fail their step.
  • Keep Stop calling the model, the default. Choose Answer and only warn only when chats must keep answering past the budget.
  • For detail, query the internal stream _agent_model_traces in Logs: the tokens, latency, and cost of each call by origin, model, and user_id. See Usage and budget.

​
Measure quality and improve it

  • Ask people to rate answers. A Not helpful with its reason shows what to fix.
  • Add an evaluator that scores a sample of team chats and RCAs, and review the low scores on the Quality tab every week.
  • Run /insight as a weekly automation. It names at most five changes worth making, such as a knowledge file to write.
  • Set the prompt check to Check, and refuse when worse, so a new organization prompt cannot make answers worse. See Check a prompt before it becomes the default.

​
Acceptance criteria

  • The data policy allows the model provider, and the provider has prices.
  • The default profile reads only the environments, services, and streams it needs, without networking.
  • No shared profile allows Bypass permissions, and the tool policy of Production is set on purpose.
  • MOLE.md names the services, their owners, and their runbooks, and each on-call team has its own knowledge.
  • An Incident analysis automation writes RCAs for error and critical incidents.
  • The daily budget leaves room for automatic analysis, and someone reviews the Quality tab each week.
Last modified on October 26, 2026