> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roll out Mole Agent with guardrails

> Decide what reaches the model, start with advice before changes, teach Mole Agent the environment, hand it routine work, and keep cost and quality in view.

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.

| Control | Where | Recommendation |
| - | - | - |
| Model provider | **Mole Agent → Settings → Models & reasoning** | A provider that the data policy allows. An OpenAI-compatible endpoint can be a model hosted in the company network. |
| Data scope | **Mole Agent → Settings → Data access** | Only the environments, services, and streams that investigations need. |
| Networking | **Mole Agent → Settings → Network policy** | Off, as in new profiles, unless a tool needs it. |
| Personal data | [Field masking](https://docs.molesignal.com/en-US/settings/data-security.md#field-masking) and [regex patterns](https://docs.molesignal.com/en-US/settings/data-security.md#regex-patterns) | Field masking applies to the queries of Mole Agent as to those of people, and **Redact on intake** removes text before it is stored. |

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](https://docs.molesignal.com/en-US/agent#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](https://docs.molesignal.com/en-US/agent#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](https://docs.molesignal.com/en-US/agent#skills), kept in a
  [skill repository](https://docs.molesignal.com/en-US/agent#skill-repositories) with **Synchronize every day**, so a change to a
  procedure is reviewed like code.

## Hand it routine work

[Automations](https://docs.molesignal.com/en-US/automations.md) let Mole Agent work with nobody in the chat. Start from the templates:

| Template | Use |
| - | - |
| **Incident analysis** | Writes the likely root cause, with its evidence, as the RCA of error and critical incidents, so the first responder starts from it. |
| **Daily health check** | Says what needs attention, every weekday morning. |
| **Weekly alert noise review** | Lists rules to tune. See [Make production alerts actionable](https://docs.molesignal.com/en-US/best-practices/actionable-alerts.md). |
| **Weekly on-call load** | Sums up pages per person and at night. See [Set up on-call and notifications](https://docs.molesignal.com/en-US/best-practices/on-call-setup.md). |
| **Change impact check** | Runs when CI calls it after a deploy. See [Verify a release](https://docs.molesignal.com/en-US/best-practices/release-verification.md). |

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](https://docs.molesignal.com/en-US/agent#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](https://docs.molesignal.com/en-US/quality.md#evaluators) 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](https://docs.molesignal.com/en-US/quality.md#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.

## Related guides

* [Mole Agent](https://docs.molesignal.com/en-US/agent)
* [Automations](https://docs.molesignal.com/en-US/automations.md)
* [Quality](https://docs.molesignal.com/en-US/quality.md)
* [Tool catalog and execution](https://docs.molesignal.com/en-US/tools.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.