Amazon Quick Automate のネイティブケース管理機能によるエージェントワークフローの拡張
Amazon Quick Automate は、AI エージェントの運用を大規模化するために、ワークアイテムの状態を追跡・管理するネイティブなケース管理機能とヒューマンインザループ処理を提供し、実務レベルでの信頼性を高めています。
キーポイント
エンタープライズスケールにおける運用課題の解決
数千〜数百万件のワークアイテムを処理する際、エージェント単体ではなく、状態追跡、障害箇所の特定、動的スケーリングが不可欠であることを強調しています。
ネイティブケース管理機能の詳細
各ワークアイテムをライフサイクル全体で永続化する「ケース」として扱い、ステップごとの可視性と並列実行によるオーケストレーションを可能にします。
ヒューマンインザループ（HITL）と例外処理
判断が必要な場面やエラー発生時に人間が介入できる仕組みを組み込み、自動化プロセスの信頼性と柔軟性を確保する機能を解説しています。
ケース作成者 - 処理者パターンの活用
需要に応じて動的にスケーリング可能なアーキテクチャパターンを紹介し、実世界のユースケースにおける構造化された管理方法を具体的に示しています。
重要な引用
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
Quick Automate brings structure, visibility, and control to agent-driven business processes.
影響分析・編集コメントを表示
影響分析
本記事は、AI エージェント技術が実験段階から実社会の大規模運用へ移行する際の決定的な課題である「信頼性と管理性」に対する具体的な解決策を提示しています。特に、AWS の Quick Automate が提供するケース管理機能は、企業の DX 推進において AI を安全かつ効率的に導入するための標準的なアーキテクチャモデルとして重要な役割を果たす可能性があります。
編集コメント
AI エージェントの実用化において、技術的な処理能力以上に「運用の可視化」と「人間の介入機制」が重要であるという本質を突いた内容です。AWS の新機能は、企業の AI 導入障壁を下げる重要なステップと言えます。
人工知能（AI）エージェントは、概念実証の段階であれば請求書の処理や請求の裁定支援、サポートチケットの分類などを実行できます。しかし、これらのエージェントを実環境で数千件あるいは数百万件の作業項目にわたって運用すると、全く異なる課題が生じます。企業規模での成功には、エージェントそのもの以上に重要な要素があります。組織は、各作業項目が複数のエージェントやシステムを通過する際のステータスを追跡し、失敗が発生した場所と理由を明確に把握し、必要に応じて人間が介入できる仕組みを提供し、需要に基づいてインフラを動的に拡張する必要があります。Amazon Quick Automate は、ケース管理 を通じてこれらの運用上の課題に対処します。すべての作業項目はライフサイクル全体を通じて永続する「ケース」として表現され、ワークフローのステータスに対する段階的な可視性を提供し、判断が必要な場合に人間が関与する処理をサポートし、並列実行を可能にすることで、チームが大規模なビジネスプロセスの自動化のためにエージェントをオーケストレーションすることを可能にします。
本記事では、Quick Automate において、ケース管理とエージェント型自動化機能を組み合わせる方法をご紹介します。ここではケース管理の概要を説明し、ケース作成から処理を経て解決に至るまでの、エージェント型ワークフローにおけるケースのライフサイクルを探ります。単一または複数のケースを作成・管理する方法、ステータスの自動追跡と更新、例外への対応、およびワークフロー内での Human-in-the-loop (HITL) ステップの組み込み方法について解説します。さらに、動的なスケーリングを可能にするケース作成者 - 処理者のパターンについても取り上げます。最後に、実際のユースケースを通じて、HITL やケース追跡を含むエンタープライズプロセスにおけるケース管理の構築方法を具体的に説明していきます。
Quick Automate は、Amazon Quick 内で AI エージェントとワークフローオーケストレーションを組み合わせることで、アプリケーション、UI、API にわたる複雑なエンドツーエンドのビジネスプロセスを自動化します。エージェント型と決定論的な自動化機能をエンタープライズ向けワークフローオーケストレーションにネイティブに統合することで、Quick Automate はエージェント駆動型のビジネスプロセスに構造化、可視性、制御をもたらします。追跡可能な作業項目を備えたネイティブのケース管理機能を提供し、細粒度アクセス管理、アクティビティログ、バージョン管理、例外処理、HITL（人間がループに参加する）機能などの制御手段も備えています。その結果、プロセスはエンタープライズ規模で開始から解決まで確実に進行します。
Quick Automate のケース管理機能は、いくつかの重要な利点を提供します。明確に定義されたステージをワークフローが進む過程でのリアルタイム追跡により、可視性が向上します。プロセスオーナーは各作業項目の現状を正確に把握でき、マネージャーは処理能力を監視し、ボトルネックを早期に特定して遅延がビジネス成果に影響を与える前に介入できます。並列処理により複数のケースを同時に実行できるため、スループットが増加し、組織がビジネスサービスレベル契約（SLA）を満たすのを支援します。すべてのアクション、意思決定、状態遷移がケース履歴の一部として記録されるため、コンプライアンス、監査可能性、ガバナンスが強化されます。また、オペレーター、マネージャー、ビジネスステークホルダーを一致させるリアルタイムステータス更新を通じて、ステークホルダーのエンゲージメントも向上します。コミュニケーションは各ケースの文脈内で行われるため、断片的なメールスレッドに代わり、集中型コラボレーション、明確な所有権、失われる引き継ぎの減少を実現します。
前提条件
Quick Automate でケース管理ワークフローを実装する前に、Amazon Quick にアクセスできることを確認し、組織に適した AWS リージョン で作業を行っていることを確認してください。Quick Automate 内のワークフローはリージョン固有のものだからです。また、Quick Automate でワークフローを作成するには、ユーザーアカウントに エンタープライズライセンス が付与されている必要があります。
ケースのライフサイクルとステータス
Quick Automate における ケース管理 は、複雑で長時間実行されるワークフローを、並列処理可能な個別の追跡可能な作業単位に変換します。各ケースは、定義されたライフサイクル段階を経て進行する個別の作業項目として機能します。ケースには「ケースタイプ」が含まれており、これは請求書や請求事項など関連する業務をグループ化するためのユーザー定義コンテナです。また、追跡用の一意の ID として機能する参照名と、処理に必要なビジネス情報を保持するキー・バリューペア形式で保存されたカスタムデータフィールドも含まれています。システムは自動的に、ワークフロー内のケースの状態、失敗発生時の例外詳細、およびケースに関連する実行ログなどの追加メタデータを管理します。以下の表では、ケースが取りうるライフサイクルステータスを説明しています。
| ステータス | 説明 | このステータスに入る方法 | 次に何が起こるか |
|---|---|---|---|
| Ready (準備完了) | ワークフローが処理可能な新しいケースを生成 | ワークフローが新しいケースを生成 | ワークフローがそのケースを消費し、実行を開始 |
| In Progress (進行中) | ワークフローがケースを積極的に処理中 | ワークフローが *Ready* ステータスのケースの処理を開始 | ケースは *Successful (成功)*、*Failed (失敗)*、または *Pending Resolution (解決待ち)* のいずれかのステータスへ移行 |
成功
ケースはエラーなく各ステップを完了しました
プロセス内の各ケースは例外なく完了しました
終端状態。これ以上の処理は行われません。
失敗
ケースはビジネスまたはシステムの例外をもって終了しました
処理中に例外が発生しました
終端状態 – 詳細はログを確認してください。
解決待ち
ケースは一時停止され、人間のタスク完了を待機しています
タスクセンターにタスクが作成されます。システムが次のケースへ進む間、ケース処理は保留されます。
タスクセンターでタスクが完了すると、関連する人間からの入力とともにケースは自動的に *準備完了* 状態へ移行します。
ケース管理自動化のベストプラクティス
Quick Automate の ケース管理 は、標準的な自動化ライフサイクルに統合されています。以下の各サブセクションでは、初期設計から本番環境での監視に至るまでの各フェーズを順を追って解説します。
自動化の設計
ワークフローを設計する際は、まず自社の自動化において「ケース」とは何を指すのかを特定することから始めます。ケースは、請求書、クレーム、チケット、または注文など、開始から解決までワークフロー内を移動する単一の作業単位を表します。
次に、ケースの作成方法を決定します。ケースは、イベントが発生するたびに個別に作成することもできますし、ファイル、データベース、外部システムなどのソースからバッチ生成することも可能です。次に、ケースの処理方法を決めます。ケースは順次処理することも並列処理することもできます。単一の自動化でワークフロー全体を実行することも可能ですが、チームでは並列処理を可能にし、責任所在を明確にするために、通常は 2 つの自動化に責任範囲を分けます。Case Creator は、Excel ファイル、データベース、Web アプリケーションなどのソースからデータを取得し、各レコードを個別の作業項目を表すケースに変換します。Case Processor はケースを受け取り、例外処理や HITL タスクを含む実際のワークフローステップを実行します。複数のプロセッサを並列で実行することで、スループットを増加させることができます。
最後に、人間の介入が必要となる場所とタイミングを決定し、それをワークフローの一部として組み込みます。チームは、ケースを一時停止し、レビュー担当者に関連データや判断フィールドを表示し、タスク完了後に自動的に処理を再開する人間によるチェックポイントを作成できます。
自動化の作成
Quick Automate は、ビルダーに対して作業を取り込むための 2 つのアクションを提供します。
最初のアクションは Create New Case です。これは、データソースがユーザーによるフォーム送信や API 呼び出しの到着、サポートチケットの発生といった個別のイベントである場合に使用されます。一意のリファレンス名（例：Order-12345）を指定し、類似したケースをグループ化するケースタイプ（SalesOrders など）を選択して、ケースのカスタムデータを含むキーと値のペアを添付します。このアクションはちょうど 1 つのケースを作成し、即座にそのステータスを「Ready」に設定します。
2 つ目のアクションは Create Multiple Cases です。これは、データソースがスプレッドシート、CSV ファイル、またはバッチインポートやスケジュールされたデータロードなどのレコードのテーブルである場合に使用されます。ケースタイプ、ソースとなるテーブル、および一意の ID として機能する列を指定します。このアクションは各行ごとに個別のケースを作成し、各列を自動的にカスタムデータフィールドにマッピングします。
ワークフローが異なるステージを進行するにつれて、ケースデータには変更が必要な場合があります。[update cases action]（更新ケースアクション）を使用すると、ケース ID とキー・バリューペアを提供することで、既存のケースデータに追加または修正を加えることができます。このアクションは、処理結果の記録、監査用タイムスタンプの取得、計算値の保存、カスタムステータスの維持などに利用できます。なお、このアクションは「進行中」のケースに対してのみ利用可能です。自動化内では、updated_case["custom_data"]["key_name"] を使用して更新された情報を取得してください。既存のケースを動的に検索または特定する必要がある場合は、[Search Cases action]（ケース検索アクション）を使用します。このアクションにより、ケースタイプ、参照 ID、ステータス、その他の属性などのフィルターに基づいてケースを検索できます。取得した結果は、その後、ケースの詳細を確認したり、追加処理を開始したり、ワークフローの一部としてケースを更新するために使用できます。
Human in the loop (HITL) タスク Human in the loop (HITL) tasks の場合、ビルダーは「ユーザータスクの作成」アクションを使用してケースを一時停止し、関連する文脈と意思決定フィールドを人間レビューヤーに提示できます。ケースが「解決待ち (Pending Resolution)」ステータスで待機している間も、他のケースは引き続き処理されます。レビューヤーが Task Center でタスクを完了すると、関連する人間の入力とともにケースは自動的に「準備完了 (Ready)」ステータスに遷移し、処理が再開されます。自動化は最初から再開されるため、次の実行分岐を決定するために latest_task_resolution 属性を確認する必要があります。
自動化のデプロイ
自動化が作成された後、本番環境での実行に向けて公開および設定を行います。ワークフローを公開し、定義された間隔で実行スケジュールを設定できます。デプロイ時には、2 つの重要な側面を設定します。まず、トリガーの設定時に予想される負荷に基づいて、同時に実行する並列インスタンス数を設定します。ケースプロセッサ自動化では、ケースボリュームを分散させるために複数のインスタンスを並列で実行できます。次に、HITL タスクの場合、Task Center でタスクを解決できるユーザーまたはグループを指定します。デプロイ時には、Quick ユーザーがタスクを完了できるようにアクセス権限を付与するために、個人またはグループを追加します。
モニタリングの自動化
Quick Automate は、ケースがワークフローを通過する際にリアルタイムで各ケースの可視性を提供し、ユーザーは単一のダッシュボードから各プロセッサインスタンスの状態を追跡できます。モニタリングビューでは、正常な完了率、ビジネス例外（必須フィールドの欠落など論理的またはデータ関連の問題に起因）、システム例外（技術的障害に起因）、未完了ケースといった主要指標が表示されます。これらの指標により、チームはボトルネックを迅速に特定し、自動化のパフォーマンスを測定できます。各ケースレコードにはそのステータス、メタデータ、処理詳細が含まれており、ユーザーはケースの詳細を確認して完全なログ、カスタムデータフィールド、例外メッセージ、タイムスタンプ、利用可能な場合はスクリーンショットなどを閲覧できます。
ユースケース：ケース管理を活用した複数銀行の明細書処理の自動化
このユースケースでは、Quick Automate がケース管理による並列処理を用いて、2 つのシステム間での手動データ入力削減をどのように実現するかを示します。ソリューションアーキテクチャから実装の詳細に至るまで、実際の財務統合シナリオを追跡し、前節で導入された各概念が生産環境における自動化にどう適用されるかを解説します。
複数の金融機関と取引を行う企業は、 recurring な運用上の課題に直面しています。毎月、財務アナリストは各銀行のポータルから明細書をダウンロードし、数百件の取引を手動で会社の中央財務管理システムに入力します。金額の入力ミスが一つでも発生すると、照合問題が連鎖して数時間を要する追跡作業となり、サバニーズ・オクスリー法（SOX）コンプライアンスではすべての入力が正確かつ監査可能であることが求められます。この手動プロセスは遅く、誤りやすく、月末の照合を遅らせる要因となっています。
ソリューションアーキテクチャ
以下の図は、複数銀行の取引明細処理自動化のためのエンドツーエンドのソリューションアーキテクチャを示しています。ケース作成者およびケースプロセッサの自動化機能は連携して並列処理を可能にし、大規模な環境におけるサイクルタイムを短縮します。最初の自動化である「ケース作成者」は最新の銀行明細を取得し、カスタム AI エージェント（AI Agent）を用いて各取引を抽出し、個別のケースとしてロードします。2 つ目の自動化である「ケースプロセッサ」は、各ケースに対して銀行ポータルへアクセスし、適切な口座を選択して取引を入力することで処理を行います。複数のプロセッサインスタンスが同時に実行され、それぞれが独立して取引を取得・入力します。$200 を超える支払いは人間のレビュー対象としてフラグが立ち、財務アナリストが受取人、金額、承認の有無を確認した上で取引を承認または却下します。却下された取引は、アナリストによる理由コードとコメントを付与してビジネス例外として記録され、監査証跡（Audit Trail）に保持されます。
*図 1: 複数銀行の取引明細処理のためのソリューションアーキテクチャ*
実装：クリエイター・プロセッサ設計
ケース作成者 ワークフロー（財務諸表の集約）は、3 つの主要な活動を実行します。まず、銀行ステートメントポータルにアクセスして最新のステートメントを生成しダウンロードします。次に、カスタム AI エージェントを使用してダウンロードされた PDF を解析し、各取引構造化データフィールドへ抽出します。最後に、抽出された各取引ごとに 1 つずつケースを作成するバッチ処理を行い、下流の処理のためにそれぞれの状態を「準備完了（Ready）」に設定します。以下の画像は、Quick Automate で作成されたケース作成者ワークフローを示しています。このワークフローには 2 つのプロセスステップが含まれています。最初のステップは、銀行ポータルへのブラウザナビゲーションと PDF ダウンロードを担当し、2 つ目のステップでは抽出のためにカスタム AI エージェントを呼び出し、その後にバッチによるケース作成を実行します。
*図 2: Quick Automate 内のケース作成者ワークフロー*
カスタムエージェントは、アクションと指示を構成した特殊なタスクエージェントであり、ワークフロー内でネイティブに使用されます。このエージェントはダウンロードされた PDF を受け取り、Python コードツールを使用して取引明細項目を構造化されたテーブルへ抽出します。エージェントの出力スキーマでは、各ケースに必要なフィールドが定義されています。以下の画像には、指示と出力スキーマを含むエージェント構成が表示されています。
*図 3: カスタム AI エージェント構成*
エージェントがすべての取引を抽出した後、自動化プロセスは「複数ケース作成」アクションを使用してバッチ処理でケースを作成します。ここではケースタイプとして「銀行取引」を指定し、エージェントの出力テーブルをカスタムデータソースとしてマッピングするとともに、「参照」列を各ケースの一意な ID として割り当てます。以下の画像には、ワークフロー内のバッチケース作成構成が表示されています。
*図 4: 複数ケース作成*
作成後、各ケースにはカスタム属性として完全なトランザクションデータが含まれます。ケースレコードには、ケースステータス（Ready）、参照名、ケースタイプ（Bank Transaction）、および銀行名、口座番号、取引日、説明、タイプ、金額を含むカスタムデータフィールドが含まれています。以下の画像は、ケーステーブルとその主要コンポーネントを示すMonitorダッシュボードです。
原文を表示
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.
Status
Description
How case enters this Status
What happens next
Ready
Workflow generates new cases available for processing
Workflow generates a new case
Workflow consumes the case and begins execution
In Progress
Workflow actively processing the case
Workflow starts processing a *Ready* case
Case moves to *Successful*, *Failed*, or *Pending Resolution*
Successful
Case has completed each step without errors
Each step within Process case finished without exceptions
Terminal state. No further processing occurs.
Failed
Case finished with a business or system exception
An exception is raised during processing
Terminal state – check logs for details.
Pending Resolution
Case paused, waiting for human task completion
A task is created in the Task Center. Case processing is suspended while the system moves on to the next case.
When the task is completed in the Task Center, the case automatically transitions back to the *Ready* state with the associated human input.
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.
Authoring an automation
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.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み