Twice as Fast, Without Leaving the EU: Inside Digicust's August Update

In August, we completed the latest update to Digicust's production agent.

That result is significant, but the more interesting part is what it took to get there. Reaching 65 seconds was not simply a matter of finding a faster model. A production customs agent has to do much more than generate an answer. It works through tariff data, master data and code lists, calls external systems, loops when a case requires it, and handles the commercial information contained in real shipment files. A faster model is useful only if it can do that work reliably within the processing boundaries our customers expect.

That is what makes the August Update worth a closer look. We changed the engine without changing the full customs workflow around it. The primary AI processing continued to run on our EU stack and, if that path failed, the fallback stayed in the EU too.

This is the story of why that combination is hard, how we rolled it out without breaking anyone's day, and what comes next.

Twice as fast, without doing half the work

When processing time drops from 131 seconds to 65 seconds, there is an obvious question: did the agent simply do less?

It did not. The August Update uses the same Digicust agent and the same declaration workflow as the previous setup. During a processing step, the agent can still work through tariff data, check master data and code lists, call connected systems, and loop when a case requires more work.

A typical turn still involved about the same number of tool calls: five compared with six previously, while the median processing time fell from 131 to 65 seconds. In other words, the speed improvement came from completing essentially the same customs work faster, not from stripping the workflow down.

Median time per step

2x faster

131 sPrevious Balanced

65 sAugust Update

Median credits per step

About 15% lower

2.10Previous Balanced

1.78August Update

Tools used per step

Same full workflow

6Previous Balanced

5August Update

But showing that a new model can work faster is not enough to put it into production. Before making it available to customer workflows, we still had to prove that it could handle the complete agent workload and meet the same production requirements as the setup it was replacing.

Getting a faster model safely into production

Finding a faster model was a good start. However, the harder part was making sure it could be introduced into a live customs environment while still meeting the same production requirements as before.

For this update, that meant passing several checks before the new model could become our recommended engine. It had to run on EU-based infrastructure with the full Digicust tool set attached and hold up under the workload of a real agent turn. We also had to test not only the primary processing path, but what happened when that path ran into trouble.

That last point is particularly important because customs files contain information such as consignee names, invoice values, commodity codes and origin. Keeping the primary model in the EU is therefore only part of the picture. If that model stalls during a case, our routing can move the work to a fallback model. That fallback matters just as much for where customer data is processed.

For this update, the backup processing stayed in the EU too, routing to the proven model behind our previous Balanced setup. A fallback should not mean falling outside the processing boundaries customers expect.

Still, passing those technical checks was not enough for us to switch everyone at once. The August Update first went into a live pilot with a high-volume broker, covering roughly 200 cases. Processing time was about half, quality held, and no model errors appeared during the pilot window. We continued watching it over the weekend before moving further.

Ten days after the first implementation, the August Update became our recommended default. New agent workflows, which we call strategies in Digicust, received it automatically, while existing ones stayed on their current setup until someone on the desk chose to switch. Larger accounts could therefore move gradually rather than changing every workflow at once.

The speed improvement continued beyond the pilot

The first results came from a controlled pilot. The more important test was what happened as the update moved into everyday customer traffic.

Across the full measurement period from 1 July to 2 September, we recorded 6,841 customer agent turns on the August Update. Test and demo accounts were excluded. The median processing time was 65 seconds, compared with 131 seconds on the previous Balanced setup. That is a 2x improvement, now measured across real customer traffic rather than only the initial pilot.

Agent turn

Processing step, including tools

131 sPrevious Balanced

65 sAugust Update

Wait in the conversation

What the clerk sees

134 sPrevious Balanced

67 sAugust Update

But we wanted to see whether that difference would remain as more customers moved over. Looking only at the final 14 days, when the update was already handling 63% of customer cases, the median was 68 seconds compared with 129 seconds on the previous setup. The gap had narrowed slightly, but the speed improvement was still 1.9x under mixed production traffic.

Importantly, this was not visible only in our backend measurements. The wait a clerk actually experiences in the conversation followed the same pattern: the median time from an AI message appearing to completion fell from 134 seconds to 67 seconds over the full measurement period.

Medians, not miracles

Twice as fast is the headline number, but in production customs work, typical performance matters more than the fastest individual case.

The 65-second result is a median: half of the measured agent turns finished faster and half took longer. More complex cases can still require longer runs, particularly when the agent needs additional tool calls or loops to complete the work. Looking further into the distribution, at the 95th percentile, processing time moved from 369 seconds to 301 seconds. The improvement is still there, although naturally smaller than at the median.

Some variation also comes from the infrastructure behind the model. AI processing capacity in the EU is finite and shared, so processing times can change even for similar workloads. If a model stalls during a run, our routing is designed to catch it and move the work to the fallback path, which also remains in the EU.

We therefore focus on the median rather than the best-performing cases. It gives customers a more realistic picture of what they can typically expect in production.

What faster processing means on a customs desk

The difference between 131 seconds and 65 seconds becomes even more meaningful when it repeats across a full working day.

Customs teams process documents, review classifications, check declarations and deal with exceptions throughout the day. Each time the agent responds faster, there is less waiting between those tasks. At a busy desk, those shorter waits can add up to hours.

55 min50 steps

1.8 h100 steps

3.7 h200 steps

7.3 h400 steps

Agent processing steps per day on a desk

The numbers in the graphic are illustrations based on the median processing times, not a promise that every team will save exactly the same amount of time. Different cases require different amounts of work. But they show why improving processing speed matters beyond the performance numbers themselves.

For customs teams, the goal goes beyond making AI respond faster. It means spending less time waiting on routine processing and more time on the cases that actually need human attention.

What comes next

The August Update is something we are proud to have achieved. But we do not stop there. AI models are improving quickly, and every new generation gives us another opportunity to ask: can we make customs work better again?

For us, continuous improvement is part of the product. A newer model alone does not automatically make a better customs agent. It still has to work with the tariff context, master data, validation rules and workflows around it, and prove itself under the same production requirements. That is what allows us to bring new AI capabilities into customs workflows without rebuilding everything around them.

The next step is already underway. The next model generation has passed its first qualification step on EU-based infrastructure, with the remaining checks now in progress. If it passes, it will follow the same path we used in August: testing with the complete agent, real customer traffic and a controlled rollout.

We have seen what one update can do. Now we are eager to see how much further the next one can take us.

The September update is already in qualification. We look forward to sharing those numbers soon.

Explore how Digicust automates customs declaration workflows while customs teams retain control of exceptions and approvals.