Nyheden kort
Alvys lancerer Foundry, et agentisk AI‑lag, der kører inde i virksomhedens transport management system. Det fremgår af Alvys’ udmelding i ArtificialIntelligence‑News. Her beskriver Alvys en platform, der kan automatisere driftsopgaver via agenter, som arbejder på TMS’ egne data og workflows. De centrale detaljer om funktioner, +20 skabeloner, +120 integrationer, SOC 2 og modelaftaler stammer fra Alvys’ udmelding og er ikke uafhængigt bekræftet.
Alvys’ CEO Nick Darman siger i kilden: “We have the freight context and we understand your lanes.” Det er hele afsættet: agenterne skal handle på den kontekst, der allerede bor i TMS’et, frem for at være et eksternt lag.
Hvad er Foundry teknisk
I kilden beskrives Foundry som en agentmotor, der “er designed to carry out defined steps in freight workflows”, med adgang til lane‑historik, kunderegler, dokumenter, marginopsætning, aftaler og undtagelser. Altså ikke kun at pege på en afvigelse, men også at udføre godkendte trin i et flow.
Kørsel inde i TMS’et betyder ifølge Alvys færre separate logins og mindre integrationsvedligehold. Det kan være praktisk. Til gengæld bliver man afhængig af TMS‑leverandørens governance, kapacitet og release‑tempo. Det bør adresseres i SLA og beredskab fra start.
Hvilke opgaver kan automatiseres
Kildeteksten lister en række brugsscenarier: En Detention Agent kan identificere, når detentionstid er overskredet, og “file the detention”. Det kræver som regel kontraktlige rammer og kundegodkendelser i praksis, så gatekeeping må være skarp, før fuld eksekvering åbnes.
Der nævnes også Document Intelligence, der læser og arkiverer ratekonfirmationer, BOL’er og POD’er. En Track & Trace‑agent håndterer check calls og statusopdateringer. Dertil en Rate Audit Agent til fakturatjek, en Asset Compliance‑agent til myndigheds‑, forsikrings‑ og sikkerhedsoptegnelser og en Claims Agent til oprettelse og dokumentation af skadesager. Alle er eksempler fra Alvys’ udmelding.
Skabeloner og tilpasning
Alvys siger, at Foundry rummer “more than 20 pre‑built agent templates”. Dertil kan kunder skabe egne eller samarbejde med Alvys’ ingeniører. Ifølge kilden: “operators can upload an existing standard operating procedure or describe a task in plain language, after which Foundry generates a workflow for approval.” Det kan afkorte implementeringstiden, hvis SOP’er og felter faktisk afspejler realdrift.
Er SOP’er eller mappings slørede, flytter man bare fejlene ind i en hurtigere maskine. Start smalt, lås valideringsreglerne, og lad først økonomisk følsomme trin køre med approvals indtil data og tærskler holder vand.
Test, deployment og drift
Kilden anfører: “Agents can be tested against simulated data before deployment on live freight.” Derudover kan operatører “build, deploy, monitor, and pause them through the Foundry platform.” Det er de væsentlige driftskontroller samlet ét sted.
Hvordan testdata skabes, hvilke nøjagtighedskrav anbefales, og om sandbox er tæt på produktion, står ikke beskrevet. Betragt det som uafklaret, indtil Alvys leverer dokumentation. Pause og rollback er i øvrigt ikke pynt: det er hverdagsværktøj, når en regel rammer ved siden af.
Sikkerhed, governance og sporbarhed
Alvys fremhæver et governance‑lag kaldet Agent Shield med approvals og forbrugstærskler per agent. Ifølge kilden logges agentbeslutninger, handlinger og manuelle overrides i et audit trail. Det lyder rigtigt for sporbarhed; de afgørende detaljer er retention, eksport og hændelsesgranularitet.
Alvys skriver også, at Foundry kører på et SOC 2‑kompatibelt fundament, og at aftaler med modeludbydere forhindrer træning på kundedata. Det er Alvys’ egne udsagn. Bed om scope for trust services‑kategorier, systemgrænser, seneste auditdato og navngivne modeludbydere med driftsmodel (on‑prem, Alvys’ cloud eller tredjeparts‑API). Uden det kan man ikke lave en ordentlig risikovurdering.
Integration og driftseffekter
Alvys angiver, at Foundry trækker på TMS’ eksisterende infrastruktur med “more than 120 integrations” og native EDI‑forbindelser til hundredvis af afsendere. Hvis det holder, kan idriftsættelse gå hurtigere, fordi dataflowet allerede er kendt.
Men tempoet følger TMS. Hvis en ekstern løsning kan patches på et døgn, mens TMS releaser månedligt, kan en kritisk fejl hænge for længe. Byg derfor change‑vinduer og fallback ind i driftsplanen.
Tjekliste til implementering
- Start med et lavrisiko‑flow som pilot, fx læsning og arkivering af ratekonfirmationer.
- Definér inputfelter, fejlmarginer og mål: behandlingstid, fejlrate og andel med manuelt touch.
- Ryd op i datakvalitet: navngivning, tidszoner, enheder, undtagelser. Dokumentér felt–kilde–ejer.
- Tænd Agent Shield‑approvals på alle økonomisk følsomme handlinger i fase 1.
- Etabler en reel rollback‑plan: stop hurtigt, fortryd massehandlinger ordentligt, og hold kundekommunikation ren.
- Opsæt monitorering: alarmer på undtagelser, kø‑længde, håndteringstid og modeludgifter.
Økonomi og performance
Mål effekten, ikke fornemmelsen. Minutter pr. detention‑claim før/efter, fakturanøjagtighed, andel sager med manuelt touch. Track undtagelser over tid: kø‑størrelse, eskaleringer og gennemsnitlig håndteringstid. Så kan I se, om arbejdet blev mindre eller bare flyttet.
Kilden nævner også et modelvalgssystem, der kan rute opgaver mellem sprogmodeller efter pris, hastighed og kvalitet. Det kan styre omkostninger, men kræver stram output‑audit pr. model, især i dokumentforståelse.
Markedsplacering og konkurrence
Mange agentløsninger lever som add‑ons. Her lægger Alvys laget ind i TMS‑kernen, hvor data, regler og godkendelser bor. Om det er stærkere, afgøres i praksis af governance, sikkerhed og performance under spidsbelastning — ikke af antallet af skabeloner.
Som generel kontekst viser nyere modelteknologi, at agenter også kan køre lokalt eller hybridt. VentureBeat beskriver fx, at en Qwen3.8‑model kan køre uden cloud‑API. Den kilde omtaler ikke Alvys, men indrammer kundekrav om edge‑/hybridkørsel af hensyn til data og latency.
Risici og begrænsninger
Automationsfejl sker. I detention kan tidszoner, appointment‑ændringer og uens tidsstempler give falske positiver. En forkert claim koster efterarbejde og kan slide på relationer. Dokumentforståelse vælter let på dårlige scanninger eller skiftende layout.
Et kort, hypotetisk billede: En agent filer 30 detention‑claims, fordi en mapping læser appointment time som departure. Uden gatekeeping går kravene ud. Et sundt setup havde fanget outlieren i forslagstilstand, stoppet agenten, rullet de 30 sager tilbage, logget beslutningsgrundlaget og genkørt med rettet regel.
Spørgsmål til Alvys
- SOC 2: Hvilke trust services‑kategorier og systemgrænser er omfattet, og hvornår er seneste revision?
- Modeller: Hvilke modeludbydere understøttes, hvor kører inferens, og hvordan håndhæves forbud mod træning på kundedata?
- Arkitektur: Kører agenter i en TMS‑hostet runtime, som container‑jobs eller via eksterne orkestratorer? Typisk latenstid/throughput?
- Testdata: Hvordan genereres simulerede data og edge cases, og hvilke acceptkriterier anbefales før go‑live?
- Skabeloner: Fuld liste over de +20 templates med inputkrav, output og standardfejl‑behandling.
- Integration: Kræver Foundry nye mappings oven på eksisterende EDI/API, og hvor meget manuel konfiguration ved første udrulning?
- Governance: Standard‑approvals, tærskler og håndtering ved konflikt mellem agentforslag og menneskelig afgørelse?
- Ansvar: Hvem bærer risikoen ved fejlagtig agent‑handling, og hvordan er det reguleret kontraktuelt?
Konklusion og næste skridt
Foundry markerer et skifte, hvor agentbaseret AI flytter ind i TMS‑kernen. Ifølge Alvys kan platformen automatisere centrale driftsopgaver, levere sporbarhed via Agent Shield og tilbyde både pre‑build og tilpassede agenter. Påstande om SOC 2, integrationsomfang og modelaftaler bør valideres, før man går bredt i produktion.
Næste skridt er lavpraktiske: vælg et smalt pilot‑scope, få SOP og mappings på plads, tænd approvals, mål hårdt på effekt og få svar på dokumentationsspørgsmålene ovenfor. Forskellen mærkes først, når agenterne kører på rigtige sager med klare målepunkter.
