Acumatica AI agents can become controlled steps inside an ERP process: a user, business event, import scenario, schedule, or workflow invokes an agent action; the agent reads the current record and approved supporting data; it writes a bounded result; and the surrounding process decides what happens next. The practical opportunity in Acumatica 2026 R2 is therefore not unrestricted autonomous ERP. It is governed automation in which the target record, available tools, editable fields, trigger, review point, exception path, and audit evidence are designed before activation.
That distinction matters because an agent can change business records. A useful implementation does more than write a persuasive instruction. It limits the data the model can retrieve, exposes only the tools required for the task, constrains outputs to values that downstream rules can evaluate, tests both normal and adverse cases, and assigns a human owner. Acumatica provides relevant controls through the Agents form, endpoint-backed tools, published Generic Inquiries, field masking, result previews, processing logs, token statistics, AI Automation History, business events, workflows, and import scenarios. Those controls still require process design and operational discipline.
This playbook explains how finance, operations, IT, and process owners can select a suitable use case, design the agent boundary, protect sensitive data, build approval and exception paths, test changes, monitor cost and behavior, and scale only after evidence supports the decision. It focuses specifically on Acumatica AI Automation agents and agent actions. For the broader 2026 R2 program, see the Biz-Tech Acumatica 2026 R2 Upgrade Guide.
Executive Summary for Business and Technology Leaders
An Acumatica AI agent is most valuable when it applies judgment to a narrow record-level task that ordinary rules cannot express cleanly. Examples include classifying an incoming record, drafting a bounded description, comparing a current transaction with approved reference data, or assigning one of several defined review outcomes. Acumatica documentation describes agents that can retrieve the current record, update editable fields and detail lines, and retrieve supporting information through published Generic Inquiries. Once activated, an agent action can be invoked manually or by a configured business event, import scenario, or workflow.
The control model should begin outside the model. The process must specify which record exists before the agent runs, what data the agent may receive, what fields it may update, which output values are valid, what event or transition may follow, and who reviews exceptions. Acumatica notes that an agent works with the current record on its target form and cannot create a new record on that form. It also cannot invoke another target-form action from inside the agent. Record creation, releases, notifications, status transitions, and other actions should remain separate, visible process steps.
The safest first production use case usually has five characteristics:
- A clear owner can explain the business decision in plain language.
- The required data is available on one target form or through a small number of governed Generic Inquiries.
- The permitted output can be limited to a small set of fields or values.
- A person can verify correctness without recreating the entire analysis.
- An incorrect result can be contained, corrected, and traced without financial posting or irreversible downstream effects.
The rollout decision should be evidence based. A pilot should show that the agent selects the right scope, uses the intended tools, produces acceptable changes, routes uncertainty correctly, stays within a tolerable token and processing budget, and fails safely when data is missing or instructions conflict. If those conditions are not demonstrated, the next action is not broader deployment. It is a narrower boundary, better source data, clearer instructions, or a conventional deterministic rule.
What an Acumatica AI Agent and Agent Action Actually Do
In Acumatica 2026 R2, the Agents form ML202000 is used to configure and test AI Automation agents. Selecting a target data-entry form gives the agent a current-record context. Acumatica adds standard tools that retrieve the current record and apply updates to editable fields or detail lines. A configured endpoint defines which entity and fields those tools expose. Supporting data can be added through Generic Inquiry tools, with one published inquiry per tool.
After testing, activating most agents adds a generated command to the target form. A user can invoke that command from the More menu or add it as a favorite. The action can also participate in a process started by a record change, schedule, user action, import, business event, or automation workflow. Acumatica registers an internal action name that begins with LLMAction_ followed by the agent ID; workflow and import-scenario configurations use that name.
The agent is not the whole process. It is one step that retrieves information, applies the instructions, and returns a bounded result. A subsequent business event or workflow condition can evaluate the value written by the agent and decide whether to notify a reviewer, assign a task, run another step, or move the record. This separation is useful because it leaves deterministic routing and approvals in Acumatica configuration rather than asking the model to control every consequence.
The boundary also prevents common overstatements. An agent does not receive unrestricted database access merely because it operates inside the ERP. It receives what its tools, endpoints, Generic Inquiries, filters, and current-record context expose. It cannot update fields that are read-only through the configured endpoint, and it cannot update a detail line if the line cannot be edited manually on the target form. If a task requires a dialog, another form, or a target-form action, that task belongs in a separate workflow step or customization.
How AI Automation Differs from AI Assistant and Biz Tech AI Analyst
Acumatica AI Automation, Acumatica AI Assistant, and Biz-Tech AI Analyst solve different problems. Treating them as interchangeable leads to poor architecture and confusing expectations.
Acumatica AI Automation agents operate in a configured record context. They can retrieve current-record data, call approved supporting tools, and update fields that the configured endpoint permits. Their natural role is bounded execution within a business process. The governance question is which actions, data, fields, triggers, and outcomes are permitted.
Acumatica AI Assistant is oriented toward conversational analysis. The Assistant works with administrator-exposed Generic Inquiries so users can ask questions, examine source records, and create analytical outputs such as tables, charts, pivots, or dashboard widgets. It is suited to finding and explaining information, while AI Automation agents are designed to participate in defined process steps. Organizations planning both should maintain separate ownership, access reviews, use-case inventories, and acceptance tests. The Biz-Tech guide to Acumatica AI Assistant governance covers that analytical use case in more detail.
Biz-Tech AI Analyst is a separate Biz-Tech product for creating and refining Acumatica reports, Generic Inquiries, and Import Scenarios through a proposal-and-approval process. It can help turn business requirements into governed designs, including import mappings, but it does not replace Acumatica AI Automation or remove the need to govern an agent action. AI Analyst presents the proposed data sources, fields, filters, grouping, mapping, and limitations before building or changing a design. For imports, the user’s team retains control of Prepare and Import.
These products can complement one another. A team might use Biz-Tech AI Analyst to prepare a narrowly scoped Generic Inquiry or Import Scenario, use Acumatica AI Automation to apply judgment to each current record, and use Acumatica AI Assistant to analyze approved results. The architecture is sound only when each capability retains its own access boundary, review process, and operational owner.
Choose a Process That Benefits from Model Judgment
The first design decision is whether the task needs an LLM. Many ERP actions are better implemented with formulas, workflows, business events, approval maps, import mappings, validation rules, or code. Those mechanisms are deterministic, easier to test exhaustively, and usually cheaper to run. An agent earns its place when the input contains ambiguity, unstructured text, contextual comparison, or classification that would otherwise require brittle rules or repetitive human interpretation.
Good candidates often transform information rather than authorize a final transaction. Examples include drafting a standardized summary from an existing record, categorizing an activity into one of several review queues, comparing a record with reference data, identifying the reason a record requires attention, or proposing a value for a reviewer to accept. The sales-order pricing demonstration in Acumatica documentation follows this pattern: the agent compares actual line prices with expected values retrieved through a Generic Inquiry and prepares a description of the differences.
Weak candidates combine too many business decisions. An instruction such as “review the order, decide whether the customer is trustworthy, change prices if needed, release the order, and notify everyone” mixes data retrieval, subjective judgment, financial authority, a target-form action, and communication. It is difficult to test, difficult to explain, and inconsistent with the documented boundary that an agent cannot invoke another action on the target form. Split such a process into record preparation, agent evaluation, human or rule-based approval, and deterministic execution.
Use a short selection test before configuration:
- State the input record and the business question in one sentence.
- Identify the smallest output that makes the next step possible.
- List the exact fields and reference data required.
- Define an abstain or review outcome for insufficient evidence.
- Name the person who can judge whether the output is correct.
- Describe how the original state can be restored or corrected.
If the team cannot answer those questions, it is not ready to write agent instructions.
Define the Automation Boundary Before Writing Instructions
Agent governance begins with a process contract. The contract should identify the target form, current entity, trigger, inputs, tools, fields the agent may update, permitted result values, prohibited changes, review path, and evidence retained. This contract should be approved by the process owner and technical owner before anyone spends time refining prompts.
The target form anchors the agent to a current record. Confirm that the form is a data-entry form, that the required entity is available through an endpoint, and that the intended fields can be retrieved and updated. If the Default endpoint omits a required field, decide whether extending an endpoint is justified. Acumatica warns that after an endpoint changes, tool settings in every affected agent must be updated and saved so the tools are rebuilt against the current endpoint definition. Endpoint changes therefore belong in change control, not an informal prompt-editing exercise.
Limit write scope. If the agent only needs to assign a review category and add an explanation, do not expose unrelated writable fields. If it does not need line-level updates, do not design the instructions around them. If a downstream workflow needs a status-like value, use a dedicated field with a small controlled vocabulary rather than asking the model for free-form prose that another rule must interpret.
Define what the agent must not do. Examples include changing quantities, prices, tax data, payment information, customer credit settings, posting periods, ownership, or release status. Some prohibited actions may already be impossible through the selected tools, but documenting them helps reviewers confirm that the technical configuration matches the business policy.
Finally, describe the next step independently of the agent. A workflow or business event should evaluate the saved output and determine whether a person reviews it, a notification is sent, or the record advances. This makes the process observable and allows the organization to disable the agent action without redesigning every downstream rule.
Build a Minimum Data Contract
An agent should receive the least data required to answer its assigned question. More context can improve a demonstration while weakening production control. Extra columns increase the chance that sensitive information is transmitted, that irrelevant details distract the model, that token consumption grows, and that a future data change alters behavior unexpectedly.
For current-record tools, document each exposed field and why it is required. Separate fields needed for reasoning from fields needed only for identification or traceability. For Generic Inquiry tools, define the inquiry owner, published screen ID, filters, returned columns, row limit, business meaning, refresh assumptions, and access restrictions. A query that was designed for human exploration may be too broad for an agent tool.
Acumatica supports adding one or more Generic Inquiry tools, each retrieving data from a single published inquiry. The tool name and description help the model decide when to call it. Use names that describe the business data and descriptions that state both purpose and limits. Avoid a generic description such as “use this for more information.” A better description explains which records the inquiry returns, what filter should be applied, and which decision the data supports.
The data contract also needs volume limits. An inquiry that returns hundreds of rows may exceed the useful context for the task, increase response time, and raise provider costs. Add shared filters and query conditions that produce only the relevant comparison set. Test with records near the expected maximum, not only with a convenient example that returns two rows.
Review the contract whenever a source changes. New columns, renamed fields, modified joins, different filters, or expanded access can change what the agent sees without any edit to its business instructions. Treat a material Generic Inquiry or endpoint change as a reason to retest affected agents.
Protect Sensitive Data and Understand the Masking Boundary
Acumatica AI Automation can mask selected fields returned by the get_current tool before data is sent to the LLM. The system replaces values with placeholders, keeps the actual data in Acumatica, and restores recognized placeholders when the model returns them. This is useful when an agent needs to carry a value through a result without analyzing the value itself.
Masking has operational limitations. A model cannot calculate with or classify a value it cannot see. If a numeric amount is masked, the model cannot use the actual amount to compute a percentage or compare it with a threshold. Acumatica also documents that after patch_current is invoked, an agent with masked fields cannot call get_current again. Instructions and tool sequence must account for that boundary.
Most importantly, masking on get_current does not mask columns returned by Generic Inquiry tools. Acumatica documentation explicitly warns that GI results are sent to the LLM without that masking. A governed design must therefore remove sensitive columns from the inquiry itself, apply appropriate filters, and limit returned records. Do not assume that selecting masked fields on the current-record tool protects a broad supporting inquiry.
Perform a field-level data review before production:
- Identify personal, payroll, banking, payment, tax, credential, contract, pricing, health, and regulated information.
- Decide whether the model needs to see, carry, aggregate, or ignore each value.
- Remove unnecessary fields at the source rather than relying only on instructions.
- Confirm the LLM provider, deployment, retention, regional, and commercial terms with the organization’s security and legal owners.
- Review processing logs carefully because they can contain tool inputs, messages, returned data, errors, and model output.
The processing log is a governance asset and a sensitive record. Limit access to people who need it, define retention expectations, and avoid copying production logs into unsecured tickets or chat threads.
Write Instructions as an Executable Business Policy
Business instructions should describe purpose, required data, allowed tools, decision rules, output fields, valid values, exceptions, and stopping conditions. They should not depend on motivational language or broad requests to “use best judgment.” A reviewer should be able to compare the instructions with the process contract and identify any missing or conflicting rule.
Start with the goal and scope. Name the current record and the single decision the agent supports. Then define the tools and when to use them. Insert exact field and tool names from Acumatica rather than typing approximations. Acumatica provides an Insert Data Field command because the model must use names that match the configured tool schema.
State decision rules in observable terms. If the output is a review category, enumerate the allowed values and the evidence required for each one. Include an explicit value such as NEEDS_REVIEW when the data is incomplete, contradictory, outside policy, or unavailable. Downstream workflows should recognize that value and route it to a person instead of treating uncertainty as approval.
Separate analysis from writing. An agent that evaluates a record and generates explanatory text should first determine the controlled result, then produce a short explanation grounded in the retrieved fields. Limit length and prohibit unsupported claims. If the process needs a note for a customer or vendor, require human approval before external communication.
Add constraints that reflect actual business policy: fields that must remain unchanged, date or amount boundaries, valid currencies, permitted record statuses, maximum number of lines, and conditions that require no update. Avoid repeating constraints in contradictory ways. Acumatica notes that conflicts among system instructions, business instructions, and tool descriptions can cause processing errors.
Version the instructions. Record the approver, effective date, related agent ID, target form, endpoint version, GI versions, and test evidence. A prompt edit can change production behavior as materially as a workflow or code change.
Keep Human Approval at the Right Decision Point
Human review should protect the consequence, not merely observe the model. Placing a reviewer after an irreversible action provides little control. Place approval before release, payment, posting, external communication, compliance classification, account changes, or any transition that materially affects another party.
For a low-risk internal field, post-action review may be sufficient if changes are visible, reversible, and sampled regularly. For higher-risk records, the agent should write a proposal or review status rather than the final authoritative value. A workflow can assign the record to an authorized user, display the explanation, and require acceptance or correction.
Design the review screen around evidence. The reviewer needs the original value, proposed value, reason, relevant source data, and any missing or conflicting information. A bare “AI approved” flag is not enough. Acumatica’s test Result tab demonstrates the value of before-and-after differences; production review should follow the same principle when possible.
Define reviewer authority and service expectations. Specify who may approve, who handles exceptions, how quickly records must be reviewed, and what happens when no reviewer acts. Avoid silently allowing an agent-generated value to become authoritative because a queue aged past a deadline.
Measure human disagreement. Corrections reveal where instructions, source data, or use-case boundaries need improvement. Preserve a reason for overrides rather than recording only that the value changed. A rising override rate should trigger investigation and perhaps automatic suspension of the action for the affected scenario.
Use Agent Actions in Import Scenarios Carefully
Acumatica 2026 R2 allows an import scenario to invoke an AI Automation agent action for each record it creates or updates when the AI Automation feature is enabled. This can apply judgment during a controlled import, but it also multiplies execution volume and introduces ordering requirements.
The documented action sequence is Save, agent action, and Save again. The first save creates or updates the current record so the agent has something to process. The agent reads that record and writes its result. The second save persists the agent’s values. Each row uses Commit and executes for each record. The internal action name is entered manually in angle brackets because the dynamic agent action does not appear in the normal lookup.
Mapping conflicts deserve special attention. If the source file maps a value into a field that the agent also writes, the import can overwrite the model’s result. Acumatica advises leaving the corresponding source values empty when the agent is responsible for those fields. Document field ownership explicitly so a future spreadsheet template or mapping change does not reintroduce the conflict.
Every imported record causes a separate LLM request sequence, and the import waits for each result. Begin with a small record count, measure processing time and token use, and verify the AI Automation History before increasing volume. Do not launch a large production import based on a successful one-record test.
Create restart and reconciliation rules. Determine how to identify records that completed the first save but not the agent action, or the agent action but not the final save. Use an import batch identifier, status field, or other traceable marker. Define whether a failed record can be retried safely and whether the agent will produce the same result when the current record already contains a partial output.
Orchestrate with Business Events and Workflows
An agent action becomes more useful when Acumatica configuration controls when it runs and how its result is handled. A business event can respond to a record change, schedule, or user action. A workflow can expose the agent action only in appropriate states, run it automatically, or use it in a transition. These mechanisms should remain responsible for sequence and authorization.
Use stable output values for downstream logic. Acumatica recommends instructing an agent to write one of a fixed set of values when a business event or workflow condition depends on the result. Free-form text is suitable for explanation, but it is a poor control signal. A dedicated field with values such as NO_ISSUE, REVIEW, and BLOCKED is easier to route, report, and test.
Remember that a business event fires only when its monitored value changes. If the agent writes the value already stored in the field, the event does not trigger. Design state transitions accordingly. Clearing the field before every run may create other risks, so test repeat execution and idempotency instead of assuming every successful agent call causes a new event.
Keep target-form actions separate. Acumatica states that the agent cannot invoke another action of the target form. If the process requires release, assignment, notification, creation of another document, or another command, configure that as a subsequent event or workflow step. This produces clearer logs and lets each action enforce its own rights and validation.
Add an automation stop. Administrators should know how to deactivate the agent, disable an invoking event or workflow transition, and hold affected records. Document the order of operations so an incident response does not create more partially processed work.
Test the Agent Before Activation
Testing must prove both correctness and containment. On the Agents form, the Test Agent function uses an example record and shows intended changes without saving those changes to the database for most agents. The Result tab identifies the affected entity and displays before-and-after values. The Processing Log records instructions, tool schemas, tool calls, responses, timing, errors, messages, and token consumption.
Build a representative test set rather than selecting only clean examples. Include ordinary records, records at policy boundaries, missing fields, unexpected detail-line counts, inactive or closed statuses, values outside normal ranges, conflicting GI results, no GI results, duplicate references, and attempts to introduce irrelevant instructions through text fields. Use de-identified or suitable nonproduction data according to organizational policy.
For every case, record the expected result before running the agent. A test is weak when reviewers decide after seeing the output that it “looks reasonable.” Compare the actual result with an approved expectation and capture differences. For classification, measure agreement by category. For generated text, define required facts, prohibited claims, maximum length, and acceptable tone.
Inspect tool behavior, not only the final wording. Confirm that the model called the expected inquiry, applied the intended filter, retrieved the correct records, and updated only the permitted fields. A plausible answer produced from the wrong data path is still a failure.
Repeat tests across model or connection changes. Agent LLM Connections can point to supported providers including Azure, Amazon Bedrock, OpenAI, and Anthropic, and providers may retire or change models. Acumatica recommends reviewing provider availability and retesting connections. A connection or model change should trigger functional regression tests, masking-placeholder tests, volume tests, and renewed approval before production use.
Validate Failure and Exception Paths
Production reliability depends on how the process behaves when the model, connection, data, or surrounding workflow fails. The desired failure mode is usually a visible exception with no unauthorized update, not an improvised answer.
Test invalid credentials, unavailable endpoints, provider timeouts, rate limits, missing GI permissions, empty results, malformed data, excessive record volume, noneditable fields, and an agent output that does not match the controlled vocabulary. Confirm what appears in the Result and Processing Log tabs and how operators identify the affected record.
Define retry rules. Some failures are transient, but an automatic retry can duplicate work or apply a change after the record has moved to another state. Before retrying, verify that the current record is still eligible, that earlier changes were not saved, and that the action is idempotent. Limit retry count and route repeated failures to a named queue.
Distinguish technical errors from business uncertainty. A provider timeout is a technical failure. Missing evidence or contradictory source data is a business exception. They may require different owners, communications, and service targets. Do not let a generic error status hide the cause.
Create a reconciliation view or Generic Inquiry that shows records awaiting agent processing, records completed, exceptions, last-run time, outcome, reviewer status, and related batch or workflow identifiers. This operational view is often more valuable than a polished demonstration because it enables supervisors to manage real work.
Monitor Activity Tokens Cost and Behavior
Each agent execution can make multiple requests to an LLM, especially when tools are called. Acumatica records token statistics calculated by the ERP and values reported by the provider. The two can differ because providers tokenize and report categories differently. Acumatica documentation states that the provider remains the source of truth for actual usage and billing.
During testing, use the Processing Log to see which requests and tool steps consume tokens. Over time, use AI Automation History ML400000 to review connection tests, agent tests, and production actions invoked by users, business events, import scenarios, or workflows. The history includes Acumatica-calculated values and provider-reported input, output, and total tokens when the provider supplies them.
A blank provider value does not necessarily mean zero usage. It may mean the provider did not report the value. Establish a reconciliation process with the provider dashboard and commercial terms. Monitor both unit economics and business throughput: cost per processed record, cost per accepted result, elapsed time, failure rate, and reviewer effort.
Behavior monitoring is equally important. Track outcome distribution, human override rate, exceptions by cause, tool-call patterns, fields changed, and volume by trigger. A sudden change may indicate new source data, a modified Generic Inquiry, a prompt edit, an endpoint change, a model update, or a shift in incoming records.
Set thresholds for investigation and suspension. Examples include a material rise in NEEDS_REVIEW, repeated writes outside expected fields, processing time that disrupts imports, provider cost above budget, or reviewer disagreement above the pilot baseline. Thresholds should initiate a defined response rather than remain dashboard decoration.
Establish Change Control and Audit Evidence
An AI agent is a production configuration with dependencies. Its effective behavior comes from the business instructions, system instructions, tool descriptions, endpoint entity and version, writable fields, Generic Inquiry definitions, filters, provider connection, model, invoking configuration, and downstream workflow. Change control must cover that full dependency set.
Maintain an inventory with agent ID, name, purpose, owner, target form, endpoint, tools, supporting inquiries, invoking events or workflows, output fields, approval path, connection, reviewer, activation date, and last validation date. Link the inventory entry to the approved process contract and test evidence.
Require review for material changes. A wording correction that cannot affect behavior may need lightweight review, but a new tool, field, decision rule, model, GI column, filter, or automatic trigger requires regression testing. Changes to shared endpoints or inquiries should identify every dependent agent before publication.
Preserve evidence from testing and production review without copying sensitive content unnecessarily. Useful evidence includes test case IDs, expected and actual controlled outcomes, before-and-after field differences, error classifications, timing, token totals, reviewer decision, and approval. Store logs according to security and retention policy.
Auditability also means explaining current behavior. An administrator should be able to answer why the agent could see a field, why it was allowed to update another field, which version of instructions applied, which process invoked it, and who approved activation. If those answers require reconstructing decisions from emails, the control is incomplete.
Use a Phased Implementation Plan
A four-phase rollout keeps the first deployment small while producing evidence for each expansion decision.
Phase one defines the process. Select one record-level use case, write the process contract, identify sensitive data, specify permitted outputs, and choose the reviewer. Confirm feature availability, licensing, target build, provider requirements, and environment policy with the appropriate Acumatica partner and internal owners.
Phase two builds in a sandbox. Configure the connection, target form, endpoint-backed tools, supporting Generic Inquiries, instructions, output fields, and manual action. Do not add an automatic trigger yet. Test representative records and correct scope, data, and instruction problems.
Phase three runs a controlled pilot. Activate the command for a limited user group or narrow queue. Require review of every result. Measure accepted results, corrections, exceptions, processing time, token consumption, and operational effort. Keep a conventional fallback process available.
Phase four automates only the proven boundary. Add a business event, workflow, schedule, or import scenario when manual pilot evidence shows consistent behavior and safe failure. Continue sampling accepted outcomes and reviewing exceptions. Expand volume, record types, or write scope one variable at a time.
Each phase needs an exit decision. The team should explicitly approve advancement, repeat the phase with changes, or stop. “No serious complaints” is not sufficient evidence. Use documented acceptance criteria and a named owner.
Measure Business Value Without Overclaiming
The business case should compare the governed process with its actual baseline. Relevant measures may include review time per record, queue age, percentage of records requiring manual investigation, classification agreement, correction rate, exception resolution time, processing cost, and downstream error rate. Choose measures tied to the selected use case.
Avoid treating model output volume as value. Processing more records is beneficial only when the outputs are correct enough, reviewed at the appropriate level, and used by the next process step. Likewise, a reduction in manual touches is not positive if unresolved exceptions or downstream corrections increase.
Measure accepted automation separately from assisted work. A reviewer may save time even when every result still requires approval. That can be a valid outcome and a safer long-term design for sensitive decisions. Do not force full automation merely to improve an adoption metric.
Include control costs: configuration, source-data maintenance, review, provider consumption, investigation, retraining, and change management. Agent economics can change when record volume, prompt length, tool calls, or provider pricing changes. Review the cost model with actual production history.
Report limitations with results. State the period, record population, model and connection, process version, review method, and exclusions. A pilot on one business unit and one record type does not prove enterprise-wide performance.
Governance Checklist Before Production Activation
Use the following checklist as a release gate:
- The process owner approved a one-sentence purpose and a bounded business outcome.
- The target form, current entity, endpoint, tools, fields, and supporting inquiries are documented.
- The agent receives only the data required for the task.
- Sensitive fields are removed, masked where supported, or otherwise governed.
- The team understands that Generic Inquiry results are not protected by current-record field masking.
- Permitted updates and prohibited changes are explicit.
- Downstream logic uses controlled values rather than interpreting free-form prose.
- Human approval is placed before consequential or irreversible actions.
- Normal, boundary, missing-data, adverse-input, error, retry, and repeat-run cases passed.
- Reviewers verified tool calls and field differences, not only final wording.
- Token use, provider billing, elapsed time, and expected volume are within budget.
- AI Automation History and operational reconciliation views are assigned to owners.
- Rollback steps can deactivate the agent and its invoking configuration safely.
- Instruction, endpoint, inquiry, workflow, and connection changes require appropriate retesting.
- A named owner approved activation and the next review date.
The checklist should be retained with implementation evidence. If an item does not apply, record the reason rather than deleting it. That creates a reviewable decision and helps future owners understand the original boundary.
Common Implementation Mistakes
The first mistake is starting with instructions instead of a process contract. Prompt refinement cannot repair an undefined owner, excessive write scope, or missing approval step.
The second is exposing a broad Generic Inquiry because it is convenient. Supporting inquiries should be purpose-built or carefully constrained. Remember that current-record masking does not mask GI results.
The third is combining judgment and consequence. Let the agent propose or classify, then let a person or deterministic workflow authorize the material action.
The fourth is testing one clean record. A production decision needs boundary, missing-data, conflicting-data, volume, repeat-run, and technical-failure cases.
The fifth is relying on free-form text as a workflow condition. Use fixed output values for routing and keep prose for explanation.
The sixth is ignoring dependency changes. Endpoint, GI, model, provider, instructions, and workflow changes can all alter behavior.
The seventh is assuming provider token values are always complete. Blank values can mean unreported usage, and the provider dashboard remains the billing authority.
The eighth is automating a large import too early. Each record can generate a separate execution and multiple LLM requests, so begin with a small batch and reconcile every outcome.
The ninth is presenting Acumatica AI Automation as equivalent to AI Assistant or Biz-Tech AI Analyst. Their purposes and control boundaries differ.
The tenth is treating activation as the end of implementation. Production monitoring, human feedback, exception handling, and scheduled revalidation are part of the operating model.
Frequently Asked Questions
What is an Acumatica AI agent
An Acumatica AI Automation agent is a configured model-driven capability associated with a target data-entry form. It can retrieve the current record, update fields and editable detail lines through endpoint-backed tools, and retrieve supporting data from published Generic Inquiries. After testing and activation, the related agent action can be invoked manually or through configured business events, workflows, schedules, or import scenarios.
Can an Acumatica AI agent create a new record
The documented agent action works with the current record on its target form and cannot create a new record on that form. A surrounding process must create or identify the record before invoking the agent. The agent may update permitted fields on that current record; other creation or action steps should be configured separately.
Can an agent run another form action?
Acumatica documentation states that an agent cannot invoke another action of the target form. Configure release, notification, assignment, transition, or other commands as separate business-event or workflow steps with their own permissions and validation.
How can agent actions be started
An active agent normally adds a command to the target form for user invocation. An action can also be invoked through a business event, import scenario, or workflow. The appropriate trigger depends on the process risk, record state, desired review point, and expected volume.
Does masking protect data returned by Generic Inquiries
No. Acumatica’s documented field masking applies to selected values returned by the get_current tool. It does not mask data returned by Generic Inquiry tools. Remove sensitive GI columns, use narrow filters, limit records, and review the inquiry as a separate data boundary.
How should an agent communicate a result to a workflow
Use a dedicated field with a fixed set of permitted values, such as NO_ISSUE, REVIEW, or BLOCKED. The agent may also write an explanation, but downstream logic should not have to interpret unrestricted prose. Test repeat execution because a business event is triggered only when the monitored value changes.
Can an import scenario call an agent action
Yes, when AI Automation is enabled. Acumatica documents a Save, agent action, Save sequence for each record, with Commit selected and execution configured for each record. Start with a small batch because each record creates a separate LLM execution and the import waits for the response.
How do I estimate AI Automation cost
Review token consumption in the Processing Log during tests and in AI Automation History over time. Compare Acumatica-calculated values with provider-reported usage, and reconcile with the provider dashboard because the provider remains the source of truth for billing. Include processing volume, tool calls, retries, review effort, and support overhead.
When should a team keep human approval
Keep approval before financial posting, release, payment, external communication, compliance classification, account changes, or another material consequence. Lower-risk internal suggestions may use sampling after a controlled pilot, but the organization should retain an exception path, override evidence, and a way to suspend the automation.
What is the safest first Acumatica AI agent use case
Choose a narrow current-record task with limited data, a small controlled output, an easy human check, and a reversible result. Classification, summarization, or proposal generation is usually safer than autonomous transaction processing. Test manually before adding automatic triggers.
A Practical Next Step
Start with one real queue, one current record, one decision, and one owner. Write the process contract before configuring an agent. Then build the smallest tool and data boundary that can support the decision, test adverse cases, and run a reviewed pilot. Scale only the part that evidence shows to be reliable.
Biz-Tech Services can help organizations assess Acumatica AI Automation use cases, design controlled workflows and import scenarios, review Generic Inquiry and endpoint exposure, define test evidence, and establish monitoring and rollback procedures. The objective is a production process that remains understandable and governable after the demonstration ends. Explore practical implementation resources in the Biz-Tech Acumatica Lessons library or discuss a scoped automation review with Biz-Tech Services.
Sources
- Acumatica 2026 R2 Integration Guide Use of Agent Actions
- Acumatica 2026 R2 Integration Guide Agent Actions in Import Scenarios
- Acumatica 2026 R2 Form Reference Agents ML202000
- Acumatica 2026 R2 Integration Guide Creation of Agents
- Acumatica 2026 R2 Integration Guide Hiding of Sensitive Data
- Acumatica 2026 R2 Integration Guide Testing and Troubleshooting Agents
- Acumatica 2026 R2 Integration Guide Collection of Statistics
- Acumatica 2026 R2 Form Reference Agent LLM Connections ML201000
- Acumatica Cloud Platform and 2026 R2 AI Overview
- Biz-Tech Services Acumatica 2026 R2 Upgrade Guide
- Biz-Tech Services Acumatica AI Assistant Governance Guide
- Biz-Tech AI Analyst
