Choose Which Tools Run Live

In this step you decide which of Atlas's tools may run for real while you test it. Atlas has a tool that only reads, a tool that asks another agent, two documentation tools, and a tool that hands a conversation to a human. A test must never change real data by accident, so Qlar blocks or pretends most of them by default. You review them once on the Tool Policy page, and then you see how a single scenario can let one tool run for real. It takes about fifteen minutes.

Before this page, Test Tools Safely with Mocks gave get_project_status a scripted answer. Mocks always win, so this page matters for everything you did not mock: the default of "blocked" or "live" that applies when no mock answers.

AI is involved in every run: Atlas writes its answers and decides when to call a tool. The Tool Policy page itself has no AI in it. The same setting gives the same decision every time, but what Atlas does in a scenario can still differ from run to run.

Before you start

• Atlas has its tools in place, as in Connect Your API, Connect an MCP Server, Work With Other Agents and Hand Off to a Human.
• You have the Owner or Contributor role on the agent.
• You have read Test Tools Safely with Mocks, so you know what Blocked, Simulated and Live mean for a tool call.
• Tool Policy shows in the sidebar under Simulation only when the feature is switched on for your CMS.

Step 1: Sort Atlas's tools into read and write

A tool that only reads is harmless to repeat. A tool that writes, sends or hands over can change something real. Before you touch the page, sort Atlas's tools:

The rule of thumb: let tools that only read run live, if the data they read is safe to read in a test. Leave tools that write or send blocked, and give them a mock.

Step 2: Open the Tool Policy page

1. In the sidebar, open Simulation and click Tool Policy.
2. Read the line under the title: "What each tool does in simulations when no mock answers the call. Applies to every scenario of this agent, on both Draft and Published."
3. Read the card How a tool call is decided in a simulation. It shows five chips in the order Qlar asks them, and the first one with an answer wins: Step mocks, Scenario mocks, Scenario's Allow live, This policy and Built-in default.

This page only controls the fourth chip, This policy. It applies to every scenario of Atlas, on both Draft and Published. You set it once.

Below the card, Atlas's tools sit in three groups:

• Effect unknown ("4 tools · 4 not reviewed", Default: Blocked). Qlar cannot tell from the outside what a custom API, an MCP server or another agent does, so get_project_status (under Custom API), resolve-library-id and query-docs (under MCP · context7_docs, with Turn all on and Turn all off) and Ledger (under A2A, with an A2A badge) are all here.
• Reads data ("0 tools", Default: Live). Atlas has no tool that Qlar knows only reads, so it is empty.
• Not set on this page ("6 tools"). The built-in escalate_conversation is here under Simulated success, with no switch. The tools under Always runs are here too.

Step 3: Decide for each tool

1. Above the groups, the filters read All tools, Not reviewed (4) and Unsaved (0), next to a Search tools box. Click Not reviewed (4) to show only the tools nobody has decided about. These are the tools Atlas cannot use in a simulation right now.

2. Find get_project_status and switch Run live on. A tool with a GET request shows no warning, because reading is harmless.
3. Do the same for resolve-library-id and query-docs, if you are happy for them to reach the public server. Their names do not suggest they change data, so no warning appears either.

4. Leave Ledger's Run live switch off. If you switch it on, a warning says "Ledger is outside Qlar. Whatever it does with the request happens for real." That is why it stays off.

A tool you leave off stays blocked and keeps its Not reviewed chip. Both mean the same for a run: the call is not made. The tools you switched on also keep the Not reviewed chip until you save, as the next step shows. The group header now reads "4 tools · 4 not reviewed · 3 unsaved", and the bar at the bottom says "3 unsaved changes" with Cancel and Save.

Tip: a row you changed is marked, and counts under Unsaved (n). Nothing is applied until you save.

Step 4: Save the policy

1. Click Save in the bar at the bottom of the page.
2. A dialog titled "Save n changes to the tool policy?" opens. It says "Every scenario of Atlas uses these settings for calls that no mock answers, starting with the next run. Runs already queued keep the old settings."
3. Read the list. Every change is one line, for example "get_project_status: Not reviewed (Blocked) → Live". Because tools are going live, the dialog adds "Tools set to Live call the real system with real credentials in every simulation run, so what they do is not simulated."

4. Click Save policy.

The policy only changes what simulations do. It does not change the live Atlas, so you do not need to publish anything. To drop changes without saving, click Cancel in the bar.

Step 5: See the effect in a scenario

1. Open Simulation → Scenarios and open a scenario that does not mock get_project_status, for example one you wrote in Build Your First Test Suite.
2. In the setup pane, under Agent Tools, click Review all tools. The panel What the agent’s tools will do opens.
3. Once the policy is saved, get_project_status reads Live · Tool policy. Ledger reads Blocked · Not reviewed in the tool policy, because you left its switch alone.

The panel opens with the title What the agent’s tools will do, a line such as "Atlas · runs against the published version" and an Edit tool policy → link. The tabs Whole scenario and Step 1 switch between the whole scenario and one step, and a line such as "5 action tools · 0 mocked · 4 will be blocked" sums it up, with the chips Live, Simulated and Blocked and the filter All and Needs attention.

The screenshot below was taken before the policy was saved, so it shows the unsaved state: every tool you have not yet saved a decision for reads Blocked · Not reviewed in the tool policy (the chips count 3 Live, 1 Simulated and 4 Blocked; the Simulated one is escalate_conversation, which is never blocked), with the note "Nobody has reviewed this tool in the tool policy yet, so calls are blocked.", a Review in Tool Policy link and the buttons Mock it and Allow live…. The Live · Tool policy chip appears only after you click Save policy in step 4.

After a run, the same call shows the source chip Tool policy in the result, under Tool calls. In a scenario that mocks the tool, such as the one from the previous page, the call still shows Mocked: mocks win over this page.

Step 6: Let one write tool run live in one scenario

Sometimes a scenario has to prove that the real thing works. For Atlas, that is an escalation: when someone asks for an exception to an approval limit that SOP-FIN-007 does not allow, the Operations duty supervisor must really be notified. By default escalate_conversation is Simulated success: Atlas behaves as if it escalated, and no escalation is created. That is right for most tests.

To prove the real thing, allow it live in that one scenario:

1. Create a scenario named Exception to an approval limit in the Kirana Projects folder, the same way as in Build Your First Test Suite. Its User Message asks for an exception on a USD 1.2 million project because the Regional Director is on leave and the vendor deadline is tomorrow. The Expected Response is that Atlas says it cannot approve the exception and hands it to a person. Save it, then reopen it.
2. Under Agent Tools, click Review all tools, and find escalate_conversation.
3. Click Allow live…. A confirmation says "Real data will change." and, for an escalation tool, that supervisors will be notified. Confirm.

4. The row now reads Live, with "Takes effect after you save" under it. Click Save on the scenario. A run uses the saved scenario.
5. Run the scenario once, on Draft, to prove the escalation. Click Run on its card and, under Run against, choose Draft. A run on Draft sends the escalation to the draft escalation inbox, and the confirmation says so: "Escalations from this run go to the draft escalation inbox." (This note shows only when you run one scenario from its card or its form. Run all and Run selected do not show it.) Atlas must have a draft copy for this: if Draft is greyed out, save a change on Atlas first, as in Test Changes Before You Publish.

Do not run this scenario on Published while Allow live is on. A run on Published sends the escalation to the real supervisor, who is notified for a test.

To take it back, click Remove on the same row, and save. Do this as soon as you have proved the escalation: while Allow live… is on, every run of that scenario on Published notifies a real supervisor. That includes a run of the whole folder: its confirmation has the Run against choice but gives no escalation note, so check the version yourself before you start it.

Who can use Allow live…

Only organisation Owners and Admins can use Allow live… in a scenario. The Run live switches on the Tool Policy page (step 3) are different: anyone with the Owner or Contributor role on the agent can change them, and they apply to every scenario. For Allow live…, what you see depends on your role:

• If you are an Owner or Admin of your organisation, the button Allow live… is enabled and you can do steps 3 and 4 yourself.
• If you are not, the button is visible but greyed out. Hover over it to read "Only organisation Owners and Admins can allow a tool to run live". A lock note at the bottom of the panel says the same. Ask an Owner or Admin of your organisation to open the scenario and allow the tool, or use a mock instead: anyone with the Owner or Contributor role on the agent can use Mock it.

Use Allow live… sparingly. It makes real calls, with real credentials, in every run of that scenario. Run such a scenario on Draft, as in step 5.

Check the result

You made it if:

• Effect unknown has no tool left under Not reviewed that you meant to decide about, and the footer says "No unsaved changes".
• In a scenario, get_project_status reads Live · Tool policy, and Ledger reads Blocked · Not reviewed in the tool policy.
• In a result, a call to get_project_status that no mock answered shows the outcome Live with the source chip Tool policy.

If you see something else:

• The Agent Tools panel still says Blocked · Not reviewed in the tool policy. You have not saved the policy yet, or you did not switch that tool.
• The call shows Mocked. That is expected. A mock set always wins over Tool Policy.
• Your save was refused. Someone else saved first. The page says "The policy changed since you opened it. Reload it?" Click Reload, then make your changes again.
• Allow live… is greyed out. You are not an organisation Owner or Admin. See the list under step 6. The Run live switches on the Tool Policy page are not affected.

Next steps

• Next in this step: Test Changes Before You Publish.
• The same feature in more depth: Tool Policy and Tools in Simulations.
• Field-by-field reference: Tool Policy and Scenarios.
• Previous in this step: Test Tools Safely with Mocks.