Context Field Optimizer
AI funding and usage
AI included uses REDA credits. Bring your own AI uses your organisation’s provider account, billed directly by that provider. The licence selects one funding model for the organisation. In either model, REDA AI governs configured tools and actions in Salesforce. Set up your licence and AI accounts.
In customer-account mode, the selected model determines which Deep Reasoning levels and capabilities are available. Review the AI Account selector’s supported levels and warnings; do not assume every provider supports the same combination. Admin AI tools and document processing use the organisation default connection. Configure the default and test the workflow.
What the Optimizer Configures
Each Context Field record in REDA AI controls how a specific agent reads a specific object. The Optimizer recommends values for four fields on that record:
| Field | Purpose |
|---|---|
| Field API Names | Comma-separated list of fields the agent will see for this object, in priority order. |
| Max Fields | Hard cap (1–25) on how many fields are loaded at runtime — useful when an object has hundreds of fields and only a few are ever relevant. |
| Include Related Names | When on, lookup-relationship Name fields are auto-included alongside their Id fields, so the agent sees “Owner: Jane Smith” rather than just an Id. |
| Context Description | Free-text description of what this context is for. Helps the model understand what kind of object it’s looking at and what to do with it. |
See Adding Context Fields for the full lifecycle of a Context Field record.
How the Optimizer Works
-
Open the record
The Optimizer is launched from any Context Field record — usually right after creating a new one for a new agent/object pairing.
-
Add an instruction
An optional short instruction lets you steer the optimizer with org-specific guidance — e.g. focus on operations rather than financials, or favour fewer fields to keep credits low. The box accepts up to 5,000 characters, but only the first 1,000 reach the model — keep the instruction short and put the most important guidance first.
-
Platform composes request
The platform sends the model a structured request containing the agent definition, the agent’s custom prompts, the tools assigned to the agent, the channel, the target object’s schema, and the current Context Field configuration.
-
Recommendations come back
The model returns a recommended Field API Names list, a Max Fields cap, an Include Related Names flag, a Context Description, and a brief summary of why those choices fit the agent.
-
Review and save
A side-by-side comparison shows the current value next to the recommendation for each of the four fields. Accept the whole set, accept individual fields, or edit before saving.
What Goes Into the Recommendation
The Optimizer is not making blind suggestions from object schema alone. The request to the model includes:
- The agent’s persona, display name and channel
- The agent’s custom prompts (truncated to a sensible length)
- The tools assigned to the agent (up to a small cap of the most relevant)
- The target object’s field metadata — types, labels, picklists, relationships
- The Context Field record’s current values
- Channel-specific guidance — an internal-channel agent gets different recommendations than a customer-facing widget
The result is recommendations that are agent-aware: the same object might get a different field list for a sales-focused agent than for a service-focused one, even in the same org.
The Comparison View
After the run, the UI shows a four-row comparison table — one row per field the Optimizer can change:
| Field | Current | Recommendation |
|---|---|---|
| Context Description | … | … |
| Field API Names | … | … |
| Max Fields | … | … |
| Include Related Names | … | … |
Above the table, a short summary from the model explains the rationale — what the recommendation prioritised, what it deprioritised, and why. Read it before saving.
Credit & Time Cost
Running the Optimizer is a single model call. The credit cost scales with the size of the input (mainly the agent’s prompts and the target object’s schema) and the size of the output. The platform shows the actual credits consumed after the run.
With AI included, a callout timeout can incur the documented 20-credit charge. With Bring your own AI, REDA does not deduct a credit allowance; your provider controls its billing. Check the recorded usage and the error before retrying. A timeout by itself does not establish the cause.
See Credit Usage Optimisation for the broader cost model.
One Context Field Record at a Time
Each Optimizer run is scoped to a single Context Field record — one agent, one object. To optimise an agent that reads several objects, run the Optimizer once per Context Field record for that agent. You can do this in any order; recommendations on one record don’t depend on the others.
When to Run It
- Right after creating a new Context Field record. The Optimizer turns a blank record into a sensible starting configuration in one click.
- After meaningfully editing the agent. Persona changes, prompt rewrites, or new tools shift what context the agent actually needs.
- After schema changes. When new fields are added to an object, the Optimizer can suggest including them.
- When tightening costs. Re-running the Optimizer with an explicit instruction like “reduce field count by half” produces a leaner configuration.
What the Optimizer Does Not Do
- It doesn’t change which Context Field records exist. The set of (agent, object) pairings is your decision; the Optimizer only edits the four configurable fields on a record you’ve already chosen to optimise.
- It doesn’t enforce field-level security (FLS). The Optimizer recommends fields that are useful for the agent’s purpose. At runtime, FLS is still enforced — users see only the fields they’re allowed to read.
- It doesn’t auto-apply. Recommendations are advisory. Nothing changes until you click Save in the comparison view.
Best Practices
Make the persona specific before optimising. The Optimizer’s recommendations are only as focused as the agent definition it reads. A vague persona produces generic field lists. Tighten the persona first; then optimise.
Use the instruction box for org context. A short note like “exclude internal-only fields” or “keep under 12 fields for cost” meaningfully changes the recommendation.
Read the summary, not just the table. The summary explains why fields were chosen or dropped. That reasoning often surfaces things you should change about the agent itself, not just the context.
Re-run with a refined instruction after observing live conversations. The optional instruction box steers the recommendation; a second run with sharper guidance produces sharper recommendations than a first run with no guidance.
Pair with the Conversation Debugger. After applying a recommendation, run a real conversation and use the Debugger to see what fields the agent actually used. The fields it ignored are candidates for removal next time.
Frequently Asked Questions
No. It only edits the four configurable fields on an existing Context Field record. To optimise a new (agent, object) pairing, create the Context Field record first, then run the Optimizer.
Each run is scoped to one record. For an agent with multiple Context Field records, run the Optimizer on each in turn — the runs are independent and can be done in any order.
Field-level security is enforced at runtime when the agent actually reads context. The Optimizer recommends fields that are useful for the agent’s purpose; it doesn’t check each user’s FLS profile. Two users running the same agent will see only the recommended fields they’re individually allowed to read.
Yes. The comparison view shows the recommendation alongside the current value. You can accept the recommendation as-is, edit any of the four fields, or skip the optimisation entirely.
The Optimizer can include polymorphic fields (such as Task WhoId or WhatId) in the field list, but the runtime auto-Name expansion is limited to single-target lookups. See Polymorphic Relationships for the runtime behaviour and the Allow Degraded Record Context setting.
Typically a few seconds. Larger orgs with many fields on the target object run a little longer because the schema sent to the model is larger.
The Context Field record is a Salesforce record — standard field history (when enabled) lets you see the previous values, and you can paste them back manually. There’s no automatic “revert last optimisation” button.
Next Steps
Read Polymorphic Relationships for how the runtime handles fields like WhoId and WhatId, or Context Suggestions to add quick-action chips to the chat interface.