Scaling agentic workflows with native case management in Amazon Quick Automate

An artificial intelligence (AI) agent can process an invoice, help adjudicate a claim, or classify a support ticket in a proof of concept. But running these agents across thousands or even millions of work items in a production environment introduces an entirely different set of challenges. At enterprise scale, success depends on much more than the agent itself. Organizations need to track the state of each work item as it moves through multiple agents and systems, surface exactly where failures occur and why, allow a human to step in when needed, and scale the infrastructure dynamically based on demand. Amazon Quick Automate addresses these operational challenges through case management. Every work item is represented as a case that persists throughout its lifecycle, providing step-by-step visibility into workflow state, supporting human-in-the-loop processing where judgment is needed, and enabling parallel execution so teams can orchestrate agents to automate business processes at scale.

In this post, we show you how to combine case management with agentic automation capabilities in Quick Automate. We introduce case management and explore the lifecycle of cases in an agentic workflow from case creation through processing to resolution. We cover how to create and manage single or multiple cases, automatically track and update status, handle exceptions, and incorporate Human-in-the-loop (HITL) steps within workflows. We also show the case creator-processor pattern that enables dynamic scaling. Finally, we walk through how to structure case management for enterprise processes, including HITL and case tracking, through a real-life use case.

Quick Automate combines AI agents and workflow orchestration within Amazon Quick to automate complex, end-to-end business processes across applications, UIs, and APIs. By natively combining agentic and deterministic automation capabilities with enterprise workflow orchestration, Quick Automate brings structure, visibility, and control to agent-driven business processes. It provides native case management with trackable work items along with controls like granular access management, activity logging, version control, exception handling, and HITL capabilities. The result is that processes move reliably from initiation to resolution at enterprise scale.

Case management in Quick Automate delivers several key benefits. It provides improved visibility as workflows progress through clearly defined stages with real-time tracking. Process owners can see exactly where each work item stands, while managers can monitor throughput, surface bottlenecks early, and intervene before delays impact business outcomes. Parallel processing allows multiple cases to be executed concurrently, increasing throughput and helping organizations meet business service level agreements (SLAs). Compliance, auditability, and governance are enhanced because every action, decision, and state transition is recorded as part of the case history. Stakeholder engagement also increases through real-time status updates that keep operators, managers, and business stakeholders aligned. Communication happens within the context of each case, replacing fragmented email threads with centralized collaboration, clear ownership, and fewer lost handoffs.

Prerequisites

Before implementing case management workflows in Quick Automate, verify you have access to Amazon Quick and that you are working in the correct AWS Region for your organization, because workflows within Quick Automate are region-specific. Your user account must have an Enterprise license to author workflows in Quick Automate.

Case lifecycle and status

Case management in Quick Automate transforms complex, long-running workflows into discrete, trackable work units that can be processed in parallel. Each case functions as a discrete work item that progresses through defined lifecycle stages. A case contains a case type, which is a user-defined container for grouping related work such as invoices or claims. It also includes a reference name that serves as a unique ID for tracking, and custom data fields stored as key-value pairs that hold the business information needed for processing. The system automatically manages additional metadata including the status of the case in the workflow, exception details if a failure occurs, and execution logs pertaining to the case. The following table describes the lifecycle statuses a case can have.

Case management automation best practices

Case management in Quick Automate is integrated into the standard automation lifecycle. The following subsections walk through each phase, from initial design through monitoring in production.

Designing an automation

When designing your workflow, start by identifying what constitutes a case for your automation. A case represents a single unit of work, such as an invoice, claim, ticket, or order, that moves through the workflow from initiation to resolution.

Next, decide how to create cases. Cases can be created individually as events occur or generated in batches from sources such as files, databases, or external systems. Then determine how to process cases. Cases can be processed sequentially or in parallel. Although a single automation can run the entire workflow, teams often separate responsibilities into two automations to enable parallel processing and clearer ownership. The Case Creator ingests data from sources such as Excel files, databases, and web applications, and transforms each record into a case representing a discrete work item. The Case Processor consumes cases and performs the actual workflow steps, including exception handling and HITL tasks. Multiple processors can run in parallel to increase throughput.

Finally, determine where and when human intervention is needed and incorporate it as part of the workflow. Teams can create human checkpoints that pause a case, present reviewers with relevant data and decision fields, and automatically resume processing after the task is completed.

Quick Automate provides builders with two actions for ingesting work.

The first is Create New Case, used when your data source is an individual event such as a user submitting a form, an API call arriving, or a support ticket being raised. You provide a unique reference name (for example, Order-12345), select a case type that groups similar cases (such as SalesOrders), and attach key-value pairs containing the case’s custom data. This action creates exactly one case and immediately sets it to Ready.

The second is Create Multiple Cases, used when your source is a spreadsheet, CSV file, or table of records such as bulk imports or scheduled data loads. You specify the case type, source table, and which column serves as the unique ID. The action creates a separate case for each row, automatically mapping each column to a custom data field.

Case data often needs modification as workflows progress through different stages. With the update cases action, you can add or modify existing case data by providing a case ID and key-value pairs. Use this action to record processing outcomes, capture audit timestamps, store calculated values, or maintain custom statuses. This action is only available for In Progress cases. Access updated information using updated_case["custom_data"]["key_name"] in your automation. If you need to retrieve or locate existing cases dynamically, use the Search Cases action. With this action, you can query cases based on filters such as case type, reference ID, status, or other attributes. The returned results can then be used to inspect case details, trigger additional processing, or update cases as part of the workflow.

For Human in the loop (HITL) tasks, builders can use the Create User Task action to pause a case and present a human reviewer with relevant context and decision fields. While the case waits in Pending Resolution status, other cases continue to process. When the reviewer completes the task in Task Center, the case automatically transitions back to Ready status with the associated human input, and processing resumes. Because the automation resumes from the beginning, it should check the latest_task_resolution attribute to determine the next branch of execution.

Deploying an automation

After an automation is authored, you publish and configure it for production execution. You can publish workflows and schedule them to run at defined intervals. During deployment, you configure two key aspects. First, you set the number of parallel instances to run concurrently when configuring the trigger, based on the expected workload. Case processor automations can run multiple instances in parallel to distribute the case volume. Second, for HITL tasks, you specify the users or groups who can resolve tasks in Task Center. During deployment, you add individuals or groups to grant Quick users access to complete tasks.

Monitoring an automation

Quick Automate provides real-time visibility into each case as it moves through a workflow, allowing users to track status across each processor instance from a single dashboard. The monitoring view shows key metrics such as successful completion rates, business exceptions (caused by logical or data-related issues such as missing required fields), system exceptions (caused by technical failure), and incomplete cases. These metrics help teams quickly identify bottlenecks and measure automation performance. Each case record includes its status, metadata, and processing details, and users can drill into cases to view full logs, custom data fields, exception messages, timestamps, and screenshots where available.

Use case: Automating multi-bank statement processing with case management

This use case demonstrates how Quick Automate reduces manual data entry across two systems using case management for parallel processing. We walk through a real-world treasury consolidation scenario, from solution architecture through implementation details, showing how each concept introduced in the previous sections applies to production automation.

Corporations banking with multiple institutions face a recurring operational challenge. Each month, treasury analysts download statements from each bank’s portal and manually key hundreds of transactions into the company’s central treasury management system. A single data entry error for amount can cascade into reconciliation issues that take hours to trace, and Sarbanes-Oxley (SOX) compliance requires every entry to be accurate and auditable. The manual process is slow, error-prone, and delays month-end reconciliation.

Solution architecture

The following diagram shows the end-to-end solution architecture for the multi-bank statement processing automation. The case creator and processor automations work together to enable parallel processing and reduce cycle times at scale. The first automation, case creator, retrieves the latest bank statement, extracts each transaction using a custom AI agent, and loads them as individual cases. The second automation, case processor, processes each case by navigating to the banking portal, selecting the correct account, and entering the transaction. Multiple processor instances can run simultaneously, each picking up and entering transactions independently. Payments over $200 are flagged for human review, where a treasury analyst verifies the payee, amount, and authorization before approving or discarding the transaction. Rejected transactions are captured as business exceptions with the analyst’s reason code and comments for the audit trail.

Figure 1: Solution architecture for multi-bank statement processing

Implementation: Creator-processor design

The case creator workflow (Treasury Bank Statement Gathering) performs three key activities. It navigates to the bank statement portal and generates the latest statement for download. It then uses a custom AI agent to parse the downloaded PDF and extract each transaction into structured data fields. Finally, it batch-creates cases with one case per extracted transaction, each set to Ready state for downstream processing. The following image shows the case creator workflow as authored in Quick Automate. The workflow contains two process steps. The first handles browser navigation to the bank portal and PDF download, and the second invokes the custom AI agent for extraction followed by batch case creation.

Figure 2: Case creator workflow in Quick Automate

The Custom agent, which is a specialized task agent configured with actions and instructions, is used natively within the workflow. It receives the downloaded PDF and uses a Python code tool to extract transaction line items into a structured table. The agent’s output schema defines the fields needed for each case. The following image shows the agent configuration with its instruction and output schema.

Figure 3: Custom AI agent configuration

After the agent extracts all transactions, the automation uses the Create Multiple Cases action to batch-create cases. It specifies “Bank Transaction” as the case type, maps the agent’s output table as the custom data source, and designates the Reference column as the unique ID for each case. The following image shows the batch case creation configuration within the workflow.

Figure 4: Create multiple cases

After it is created, each case contains the full transaction data as custom attributes. A case record includes the case status (Ready), its reference name, the case type (Bank Transaction), and custom data fields containing the bank name, account number, transaction date, description, type, and amount. The following image shows the Monitor dashboard with the case table and its key components.

Figure 5: Monitor dashboard with created cases

The case processor workflow (Treasury Bank Transaction Entry) retrieves cases in Ready status and processes each transaction independently. It first opens the banking portal and authenticates as an administrator. It then enters a processing loop that retrieves cases of type “Bank Transaction” and handles them one at a time. Because Quick Automate supports multiple concurrent processor instances, you can scale this automation horizontally to match transaction volume.

For each case, the processor first checks whether the case has already been through human review. If the case was previously routed to a treasury analyst and has returned with a resolution, the processor checks the authorization outcome. Approved cases proceed directly to transaction entry. Rejected cases are raised as business exceptions with the analyst’s reason code and comments, creating a complete audit record without entering the transaction into the portal.

For cases that have not yet been reviewed, the processor evaluates the payment threshold. If the transaction is a payment (Credit type) and the amount is $200 or more, the case is routed to a treasury analyst for dual-authorization review through the Task Center. The HITL task includes transaction details, an authorization drop-down list with Approved and Rejected options, a reason code drop-down list for rejections, and a free-text comments field. The case enters Pending Resolution status while awaiting the analyst’s decision, and the processor moves on to the next available case without waiting.

The following image shows the case processor workflow as authored in Quick Automate, including the conditional logic for human review handling, payment threshold evaluation, HITL task creation, and transaction entry.

Figure 6: Case processor workflow in Quick Automate

For transactions that do not require human review, or that have been approved by an analyst, the processor uses a UI agent to enter the transaction into the banking portal. The agent navigates to the dashboard, adds a new transaction, selects the appropriate type and amount along with other details, and submits the form. The agent also validates that the transaction entry succeeded. The following image shows the UI agent configuration with its natural language instruction for transaction entry and validation.

Figure 7: Native UI agent and instruction

Monitoring case details and status

The Monitor dashboard provides real-time visibility into case processing performance for the treasury consolidation automation. From this view, operators can track how many cases have been created, how many are currently in progress, and how many have succeeded, failed, or are pending human resolution. The dashboard includes charts showing case creation trends and exception patterns over time, supporting both operational monitoring and compliance audit needs.

The following image shows the Cases tab in the Monitor dashboard, displaying case statuses, processing times, and exception details across all processor instances.

Figure 8: Cases

Operators can also access HITL tasks through the Tasks tab to view which transactions are awaiting analyst review, track SLA adherence, and see the resolution history including approval decisions and rejection reasons. The following image shows the HITL task as it appears in the Task Center. The treasury analyst sees the full transaction context along with the authorization form fields for their review decision.

Figure 9: Tasks

Conclusion

Case management in Quick Automate empowers you to handle high-volume, complex automations at scale. By converting your work into discrete, trackable cases with defined lifecycles, you gain complete operational visibility into workflows. This approach reduces cycle times through parallel processing, improves decision quality by routing critical cases to human reviewers, and builds operational confidence through real-time monitoring that surfaces exceptions before they impact outcomes.

Next steps

Start implementing case management in your workflows by reviewing the orchestration documentation for Quick Automate and trying the automations as pre-built samples as described in this post. Open Quick Automate, navigate to your project, choose Start building, and search for “Treasury Bank Statement Gathering” (case creator) and “Treasury Bank Transaction Entry” (case processor) in the sample automation library. After you open both samples, you can run the case creator first to generate transaction cases, then configure and run the case processor to begin entering transactions in parallel.

You can adapt this pattern to other automations like invoice processing or claims adjudication by modifying the case creation logic and processor routing rules while maintaining the same core orchestration structure. For additional resources, see the public documentation for Quick Automate.

About the authors