AI Agent Settings

An AI agent is any AI that works with your rules for someone: the Rule Repository's own AI Assistant and AI Rule Editor, an AI client connected through the MCP server, or an automated agent of your own. Agents work through the same permission checks as people, and some limits apply to every agent whatever its permissions say. The agent settings let you narrow what agents may do further: how many tests they may run, whether their test runs appear in the user activity, and whether they may read the live records behind your data sources.

Why you need them. Running a test can call your application's own methods, and a data source returns real records from your systems (customers, accounts, employees). The defaults suit most applications; change them when your tests are expensive, when your data sources hold personal data, or when your own automation needs to run many tests.

What Every Agent Is Held To

These rules are fixed and cannot be changed by any setting or permission:

An agent never makes a version live, takes one offline, approves, declines or deletes anything.
Everything an agent saves (a rule, a version, a draft, a test) is saved with approval requested, never live.
An agent changes an existing rule only after the person confirms it.
A test that would call a production method for real needs the person's yes, every time. (A service, or an agent acting with no person behind it, runs such a test on its permission alone: there is no one to ask.)
An agent never reads users' notes.
Permission 112 (reading every user's AI conversations) is never an agent's.

Who Counts as an Agent

RR knows three kinds of users, set on every request (see Users and the Acting User):

Kind	How it is set	Limits used
A person, with an AI acting for them	`CurrentUserType = UserType.User` and `CurrentAgentId` / `CurrentAgentName` set (the AI Assistant sets these itself; the MCP server sets them from `McpCaller.AgentId`)	`AgentTestLimits`
An AI agent acting on its own	`CurrentUserType = UserType.Agent` (`McpUserType.Agent` over MCP)	`AgentTestLimits`
A service: your own automation	`CurrentUserType = UserType.Service` (`McpUserType.Service` over MCP)	`ServiceTestLimits`

Setting Them

The settings are one object, AgentSettings, set on the request's configuration. Null means the defaults.

using CodeEffects.Rule.Repository;

public static class AgentDefaults
{
	public static AgentSettings For() => new AgentSettings
	{
		AgentTestLimits = new TestRunLimits { TestsPerCall = 5, TestsPerHour = 50, TestsAtOnce = 1 },
		ServiceTestLimits = new TestRunLimits { TestsPerCall = 50, TestsPerHour = 1000, TestsAtOnce = 4 },
		RecordAgentTestRuns = true,
		AgentDataSourceItems = true,
		// Agents may read product names, never customers
		DataSourceItemFilter = (dataSourceName, itemId, itemLabel) => dataSourceName != "Customers"
	};
}

Set it in both places agents work, so they follow the same rules:

The RR endpoint, for the AI Assistant and the AI Rule Editor: config.Agents = AgentDefaults.For(); on the Configuration you build per request.
The MCP server, in WithRepository: repository.Configure = (caller, config) => config.Agents = AgentDefaults.For(); (see Setting Up the MCP Server).

The Settings

Setting	Default	What it decides
`AgentTestLimits`	10 per call, 100 per hour, 2 at once	How many saved tests an agent may run, counted per agent
`ServiceTestLimits`	10 per call, 100 per hour, 2 at once	The same, for a service, counted per service
`RecordAgentTestRuns`	true	Whether an agent's run of saved tests writes a test-run entry to the user activity, naming the tests and their outcomes. The outcomes are recorded on the tests either way
`AgentDataSourceItems`	true	Whether agents may read data source items: the live records a data source's method returns, needed to turn "Gold tier" into the id a rule stores. Off, agents never see them, and a value from a data source is left for a person to pick in RR
`DataSourceItemFilter`	null (every item)	Narrows which data sources and items agents may read when `AgentDataSourceItems` is on. Called with the data source's name, the item's id and its label; return false to hide the item

TestRunLimits:

Setting	Default	What it decides
`TestsPerCall`	10	The most saved tests one call may run
`TestsPerHour`	100	The most saved tests one caller may run in any hour, counting tests, not calls
`TestsAtOnce`	2	The most tests one caller may have running at once

An agent over a limit gets an error saying when it may try again, and agents are told to ask the person before running many tests. The limits are counted in each server's memory: with several servers behind a load balancer, the real limit is the setting times the number of servers. People's own batch runs in RR are not limited by these settings.

Where Your Data Can Reach an Agent

When you connect AI to your rules, the definitions of your sources and rules are shared with it by design. Real data can reach an agent only in these places, each under your control:

Where	What it can hold	Controlled by
Data source items	Live records from your own data source methods	`AgentDataSourceItems` and `DataSourceItemFilter`
Recorded evaluations, and tests made from them	Real production inputs and outcomes	Permissions 80 (view evaluations) and 81 (save one as a test)
Test values and value templates	Made up, or copied from evaluations	Permission 60 (view tests)
Test runs that call production methods	What your real methods return	Permission 66 and the person's confirmation
Values inside rules	An id or a data source label a rule uses	Not limited: it is part of the rule

Ask on Stack Overflow - Yes, it's still active
Ask in GitHub Discussions

p102

l107

l097 --