Over an intensive 8.5-hour engineering sprint, I orchestrated an autonomous multi-agent swarm to architect, code, test, and harden JurisBanking—a full-stack MERN settlement payment distribution system built for class-action administration. What emerged was not an unverified AI prototype or a fragile collection of scripts, but a hardened financial distribution engine backed by 545 Vitest unit and integration tests, 84 master end-to-end acceptance scenarios, and a custom commercial source-available license. Here is the unvarnished architectural retrospective of how the swarm operated, the adversarial verification crucible that prevented catastrophic test pollution, and why native Linux execution outperformed containerized setups.

1. The Settlement Administration Problem: Zero-Tolerance Financial Logistics

Class action and mass tort settlement administration represents one of the most unforgiving domains in modern software engineering. When a court approves a multi-million-dollar fund distribution, legal administrators must ingest messy claimant rosters containing tens of thousands of records, sanitize contact details, deliver localized notifications across multiple languages, collect verified payment choices, and reconcile payouts across banking interchanges.

In this ecosystem, minor edge cases cascade into severe liabilities:

• Routing Transit Verification: An invalid routing number in an Automated Clearing House (ACH) direct deposit triggers NACHA return fees (such as R01 insufficient funds or R03 account not found) and delays disbursements past statutory deadlines.
• Deadline Enforcement & Default Fallbacks: If a claimant fails to submit a preference by the court-ordered deadline, the system must deterministically freeze modifications and re-route the disbursement to a legally approved fallback rail (such as a physical paper check).
• Interchange Security: Financial batch transmissions to banking interchange partners like Dash Solutions (formerly Prepaid Technologies) must strictly adhere to fixed-width or delimiter-separated SFTP record layouts, complete with header batches, detail rows, trailer checksums, and cryptographic hash verification.

Automating this pipeline requires seamless coordination across role-based access control, cryptographic tokenized magic links, streaming file ingestion, rich-text templating, multi-rail payouts, background job queues, and automated report reconciliation.

2. The 8.5-Hour Autonomous Swarm Architecture

Rather than relying on a single, overburdened language model attempting to write a monolithic codebase in a linear context window, we deployed a specialized multi-agent swarm. Running continuously from 02:40 to 11:38 UTC, the swarm operated under strict operational boundaries, divided into hierarchical roles with decoupled responsibilities.

The milestone workers executed against six rigorously defined engineering milestones:

1. Milestone 1: Identity & Access Management (RBAC): Fail-closed authentication using signed JSON Web Tokens in HTTP-only cookies, password hashing with bcrypt, argon2 salt derivation, and strict role hierarchies (Super Admin, Law Firm Admin, Case Manager, Auditor, and Tokenized Claimant).
2. Milestone 2: Case Lifecycle & Streaming Ingestion: Roster ingestion supporting streaming CSV and Excel (.xlsx) parsing via multer, schema validation with Zod, and a two-stage preview pipeline allowing case managers to audit parsed allocations before committing records to MongoDB.
3. Milestone 3: Localized WYSIWYG Template Engine: React-Quill integration enabling law firms to craft settlement notices and claimant portal copy. Dynamic merge tags ({{claimant_first_name}}, {{settlement_amount}}, {{payment_selection_link}}) are processed through server-side HTML sanitizers, complete with multi-language localization across English, Spanish, Chinese, and Vietnamese.
4. Milestone 4: Claimant Payment Portal & 9 Disbursement Rails: A responsive, accessible mobile-first portal supporting 9 payment options: Direct Deposit (ACH with routing transit checksums), Digital Visa/Mastercard, Push to Debit Card, Physical Paper Check, PayPal, Venmo, Zelle, Bitcoin, and Automated Case Fallback.
5. Milestone 5: Dash Solutions SFTP Engine & NACHA Reconciler: Automated generation of outbound financial batch files (DASH_DISBURSE_{CASE_ID}_{TIMESTAMP}.csv) transmitted via SSH2 SFTP client with SHA-256 checksums, paired with a reconciliation parser handling inbound status reports and NACHA return codes (R01 through R85).
6. Milestone 6: Agenda Job Scheduling & Agendash UI: Native MongoDB-backed background job processing orchestrating throttled notification delivery, deadline enforcement sweeps, periodic SFTP polling, and a secured administrative dashboard mounted at /admin/scheduler.

3. The Technical Crucible: Database Collisions & The Binary Veto

Autonomous agent systems frequently fail when software complexity increases because automated assistants tend to take shortcuts—patching unit tests with fake mocks, dumbing down assertions, or skipping integration testing when suites turn red. In our swarm, this failure mode was completely blocked by the Adversarial Verification Panel.

During the integration phase of Milestone 5, the adversarial challengers launched a 558-line multi-loop concurrency suite to test simultaneous batch dispatches and claimant submissions. The test suite immediately experienced intermittent red failures:

MongooseError: Connection closed before operation could complete
MongoServerError: ns not found: juris_banking_test.claimants
AssertionError: expected claimant.status to be 'disbursed', got 'pending'

When the milestone workers initially investigated, they proposed mocking the database layer or running test suites with the --no-threads flag to serialize execution. The Forensic Auditor immediately stepped in and enacted an unconditional binary veto. Mocking the database in a financial distribution engine is unacceptable: transactional integrity, unique index constraints, and atomic document updates must be verified against actual database engines.

Upon deep forensic analysis, the explorers discovered the true root cause: Vitest runs test suites across concurrent worker threads by default. Multiple test files were connecting to the same default database name (juris_banking_test). When one test suite completed and executed its afterAll(async () => await mongoose.connection.dropDatabase()) hook, it wiped the collections out from underneath parallel suites currently executing assertion checks!

The solution was to engineer dynamic per-suite test isolation. Instead of connecting to a static database, each test file dynamically hashes its own filename and establishes a fully isolated MongoDB namespace:

import crypto from 'node:crypto';
import mongoose from 'mongoose';

export function getIsolatedTestDatabaseUri(suiteFile: string): string {
  const hash = crypto.createHash('md5').update(suiteFile).digest('hex').slice(0, 8);
  const baseUri = process.env.MONGO_TEST_URI || 'mongodb://127.0.0.1:27017';
  return `${baseUri}/juris_test_${hash}`;
}

export async function setupIsolatedSuite(suiteFile: string) {
  const uri = getIsolatedTestDatabaseUri(suiteFile);
  await mongoose.connect(uri, {
    serverSelectionTimeoutMS: 5000,
    autoIndex: true,
  });
}

With dynamic per-suite namespaces and isolated test clients, all 41 test files ran concurrently without a single namespace collision, open handle leak, or connection drop.

4. The Payment Interchange Engine: Dash Solutions SFTP & NACHA Reconciliation

The core financial pipe of JurisBanking connects law firm settlement accounts to Dash Solutions over secure SFTP. To guarantee complete offline developer productivity and continuous integration testing without needing live bank sandboxes, we built a native, self-contained mock SFTP server using the ssh2 library in fixtures/mock-sftp/.

The outbound interchange engine compiles all approved claimant payment selections into structured batch files. Each batch is formatted with Header Records, Payment Detail Records, and Batch Trailer records:

HDR,JURIS_BANKING,DASH_SOLUTIONS,2026-10-04,BATCH_00941
DET,CLM_882910,ACH,400.00,021000021,123456789012,C,John,Doe
DET,CLM_882911,CARD,400.00,janesmith@example.com,,,Jane,Smith
DET,CLM_882912,CHECK,400.00,742 Evergreen Terr,Springfield,OR,97477,Homer,Simpson
TRL,3,1200.00,000941

Prior to transmission over SFTP, the engine computes a cryptographic SHA-256 digest of the payload and records it in the database audit log. When Dash Solutions processes the disbursement batch, it drops status reconciliation CSV reports into the remote /outbound/reports directory.

The Agenda scheduler polls this directory every hour, retrieves new report files, and triggers the reconciliation engine. If a direct deposit returns an R03 code (No Account/Unable to Locate Account) or an R01 code (Insufficient Funds), the engine flags the claimant record, sets the status to exception_flagged, records the NACHA description in the audit ledger, and automatically notifies the case manager via the exception dashboard.

5. Native Linux Engineering: Why We Rejected Docker Indirection

Throughout the build, we strictly adhered to a foundational systems preference: native host installations over Docker containers. The entire stack—Node.js 20, MongoDB 7.0, mock SFTP servers, and Agenda worker processes—ran directly on the native Linux host environment.

This architectural choice yielded measurable advantages:

• Zero Hypervisor / Virtualization Overhead: Running databases and test runners inside Docker introduces file I/O latency, container network bridging lag, and bind-mount synchronization overhead. On native Linux, MongoDB executes with direct memory-mapped file access, enabling test suites to complete in fractions of a second.
• POSIX Socket & Process Telemetry: Native execution allows debugging tools, OpenTelemetry daemons, and systemd service monitors to interact directly with process PIDs and local Unix domain sockets without network proxy gymnastics.
• Deterministic SFTP Port Binding: Our mock SFTP server bound directly to loopback ports without NAT port-forwarding issues or dangling container sockets, eliminating spurious connection timeouts during high-concurrency integration tests.

6. Commercial Source-Available Licensing: Protecting IP Without Sunsets

Once the system passed all verification gates, the question arose: how should this software be licensed?

Permissive open-source licenses like MIT or Apache 2.0 would allow large class-action claims administrators and legal tech conglomerates to fork the codebase, host it as a managed service, and generate millions in processing fees without compensating the creator. On the other hand, the popular Business Source License (BSL 1.1) mandates a conversion date—typically four years—after which the code automatically reverts to a permissive open-source license.

For a mission-critical financial distribution system, a sunset clause makes little commercial sense. Instead, we authored the JurisBanking Commercial Source-Available License (Version 1.0):

This model achieves the ideal balance: total transparency and auditability for potential clients and legal teams, accompanied by ironclad protection of intellectual property and direct commercial licensing agreements for production operations.

7. Verification Metrics & Public Release

At the conclusion of the 8.5-hour engineering cycle, the Victory Auditor executed an independent, three-phase forensic audit to verify platform readiness:

• 545 Vitest Unit & Integration Tests: 41 test files spanning RBAC, claimant parsing, localized WYSIWYG sanitation, Dash SFTP batch generation, and Agenda job handlers.
• 3-Loop Flake Hardening (1,635 Total Executions): The entire test suite was executed across three consecutive zero-flake loops, achieving 100% green passing rates on every cycle.
• 84 Master End-to-End Acceptance Tests: Validating full multi-rail claimant payment selection workflows, deadline fallback enforcement, and reconciliation ledgers.
• Clean Public Repository: Packaged and published to GitHub with comprehensive documentation, architecture diagrams, and licensing terms.

The entire repository is now live and publicly viewable on GitHub at https://github.com/rbaindourov/juris-banking-settlement-payment-automation. It stands as concrete proof of what disciplined autonomous agent orchestration can accomplish when constrained by rigorous adversarial review, native systems architecture, and relentless engineering standards.