How to test Palm Pulse AI Agents before treasury decisions depend on them

Palm announced Pulse AI Agents for treasury on July 15, 2026, adding scheduled, configurable analysis to its existing Pulse product. For finance, operations, and technology leaders, the immediate issue is whether recurring AI work over cash, debt, foreign exchange, and bank data can save review time without gaining authority over financial execution.

The launch materials describe agents that prepare analysis and recommend actions; they do not describe agents that execute payments, trades, or bank transfers. That boundary gives leaders a practical way to evaluate the product: confirm what the system can read, understand what it produces on schedule, test whether its recommendations hold up against source records, and keep each resulting financial decision with an accountable person.

Pulse AI Agents add scheduled work to a read-only analytical product

According to Palm's July 15 launch release, Pulse AI Agents are configurable workers available to Palm customers. A user can run them with one click or on a set schedule, with results delivered through email or Slack. Listed uses include a daily liquidity brief, foreign-exchange sensitivity analysis, variance explanation, idle-cash scanning, bank-concentration checks, a pre-month-end checklist, and a CFO cash summary.

The scheduled agents build on Pulse, which Palm introduced in March 2026 as a treasury AI analyst. Palm says Pulse works across cash positions, forecasts, investments, debt, FX exposures, and intercompany flows.

Scheduling is the meaningful addition in July. A configured task can rerun as new data arrives and put the result where a reviewer already works. That turns an occasional query into a recurring workflow, even if the underlying system remains read-only.

The data boundary determines what the agent can inspect

Palm says its data layer connects treasury management systems, enterprise resource planning systems, email, Excel files, APIs, portals, data warehouses, and bank accounts into one treasury model. Access design is therefore the first dependency. Reviewers need to know which sources were available, which records were excluded, and how current each source was when the agent ran.

In its March product description, Palm says row-level security is enforced for each customer and that only read operations are allowed at the infrastructure layer. Row-level security restricts which records a user or process can retrieve. Read-only access prevents the analytical product from changing source data through that connection, but the read-only query scope still needs to match user permissions and intended use.

These are first-party architecture claims, not independent verification. A buyer should confirm the identity used for each run, the fields it can retrieve, the effect of permission changes, and what happens when a source is unavailable. The buyer needs a concrete record of the data the task could see when it produced the result.

A schedule turns analysis into a recurring input to work

Once access is established, a user configures a task and schedule or triggers it on demand. For a daily liquidity brief, the agent might retrieve current positions and forecast data, apply the configured analysis, and send the findings before the treasury team begins its review.

Palm says each run shows its process step by step, links conclusions to source records, keeps run history, and stays within the user's permission scope. Those features would help a reviewer inspect an answer and compare runs. They do not establish that every record is correct, the analysis is complete, or the recommendation deserves approval.

Palm also describes schema-first retrieval, in which a defined data model guides what the system fetches, and a daily automated evaluation of factual accuracy, retrieval quality, and tool usage. The cited materials do not provide the evaluation set, pass thresholds, or production error rates. Buyers should examine this vendor control and still collect their own acceptance evidence.

Recommendations should stop before financial execution

The July release says the agents can recommend funding, hedging, rebalancing, repatriation, investment, intercompany-loan, and forecast moves. Each recommendation can influence a consequential decision, yet the cited launch material does not say the agents execute a payment, place a trade, or transfer funds. The supported interpretation is scheduled analysis followed by a recommendation that a person can review.

That separation should remain explicit in system design and operating procedure. The agent prepares evidence, identifies a condition, or proposes an action; a named reviewer checks the sources and decides what to do through the approved treasury process. If another system can execute the decision, its authorization, approval, and transaction controls should remain separate from the analytical task.

Read-only access limits direct action, but a wrong output can still cause harm

A system does not need transaction access to affect money. A reviewer may accept an incorrect liquidity figure, miss a stale balance, overreact to a false concentration alert, or approve a hedge based on an incomplete exposure view. Scheduled delivery can amplify that risk because a polished report arrives repeatedly and may acquire authority through familiarity.

Source links and a visible process help only if reviewers use them and can identify material discrepancies. Run history can show whether an answer changed, but not whether it improved. Permissions cannot correct a bad source record or an analytical error.

The launch release says customers are using the agents, but it does not name those customers or provide sample size, accuracy, review-time, false-alert, loss-avoidance, or independently measured outcome evidence. That is an absence in the cited launch material, not a claim that such evidence does not exist. It means an evaluation team should test product and workflow claims against evidence from its own data and review process, as described in our guide to claim-driven AI workflow testing.

Start with a task whose errors are easy to find and correct

Variance explanation is a strong first candidate. The task produces an account of why actual cash or forecast results differ from an expected figure, while the reviewer can compare each explanation with known source records and correct it without moving money. Bank-concentration monitoring is another reasonable starting point because the output is an alert or report that can be checked against balances and policy thresholds before anyone changes an account position.

A funding recommendation is a poor first scheduled task even if a person remains in the approval path. It combines data quality, forecasting, policy interpretation, and timing in a decision that may be costly to reverse. Teams learn more safely by starting where an error is easy to see, the expected answer can be reconstructed, and a correction stays inside the review process.

The initial scope should be narrow enough to diagnose failure. Define the entities, accounts, currencies, source systems, reviewer, and required checks. Broader AI workflow controls still apply, including access management, change control, incident handling, and ownership, but the pilot should remain simple enough to measure.

A pilot should measure evidence quality and review cost over a fixed window

Before the first run, select a sample of claims to trace back to source records and define what counts as a match. The source-trace match rate should report how many sampled claims point to the correct record and faithfully represent it. Predeclaring the sample method prevents selective testing.

Define a material error in terms relevant to the task, such as a wrong entity, missing account, stale period, incorrect currency treatment, or conclusion that could change the reviewer's decision. Report the material-error rate as the share of reviewed runs containing at least one material error, separate from minor wording defects. Define a false alert as a flagged condition that, under the documented policy and source data, did not require attention; report the false-alert rate as the share of reviewed alerts that met that definition.

Define the reviewer correction rate as the share of reviewed runs in which a person changes at least one fact, explanation, or recommendation before use. Measure review time per run from the start of source checking through the final correction, rather than counting only reading time. Evaluate every measure over a fixed comparison window with the same task scope, sampling method, and documented baseline, so changes in workload or data coverage do not masquerade as improvement.

No universal benchmark value can decide whether the pilot is safe enough. Acceptance thresholds should reflect the financial consequence of an error, the strength of the human review, and the cost of investigating alerts. The decision at the end of the comparison window should be to keep, revise, expand, or stop the task based on those predeclared measures.

Start with one reviewable treasury-analysis task

Palm's launch materials describe a way to configure and distribute recurring treasury analysis. Before relying on it, buyers should verify the data scope, inspect source traces, assign a reviewer, and measure accuracy and review cost over the fixed comparison window.

BaristaLabs helps teams design and implement process automation with explicit access, review, exception, and measurement requirements. A useful first engagement is one scheduled analysis task that supplies evidence to an accountable reviewer while financial approval and execution stay within existing treasury processes.