Pause-resume runtime for customs brokers that automates day-long entry exceptions without paying GPU rates while waiting on portals.

1. Sail's up-to-10x cost reduction from suspending agents during idle waits turns the core economics of customs exception automation from speculative to immediately testable.
2. Support for tasks that span hours or weeks matches the real shape of customs exception cases, which often sit idle between bursts of action and therefore need persistent rather than always-on agent infrastructure.
3. The shift from latency-first to throughput-first inference design means infrastructure vendors are finally optimizing for sustained operational workloads instead of chat demos, which is exactly what back-office brokers require.
4. OpenAI-compatible APIs and cross-provider workload control mean a brokerage can adopt this runtime on top of its current models and cloud choices instead of waiting for a single end-to-end vendor stack.

Catalyst. Sail's verified suspend-on-idle architecture and 10x cost proof make long-running agent workflows commercially viable now for back-office operations that were previously too wait-state-heavy to automate end to end.

The product is a checkpointed agent runtime plus case orchestration layer built for asynchronous operations workflows. It wraps browser sessions, document parsing, model calls, and inbox actions into a single resumable case record that can sleep safely between events without losing state. When a carrier portal changes status, a customer replies with a missing commercial invoice, or an internal broker approves a classification decision, the runtime wakes the exact case context and routes the next action to the right model, browser worker, or human reviewer. Teams get a dashboard that shows active versus sleeping cases, per-case compute cost, exception aging, and replayable audit logs for every decision and handoff.

What's different. Browser automation vendors focus on click reliability and enterprise agent platforms focus on model quality, but neither is built around the economics and state management of cases that spend most of their life waiting. This company combines resumable execution, event-triggered wake-ups, and cost accounting at the case level for a workflow shape that generic agent stacks treat badly. Over time, reliability data on which triggers, portals, and human handoffs cause stalls becomes a defensible dataset that improves routing, retry logic, and pricing.

Jobs to be done

flowchart LR
  Buyer[Customs brokerage ops leader] --> Pain[Entry exceptions wait across portals email and CBP responses]
  Pain --> Product[Checkpointed pause-resume agent runtime]
  Product --> Outcome[Lower cost faster release and auditable case handling]

Executive takeaways

• This is a real but narrow beachhead. The pain is strong enough for a compelling first product, but venture scale requires expansion beyond customs entry exceptions into adjacent trade workflows.
• The sharp wedge is not smarter models alone. It is cheaper, safer waiting. Customs work spends much of its life paused for portals, documents, status updates, and approvals.
• Technical feasibility is now proven by long-horizon agent infrastructure, durable workflow engines, and persistent browser session tooling, but none of them ships as a customs-native operating layer.
• Competitive intensity is medium high because customs incumbents already own filing workflows and horizontal orchestration vendors already sell pause-resume primitives.

Market definition

The relevant market is workflow-runtime and control-plane software for wait-state-heavy customs and trade-compliance exception cases. The product sits between horizontal durable execution infrastructure and vertical customs systems, turning multi-day entry exceptions into auditable event-driven cases that can sleep, wake, and hand off cleanly.

Customer and buyer

Daily users are customs exception desks, automation engineers, and branch operations managers who keep entries moving across ACE, carrier portals, EDI feeds, and inboxes. The economic buyer is typically the CTO, COO, or GM who owns brokerage throughput, automation budgets, and compliance risk.

Buying triggers

• A brokerage hits backlog or service-level pressure during an ACE migration, seasonal volume spike, or systems slowdown and realizes humans are still babysitting stalled entries. [6][17][18]
• Leadership wants paperless and distributed operations, yet teams still rely on phone calls, PDFs, and close handoffs that do not translate cleanly into brittle always-on bots. [10][19]
• Operators see repeated data re-entry across shipment systems, ISF records, entry records, and customer emails and start looking for a runtime that preserves context instead of recreating it. [13][14][16]

Willingness to pay

Willingness to pay is credible because buyers already spend on customs-compliance suites, long-running automation, and browser infrastructure. If the runtime removes re-keying, rejection rework, and idle browser cost on even a modest slice of exception cases, it can attach to an existing compliance and automation budget rather than inventing a new one. [13][14][15][16][20][35][37]

Category dynamics

Growth signal 7.9% annualized rise in Jamaica trade-facilitation and paperless-trade rating from 2017 to 2023

Validation signals

• NCBFAA membership concentration suggests the initial buyer set is reachable because the association represents more than 1,500 member companies handling more than 97 percent of U.S. entries.
• CBP monthly statistics confirm the workload scale is large enough that even a narrow exception wedge can matter operationally.
• FreightWaves reporting on Kewill survey data shows meaningful productivity variation and rejection-related rework in customs operations.
• Sail funding and benchmark claims show investors and builders now believe long-horizon agent economics can improve materially.

Regulatory & technical constraints

• The product has to fit the ACE single window and the entry-summary workflow rather than invent its own system of record for customs events.
• Brokerages must maintain responsible supervision and control and enough licensed-broker oversight for the customs business being automated.
• Permit fees, triennial reporting, and related broker compliance obligations make auditability and operator accountability non-negotiable.
• Authenticated browser state can contain sensitive cookies and headers, so session persistence has to be secured and policy-controlled.

Competition comes from four directions. Horizontal durable execution platforms own checkpointing and timers. RPA suites own human-in-the-loop automation. Customs incumbents own filing data and compliance workflows. Browser and agent infrastructure vendors own session persistence and long-horizon runtime primitives. The gap is a customs-specific case runtime that combines all of those capabilities around paused exception lifecycles and broker-grade auditability.

Why incumbents do not win by default

• Long-horizon AI infrastructure. Sail proves that active-compute billing and pause-resume sandboxes are viable, but it is still horizontal infrastructure rather than a customs-case operating layer.
• Durable workflow platforms. Temporal, AWS, and Azure provide durable timers, replay, and external-event handling, but customers still need to build customs connectors, browser state management, and compliance-specific approval logic themselves.
• Agent orchestration frameworks. LangGraph offers checkpoints, interrupts, and memory, which validates the pattern, yet it is a framework for builders rather than an out-of-the-box customs operations product.
• RPA and agentic automation suites. UiPath already handles long-running jobs, queues, and human tasks, but its center of gravity is generic process orchestration instead of customs-specific case memory and event wake-ups.
• Customs compliance suites. CargoWise, Descartes, and e2open own declarations, filing, and audit workflows, but they do not win by default on autonomous multi-day browser and inbox exception handling.

Customs entry exceptions are a credible first wedge for a pause-resume agent runtime because the work naturally alternates between short bursts of reasoning and long waits for ACE updates, customer documents, carrier portals, and broker approvals. Sail Research and other long-horizon workflow tooling validate that suspend-on-idle infrastructure now exists, and the startup's differentiated claim is to package those primitives as a broker-grade operating layer rather than generic developer infrastructure. The first customer is a U.S. customs brokerage branch or operations hub processing 10,000 or more monthly entries and already spending money on RPA, browser automation, or offshore exception handling. The buying trigger is a backlog spike, missed release SLA, or failed automation pilot that exposes the cost of keeping humans or always-on bots attached to dormant cases. The MVP should be an overlay on one existing customs suite plus a shared inbox and one portal family, with approval envelopes and replayable audit logs so the product fits CBP supervision realities rather than challenging them. Initial pricing should combine an annual hub subscription with usage on active case-hours and resume events, which matches the customer's labor-savings budget and the product's active-compute thesis. The strongest early proof point is a design-partner pilot that cuts exception-case cost by roughly 30 percent and average release time by roughly 20 percent while maintaining reliable wake-ups and traceable decisions. The biggest unresolved diligence gap is how much of target brokerage volume actually falls into multi-day exceptions with enough idle time to support $120k-$150k annual contracts. Because the beachhead market is real but narrow, the company should earn expansion only after it wins one queue, then one branch, then adjacent trade-compliance workflows such as duty drawback, freight claims, and export-control reviews.

Problem

• Exception cases sit 1-3 days across ACE, emails, carrier portals, and human approvals, so current automation pays for idle workers or falls back to manual queues.
• Brokers lack a single replayable case record across bot, browser, email, and human actions, which weakens auditability and slows root-cause analysis when release SLAs slip.

Solution

• A checkpointed case runtime that sleeps browser, model, and tool state when a customs case is waiting, then wakes the exact context on an inbox reply, portal change, ACE event, or broker approval.
• An operator layer with active-versus-sleeping case visibility, per-case cost accounting, approval envelopes, and audit export on top of the existing customs system of record.

Why we win

• The product is built around wait-state economics and case memory, not generic bot reliability or model quality.
• It can land as an overlay on existing customs suites and shared inbox workflows, which reduces rip-and-replace friction.
• Every handled case improves exception routing, wake triggers, and audit history in a domain where supervision and replay matter.

Milestones

flowchart LR
  Wedge[Customs exception wedge] --> MVP[Pause resume case runtime]
  MVP --> Proof[Audit complete ROI pilot]
  Proof --> Expansion[More branches and trade workflows]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 10-15 percent of entry volume in the target branch falls into 1-3 day exception queues with repeated idle waits and multiple human touches.
• An overlay on one existing customs suite, one shared inbox flow, and one portal family can cover enough cases to prove ROI without a rip-and-replace sale.
• Pilot deployments can deliver roughly 30 percent lower cost per exception case and roughly 20 percent faster average release time.
• Licensed-broker leadership accepts approval envelopes and replayable audit history as sufficient control for initial production use.
• The same runtime can expand into adjacent trade-compliance workflows with materially less engineering than the initial customs wedge.

Open diligence questions

• What percentage of entries at target brokerages become multi-day exceptions with enough idle time to justify this runtime?
• Which wake signals are reliable enough in production, including inbox replies, portal updates, ACE events, or document uploads?
• Who actually owns the budget for this product: customs operations, enterprise automation, or IT platform?
• How much implementation work is required to sit on top of CargoWise, Descartes, or similar systems without disrupting existing screens?
• What would make a brokerage choose this overlay over extending UiPath, Temporal, or its incumbent customs suite with services?

Model sanity

• Revenue engine. Base-case revenue comes from turning 21 cumulative starts into 18.2 active paying hub equivalents by Q4Y3 while blended annual value per active hub rises to $181K.
• Must go right. The first three design partners must become repeatable second-queue or second-branch deployments, because the model only works if Y2 and Y3 add 17 starts without a proportional headcount spike.
• Model breaks if. If the partner motion stalls and effective CAC behaves like the downside sensitivity, Y3 revenue falls about $545K and the cash cushion shrinks about $362K before margin scale shows up.
• Next-round proof. The seed story is strongest once the company shows 6-8 production deployments, one partner-led implementation path, and stable 70% gross margin, which is the milestone the $2.4M pre-seed is sized to reach.

Scenarios

Sensitivity

flowchart LR
  Targets[Named brokerages] --> Pilot[Paid pilots]
  Pilot --> Deployment[Active hub or queue deployments]
  Deployment --> Expansion[Second queue or branch expansion]
  Expansion --> Revenue[Subscription plus usage revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash after payroll and operating spend]

Flags: The model needs Y3 blended annual revenue per active hub of $181K, above the conservative $120K SOM math in the research, so usage and analytics attach must be real rather than aspirational. · 18.2 active hub equivalents by Q4Y3 likely still means fewer than 10 brokerage logos, so customer concentration risk remains high even if branch expansion works. · Gross margin improves from 52% in Y1 to 70% in Y3 only if connector reliability and implementation playbooks standardize; a services-heavy reality pushes EBITDA back below zero. · The $2.4M raise leaves a $741.7K base-case cash trough, so round sizing is driven as much by long security-review and integration cycles as by pure burn; a faster proof path could support a smaller round. · The downside scenario goes slightly cash negative, so a stalled partner channel or slower start cadence would likely force a bridge before the planned seed raise. · CAC payback of 7.1 months is good for enterprise software, but it assumes founder-led selling and warm partner intros keep acquisition efficient until the late-Y3 AE hire ramps.

• Conservative buyer adoption. Traditional customs brokerages may move slowly on letting agents own customer-facing exception workflows. Mitigation: Start with human-in-the-loop exception assistance inside one branch, prove backlog and cost reduction, then expand autonomy gradually by workflow.
• Integration brittleness. Carrier portals, inbox formats, and customs-adjacent systems can change often enough to break wake-up triggers or browser checkpoints. Mitigation: Prioritize event sources with stable signals first, build replay and fallback queues into every connector, and price initial pilots with integration support included.
• Incumbent platform bundling. Customs software vendors or horizontal browser-automation platforms could add basic pause-resume features once the category proves valuable. Mitigation: Win on deep case-state modeling, trade-specific audit workflows, and cross-system reliability data that horizontal platforms will struggle to collect early.