REDA AI Monsoon 2026 · v1.15000 13 Aug 2026

REDA AI — Monsoon 2026 (v1.15000)

This release is mostly about what an agent costs to run. Two new per-agent settings let you trade a little quality for a materially cheaper agent, or keep an agent's context warm between messages so a paused conversation is not re-charged from scratch. Four more settings let you cap a single agent's budget without changing anything org-wide. Alongside that, an unattended API agent can now be allowed to bypass object and field permissions — without ever seeing a record it could not see before — emails can carry your own fields on the record they create, and a fault that could silently discard incident-log entries is fixed.

Getting this version

Upgrade the REDA AI package in your org the same way you install any managed package. To confirm you have it, open Setup → Installed Packages and check that the Version Number column next to REDA AI reads 1.15000 or higher. Everything below refers to that version; if the column still shows 1.14 or 1.14001, the upgrade has not completed and the settings described here will not exist yet.

This release also carries everything that shipped in patch 1.14001. If you upgraded straight from 1.14, those changes are new to you too, and they are described here alongside the rest.

What the upgrade does not do for you

A Salesforce managed-package upgrade is deliberately conservative: it will not overwrite configuration you have changed. That protects your org, but it means an administrator has work to do by hand in every org that upgrades. Skip it and the new settings exist but nobody can see or use them.

Every new field in this release

All nine live on the Agent Definition record — the record where you configure one agent. The Section column is where the field sits on REDA's own layout; put it in the same place on yours so the two match.

What an administrator must do, per org

1. Put the fields on your layout. Go to Setup → Object Manager → REDAAI Agent Definition → Page Layouts, open the layout your team actually uses, drag each field from the palette into the section named in the table above, and click Save. If you never customised this layout, the fields are already there and you can skip this step — but check rather than assume.

2. Give your users access to the fields. The two packaged permission sets already carry all nine — REDAAI Admin can edit them and REDAAI User can read them. That is enough if your users are assigned those sets. If your org uses its own permission sets or profiles instead — most do — you must add the fields there yourself: Setup → Permission Sets → your set → Object Settings → REDAAI Agent Definition → Edit, then tick Read (and Edit for administrators) against each field.

3. Re-apply your tool-iteration limit per agent. The org-wide Max Tool Iterations setting is no longer used and its card has been removed from the admin console. If you had changed it from the default, set Max Tool Iterations on each agent that needs a non-default value. Agents you leave blank behave as 6, which is the value the org-wide setting shipped with.

4. Leave Execution Context alone unless you know you need it. The default, User, is correct for every agent a person talks to. Only change it for an unattended API agent, and read the section below first.

What's new

Two new ways to cut what an agent costs to run

Processing Tier chooses the processing profile the agent uses. Standard is the default and is what your agents use today. Efficient does the same work for roughly 30% fewer credits, with slightly lower performance on long multi-step reasoning. It is a good fit for high-volume, straightforward agents — answering routine questions, looking records up, simple data capture — and a poor fit for an agent doing complex analysis. Leaving the field blank behaves exactly as Standard, so no existing agent changes until you opt in.

Enhanced Caching keeps the agent's stable context — its instructions and the tools it can use — warm for one hour instead of five minutes. This matters because real conversations pause: someone asks a question, gets pulled away, and comes back ten minutes later. Without it, that pause throws the cached context away and the next message is charged as though the conversation had just started. With it, the conversation resumes cheaply.

Per-agent budget limits that override the org-wide defaults

Four settings that used to be org-wide can now be set on a single agent: Max Output Tokens (how long a reply may be), History Token Budget (how much earlier conversation is re-sent each turn), Max Continuation Depth and Web Search Max Uses. Leave any of them blank and the agent keeps using the org-wide value, so nothing changes until you deliberately set one.

The one with the biggest effect on credits is History Token Budget. Every turn re-sends recent conversation so the agent remembers what was said; the larger that budget, the more it costs per message. Trimming it on a chatty, high-volume agent is usually the single largest saving available — but trim too far and the agent starts forgetting earlier context, so lower it in steps and watch the quality.

Let an unattended API agent bypass object and field permissions

An agent on the API channel runs on its own — triggered by another system rather than by a person — so it acts as an integration or automation user rather than as the person who asked. That user needs permission to every object and field the agent might touch, and because a REDA AI agent decides what to look at from context, you cannot always know that list in advance. The result is an agent that works in testing and then fails on a record nobody predicted.

Execution Context solves that. Set it to System on an API-channel agent and its tools stop enforcing object and field permissions.

Three things bound it, and they are worth knowing before you use it:

• It only works on the API channel. Set it on an agent on any other channel and it is ignored. Agents people talk to run as that person, where their own permissions are exactly the right boundary; agents on your public website run as a guest, where bypassing permissions would be unsafe.
• Only an administrator can turn it on. It is a field on the Agent Definition record, editable through the REDAAI Admin permission set. The agent cannot switch it on for itself, and no instruction you write in a prompt can change it.
• Every elevated action is recorded. Each time a tool runs with permissions bypassed, an entry is written to the incident log naming the tool, the target object and the user it ran as — so you can always answer "what did this agent do with elevated access?"

Leave it as User unless you are running an unattended API agent that is failing on permissions. It is not a performance setting and there is no benefit to enabling it speculatively.

Stamp your own fields on the emails an agent sends

When an agent sends an email, Salesforce records it against the related record. You can now have the agent write your own custom fields onto that email record at the same time — most commonly to mark which agent sent it, so you can report on volume by agent later. The agent's tool now also returns the email record's Id.

Two things to set up first:

1. Create the custom field on the Email Message object (Setup → Object Manager → Email Message → Fields & Relationships → New).
2. Grant the agent's user access to it. If the field is not visible to the user the agent runs as, the value simply will not save — the email still sends and nothing appears to go wrong. This is the most common reason a stamp does not appear.

Only your own custom fields can be written this way. Standard fields such as the subject or recipient are deliberately refused, because changing them would break the threading Salesforce uses to match replies back to the original message.

Limit how many tools and how many steps an agent uses per turn

Shipped in patch 1.14001; new to you if you upgraded from 1.14.

Max Tools caps how many tools an agent offers per turn. Every tool an agent can reach is described to it on every message, so a long list costs credits on each turn whether the tools are used or not. The default has changed: agents were previously capped at 20 and blank now behaves as 25, so an agent with more than 20 eligible tools will now load up to five more per turn — slightly more capable, slightly more expensive.

Max Tool Iterations caps how many steps the agent may take within one turn when it is chaining tools together. Blank behaves as 6. See step 3 in What an administrator must do — the org-wide setting this replaces is no longer read.

What's fixed

Incident logging no longer loses entries

Incidents are written in batches. Previously, a single malformed entry could cause the whole batch to be discarded — including valid records of genuine production errors — leaving no log entry and sending no notification. An error could therefore disappear entirely because of an unrelated informational message written at the same moment. Entries are now saved individually, a rejected one is itself recorded, and valid incidents always survive. No action is needed.

The assistant no longer describes an action you have not confirmed

When an agent proposes an action that needs your confirmation, it now reports that action as not yet carried out until you confirm it. Previously the assistant could describe the action in the past tense — telling you an email had been sent — while it was still waiting for approval, and the claim survived even if you then cancelled.

Confirmation cards now show the details for custom actions

A confirmation card for an action built by your own team could appear blank, leaving you approving something with nothing to read. Those cards now list the values the action will use.

Smaller fixes

• Links to records inside an alert are now clickable, instead of showing a raw code with a record Id in it.
• Sentences in the assistant's replies no longer run together without a break.
• (Patch 1.14001) The record-retrieval tool told the agent it could ask for up to 50 fields when the real limit was 25; it now states 25, so the agent stops asking for more than it can get.
• (Patch 1.14001) The All — Inactive Agents list view showed active agents. Its filter is corrected.
• (Patch 1.14001) Five error messages that always appeared in English now appear in the reader's language.

What's improved

Custom tools can tell which channel they are running in

If your team has built its own tools for REDA AI, they now receive the channel the agent is running on. A tool can use that to behave correctly when it runs unattended rather than for a signed-in person — which is what the platform requires when automation acts on its own. Existing custom tools are unaffected and need no change; the information is simply available to those that want it.

How to check the upgrade actually worked

1. Confirm the version. Setup → Installed Packages → REDA AI shows 1.15000 or higher.
2. Open any agent. Go to the REDA AI app → Agent Definitions → open one. You should see Processing Tier and Enhanced Caching in the Performance & Cost Controls section, and Execution Context just below Channel. If you cannot see them, the layout or field-access step above has not been done.
3. Check a non-administrator can see them too. This is the step most often skipped. Log in as — or ask — someone with an ordinary user permission set, and confirm the same fields appear for them.
4. Change nothing yet. Every new setting defaults to today's behaviour, so a correct upgrade looks like no change at all until you deliberately opt in.

Frequently asked questions

Do I have to change anything for my agents to keep working?
No. Every new setting is blank by default and blank means "carry on as before". The one thing to check is the org-wide Max Tool Iterations setting, which is no longer read — see step 3 above.

Will Efficient make my agent worse?
It is slightly less capable on long, multi-step reasoning. For agents that answer questions, look records up or capture simple data, most teams see no difference. Change one agent, use it for a few days, and compare — the setting is per agent, so you can test without committing.

Should I turn Enhanced Caching on everywhere?
Turn it on for agents people chat with, where pauses happen. Leave it off for autonomous agents that run start to finish without waiting — there is no pause for it to help with. It never costs you more either way.

Does Execution Context let an agent see more data?
No. It never widens which records an agent can see — record sharing is always enforced. It only affects which fields and objects it may read or write on records it could already reach, and only on the API channel.

Why did the version jump from 1.14 to 1.15000?
Only the format changed. The minor number now carries the release and the patch together: 1.15000 is release 15, patch 000. Patches on it will be 1.15001 and up, and the next release will be 1.16000.