)
Agentic AI for Batch Application Monitoring in Financial Services
Technology Reply applies multi-agent AI architectures to batch application monitoring in financial services, reducing the analytical workload of overnight operations through automated triage, contextual diagnostics, graduated escalation, and rigorous governance with human oversight
Batch Monitoring Challenges
Financial institutions process large transaction volumes during overnight batch windows, running thousands of interdependent jobs under strict SLAs for settlements, payments, and distributions. These legacy environments involve complex dependency chains, where a single failure can propagate downstream and disrupt the following business day's operations.
Manual monitoring remains common across the industry, with on-call operators called upon to analyse logs, inspect code, and resolve issues under significant time pressure. This model is becoming increasingly difficult to sustain as batch workloads grow more complex, specialist expertise becomes scarcer, and traditional rule-based automation covers only a limited range of known failure scenarios.
Applying Agentic AI to Batch Operations
Technology Reply's work focuses on applying agentic AI to batch workload monitoring through multi-agent architectures with tool-calling capabilities. These architectures enhance operational capacity by automating the analytical steps that support human decision-making.
To validate this approach, Technology Reply is conducting a pilot with partner financial institutions, using an orchestrator that coordinates specialised sub-agents. Each sub-agent operates autonomously within a defined resource budget and produces a structured report containing findings, supporting evidence, and open questions. Guided by policies derived from operational experience, the orchestrator decides whether to continue the analysis, engage additional sub-agents, or escalate to an on-call operator.
Gathering Context Before Reasoning
The core insight behind this design is that much of an operator's time during an incident is spent gathering the context needed to make decisions. Reading logs, inspecting source code, querying databases, and comparing current behaviour with historical baselines are tasks well suited to autonomous AI agents operating within defined boundaries. By the time an escalation reaches the on-call operator, the analytical groundwork is already in place.
The orchestrator builds this context progressively by invoking sub-agents and tools in sequence, grounding each stage of the analysis in evidence. Each additional layer of information helps narrow down possible root causes and refine subsequent recommendations. Alert metadata, execution metrics, historical logs, batch dependencies, relevant source code, and database state together provide a comprehensive view of the incident to support diagnostic conclusions.
Structured Reasoning and Decision-Making
Each sub-agent produces a structured report describing what it examined, what it found, and the evidence supporting each finding. Sub-agents do not assess their own reliability. The orchestrator alone evaluates confidence, reviewing the combined findings to determine how strongly they support a proposed root cause.
This centralises judgement and keeps evidence gathering separate from the assessment of conclusions. Confidence is expressed through categories (Low, Medium, High, or Insufficient), which have proved more reliable and easier for operators to interpret than numerical scores.
The system combines findings from multiple sub-agents to establish whether the evidence points to a common root cause or whether uncertainty remains. When confidence is high and the failure is well understood, it recommends specific remediation steps. When findings are inconclusive or conflicting, it acknowledges the limits of its analysis and prepares a structured escalation report, clearly distinguishing what has been established from what remains uncertain.
What Are the Benefits of a Multi-Agent Architecture for Batch Monitoring?
Batch incident analysis could, in principle, be handled through a single model call. Distributing the work across specialised sub-agents offers four benefits that a monolithic approach cannot consistently guarantee.
An incident involving a failed job, related components, thousands of log lines, and a dependency graph can exceed what a single context can handle effectively. Each sub-agent examines only the information relevant to its task and returns a concise report, allowing the orchestrator to reason over consolidated findings.
Each sub-agent operates within defined resource and access limits. If one part of an investigation stalls, the issue remains contained, with resource limits preventing it from compromising the overall analysis.
Each sub-agent produces a distinct, traceable report, allowing the analytical process to be reviewed step by step. This visibility supports the institution's operational risk requirements.
Sub-agents connect to configurable model endpoints. Proprietary code can be analysed using an internally hosted large language model, while another agent uses a different endpoint. Either can be updated without changing the orchestration logic.
The architecture also supports specialisation across distinct analytical tasks, including shell script analysis, PL/SQL interpretation, COBOL comprehension, log pattern recognition, and database state inspection. Separating these tasks helps identify and characterise recurring failure patterns over time.
This flexible endpoint design allows financial institutions to replace external models with internally hosted alternatives to meet data sovereignty and compliance requirements, without restructuring the overall architecture.
Graduated Autonomy and Human Oversight
The multi-agent architecture supports different levels of autonomy, calibrated to the complexity and risk of each incident. For well-understood, low-risk scenarios, the system may autonomously determine that no action is needed and record its reasoning. For moderately complex scenarios, it prepares a detailed diagnostic report and recommended steps for operator review. For highly complex or ambiguous scenarios, it escalates promptly with all available context, allowing human judgement to focus where it is most needed.
Escalation policies draw on operational experience and can be tailored to each institution's preferences and risk appetite. This graduated approach automates routine analytical work while preserving human authority over consequential decisions and maintaining clear accountability throughout the incident lifecycle.
Governance Model: Safety by Design
Deploying AI agents in financial services requires rigorous governance. The architecture embeds safety constraints directly into its design, making governance an integral part of how the system operates.
Approval workflows
All agent operations are strictly read-only. Agents observe and analyse without modifying systems, limiting the impact of analytical errors to recommendations that are always passed to an on-call operator for execution.Confidence thresholds
Each report presents the analytical steps and supporting evidence, including log entries, code fragments, and query results, clearly distinguishing established findings from inferences. This transparency supports operator verification, particularly during time-critical overnight incidents.Audit trails
Each sub-agent operates within a defined budget that limits the files it can inspect and the queries it can execute. If an investigation reaches these limits without a conclusion, the orchestrator escalates rather than consuming further resources.Scope boundaries
Agents do not access sensitive production data directly. Anonymisation filters prevent customer or transactional data from being exposed to AI models when database access is needed for diagnosis.Feedback integration
The orchestrator follows policies derived from operational experience to determine when to continue autonomous analysis and when to involve human oversight, supporting alignment with the institution's governance and regulatory requirements.
How the Approach Works in Practice
Delay Scenarios
When a delay alert is received, the system analyses the operational context and execution trends to assess its severity. If a potentially significant impact is identified, it promptly engages the support team with the information needed to act. Otherwise, it continues monitoring and reassesses the situation, escalating if the delay persists. This workflow reduces unnecessary notifications and helps operators focus on relevant anomalies.
Error Scenarios
When a job fails, the system gathers and correlates the available diagnostic information to identify possible causes and recommend recovery actions. Findings are presented to operators with a clear distinction between evidence and hypotheses, highlighting any areas that require further investigation. The support team receives a structured overview that accelerates analysis and supports decision-making, while preserving human control over interventions.
Future Evolution and Continuous Improvement
Technology Reply's approach to agentic AI for batch monitoring is designed to evolve over time. Domain knowledge and operational policies are defined through configuration rather than hard-coded into the architecture, allowing the approach to adapt to different monitoring environments.
Expanded integrations
Historical trend analysis can identify potential issues before they occur. Learning from past incidents can also uncover recurring patterns and latent defects that might otherwise remain undetected across multiple batch cycles.
Predictive analytics
Once a recurring failure is sufficiently understood, predefined and reviewed remediation procedures with explicit execution conditions could address it, subject to validation against historical incidents, approval from the institution's change management and risk offices, and a traceable record of every automated execution. Agent-led analysis remains strictly read-only throughout.
Autonomous resolution
Operators could query batch status and incident history in natural language, simplifying access to operational information during high-pressure situations.
These developments preserve the core principles of contextual analysis, structured reasoning, and graduated autonomy, while progressively extending automation in line with each institution's risk management policies.
Implementing Multi-Agent Architectures for Overnight Batch Monitoring
Multi-agent AI architectures offer financial institutions a structured path from manual overnight batch monitoring to automated triage, contextual diagnostics, and graduated escalation, supported by rigorous governance. Technology Reply works with leading European banks and wealth management firms to design and implement these architectures.
Frequently Asked Questions
Technology Reply, part of the Reply Group, specializes in the design and implementation of innovative solutions based on Oracle technologies. With over 25 years of expertise and experience, Technology Reply supports its clients in their innovation and digital transformation processes, with a team of professionals capable of managing every phase of a project lifecycle: analysis, design, implementation, launch, and operations. Technology Reply positions itself as a key partner for both on-premises and cloud Oracle technologies, including Big Data, Analytics, eCommerce, Mobile, Identity and Access Management, and Content Management. With its Agile culture, Technology Reply is becoming a leader in emerging technologies, delivering projects in Artificial Intelligence, Machine Learning, microservices based on DevOps, and cognitive technologies across a wide range of industries, sectors, and clients.