Trovata Builds Autonomous Treasury Agents on Amazon Bedrock and AgentCore

Trovata is using Amazon Bedrock and Amazon Bedrock AgentCore to turn routine corporate treasury work into persistent, automated workflows, according to a new AWS case study. The platform combines natural-language access to banking data with agents that monitor cash activity, investigate anomalies and deliver updates under existing role-based permissions.

The announcement matters because treasury operations remain heavily dependent on fragmented bank portals, spreadsheets and legacy Treasury Management Systems. Trovata’s approach moves beyond an AI assistant that answers questions: its agents can run on schedules, triggers or rules and act continuously within the company’s treasury operating system.

AWS presents the deployment as an example of how an enterprise software provider can place agentic AI inside a regulated financial workflow. However, the available evidence comes from AWS and Trovata’s own account. Customer savings, adoption and performance figures cited in the case study are vendor-reported rather than independently verified.

From treasury data aggregation to autonomous workflows

Trovata describes itself as an AI-native cash and liquidity management platform with direct connections to more than 10,000 banks. Its system brings cash reporting, forecasting, analysis and money movement into one cloud-based environment, rather than requiring finance teams to reconcile information across numerous bank websites.

According to AWS, Trovata introduced generative AI designed for treasury in 2023. The company has since expanded from providing static insights to supporting autonomous agents embedded in the same platform. That distinction is central to the product design: the AI is connected to treasury objects and verified data interfaces, rather than operating as a general-purpose chatbot placed on top of an existing application.

The platform includes Trovata AI Chat for natural-language questions across multi-bank data. A treasury user could ask for the net cash position across accounts on a previous day, with the system retrieving the relevant information through Trovata’s API layer and presenting the result inside the secured environment.

A second layer, called AI Insights, is intended to identify anomalies, explain variances and surface trends. The AI Agents component turns those capabilities into recurring workflows. Agents can monitor activity, investigate changes and send reports without requiring a team member to repeat the same analysis each day.

Trovata also provides an Agent Builder-Configurator for defining agent behavior and scope. Enterprise role-based access control is designed to ensure that agents inherit the same permission boundaries as the users and workflows they serve.

How Amazon Bedrock and AgentCore fit the design

AWS says Trovata selected its cloud platform for three main reasons: serverless infrastructure for real-time execution, Amazon Bedrock for model inference, and Amazon Bedrock AgentCore for orchestration and security. The case study does not identify every model used or provide a complete breakdown of infrastructure costs, so the architecture should be understood as a product pattern rather than a fully reproducible deployment specification.

Amazon Bedrock supplies the large language model inference used for natural-language understanding and generation. AgentCore provides the runtime and orchestration layer for the autonomous workflows. AWS describes AgentCore as an isolated environment for enterprise agents, with the ability to support role-based controls and deployment at scale.

The practical division of labor is important for builders. Trovata’s own application remains responsible for connecting to banking systems and exposing verified treasury data. AgentCore coordinates the actions and workflow execution, while permissions constrain what an agent can see or do. That arrangement reduces the risk of allowing a language model to make unrestricted calls against financial systems.

The architecture also reflects a broader AWS recommendation for production agent systems: separate specialist responsibilities instead of placing every tool and decision inside one oversized agent. In its related reference architecture, AWS recommends distinct layers for data, model inference, orchestration, security, application delivery, observability and continuous evaluation. Those recommendations are not proof that Trovata implements every layer exactly as described, but they provide context for the design choices AWS emphasizes in the case study.

The evidence behind Trovata’s results

AWS reports that Trovata customers have achieved more than $1 million in annualized cost savings, saved over five hours per day per accounting team, reduced annual TMS costs by 77 percent and shortened treasury reporting from hours or days to less than a minute.

Those figures are significant if representative, particularly for enterprises where finance staff spend substantial time collecting and reconciling data before making cash decisions. But the case study does not provide a customer-by-customer methodology, baseline definitions, sample size or independent validation for the claims. They should therefore be treated as reported outcomes, not general benchmarks for every treasury deployment.

The strongest confirmed evidence is architectural. AWS documents the use of Amazon Bedrock, AgentCore, serverless AWS infrastructure, Trovata’s banking connections, natural-language querying, automated insights and RBAC-secured agents. The material also describes agents retrieving data through Trovata’s verified API layer before generating responses.

That API boundary may be more consequential than the conversational interface. In financial operations, accuracy depends not only on the model’s language output but also on whether the underlying balance, transaction or account data is current, correctly scoped and traceable. A governed data path gives product teams a way to test the agent against known treasury objects rather than relying on open-ended responses.

What the deployment means for AI builders and buyers

For builders, Trovata’s example highlights a path from assistant features to operational automation. A chat interface can make data easier to access, but recurring agents are what remove manual work from the process. The useful unit is not simply a prompt and response; it is a bounded workflow with a schedule, trigger, data source, permission model and delivery mechanism.

That model also changes the engineering burden. Teams must define which actions are read-only, which can alter records or initiate money movement, and which require approval. They need audit trails for agent decisions, controls for failed or ambiguous tasks, and evaluation methods that measure groundedness and accuracy against financial data. AWS’s separate enterprise reference architecture recommends observability, cost tracking, safety checks and continuous evaluation as production requirements rather than later additions.

Enterprise buyers should ask how an agent handles stale bank data, missing accounts, conflicting balances and unusual transactions. They should also examine whether permissions apply at the account, entity and workflow level, and whether the platform can show the evidence behind an explanation. Trovata’s stated RBAC approach addresses an important part of that problem, but the supplied case study does not disclose detailed audit, approval or error-recovery behavior.

The competitive implication is that treasury software vendors may increasingly compete on embedded automation instead of dashboards alone. A platform that can continuously monitor liquidity and explain changes could reduce the value of manual reporting tools. At the same time, buyers are likely to favor vendors that can prove reliability and control, especially when agents approach payment or money-movement workflows.

AWS’s other AgentCore case studies reinforce that pattern. Tata Consultancy Services used specialized agents and tenant isolation for an automated testing platform, while Greenlight Financial reported that its Luna system resolved more than 90 percent of up to 4,000 monthly security and risk cases without human intervention. Those results are also vendor-reported, but together the examples show AWS positioning AgentCore as infrastructure for multi-agent systems in regulated environments, not only as a chatbot backend.

What to watch next

The next signals will be whether Trovata discloses more detail on production usage, including the number of active customers, agent execution volumes, failure rates and the proportion of workflows requiring human approval. Independent customer references would help distinguish repeatable results from selected success stories.

Product teams should also watch for evidence that autonomous treasury agents can safely move beyond monitoring and reporting into controlled actions such as payment preparation, cash transfers or forecast-driven decisions. Those capabilities would raise the requirements for approvals, segregation of duties, auditability and incident response.

On the AWS side, the development of AgentCore’s runtime, identity, policy, memory and evaluation capabilities will indicate how much of the operational stack enterprises can standardize. Model choice, inference cost and the ability to switch models without redesigning workflows will remain important as treasury vendors balance latency, reliability and expense.

Creati.ai perspective

Trovata’s case is notable less because it adds a conversational layer to treasury software than because it treats AI as an always-on operational component. The combination of verified APIs, scheduled agents and RBAC points toward a more credible enterprise pattern than unrestricted automation: agents are useful when their scope, data and authority are explicit.

The open question is whether the reported savings will hold across different banking environments and risk policies. For AI builders and enterprise buyers, the lesson is to evaluate agent systems as financial infrastructure—with permissions, evidence, recovery and measurable outcomes—not merely as model-powered user interfaces.