How the AI agents work

The atomic units that do the work on every Aduaria entry. Each agent, explained — one MD per agent: what it does, the contract, how it's built (model, prompt, retrieval), and how it stays grounded. It's the source of truth for how each agent works today. The methodology + roadmap (model choice, GRI, GRI×CROSS, improvement plan) live in How the AI classifies goods; the cross-agent map + shared infra live in AI architecture.

What counts as an "agent" here

We use the word loosely. Three senses, all worth tracking in one place:

1. LLM agents — a single Claude call with a tightly-scoped prompt, structured (Zod-validated) output, and prompt caching. Single-purpose by design. Not autonomous loops.
2. Deterministic services — code, not models, but they do agent-like work (decide, score, route). Worth specifying alongside the LLM agents because the broker can't tell which is which from the UI, and a customs audit can't either — both need to be defensible.
3. Orchestrators — single-purpose pipelines that compose the agents above into a user-facing artifact (a landed cost estimate, a CBP response package). They don't add their own LLM call; they assemble what the upstream agents already produced. Listed as agents because they have the same contract shape (typed input, structured output, documented when-they-fire) and the user-facing surface treats them as units.

We run exactly one tool-using agent — the Aduaria Copilot ("Ask Aduaria," below) — which lets Claude call the platform's real services as tools and chain them to answer a broker's question. It is supervised by construction: read-only tools auto-run; every write is broker-confirmed. We do not run unsupervised, self-committing agent loops on customs work. Every number on a filed entry must trace to a regulatory source or a documented model — an open-ended agent loop that files on its own is not defensible to CBP, to a bond underwriter, or in a 19 USC 1592 penalty proceeding.

The lineup (today)

Composition

These aren't isolated. The Simulation pipeline (the demo you'd run for an investor or a prospect) chains them like this:

PDF
 │
 ▼  Document Extractor (LLM)              ─── structured invoice ───┐
                                                                    │
 ▼  HTS Classifier (LLM, RAG-grounded)    ─── 10-digit HTS + conf ──┤
                                                                    │
 ▼  Denied-Party Screener (deterministic) ─── block / review / clear┤
                                                                    │
 ▼  Duty Calculator (deterministic)       ─── 50% effective stack ──┤
                                                                    │
 ▼  Risk Modeler (deterministic)          ─── $22K-$94K range ──────┤
                                                                    │
                                          ╔═══════════════════════╗ │
                                          ║ SimulationResult      ║◄┘
                                          ║ + Methodology citation║
                                          ╚═══════════════════════╝

The two LLM calls happen in parallel where possible. The deterministic services run after the LLM ones because they need the classified HTS code to do their work.

What we deliberately don't have (yet)

• No unsupervised write loops. The Copilot is tool-using, but read-only tools auto-run and every write is broker-confirmed — Claude never commits a change to a filed entry on its own. A Phase-2 Autopilot variant that watches CBP CSMS messages and proposes exclusion requests is a candidate, but only after the data flywheel is rich enough to evaluate it — and it would still propose, not self-file.
• No multi-modal agents that compose freight + customs + payment. Freight rates are scoped (Freightos / Xeneta integration). Until then, freight is out of the Simulation explicitly (see methodology §What's NOT in the simulation).