Hvad må agenten egentlig gøre?

Indkøbsafdelingen vil have hjælp til ændrede leveringsdatoer. Men hvad skal agenten gøre? Læse leverandørens mail, ændre indkøbsordren eller skrive til kunden? Brug dette tænkte eksempel til at skille opgaven ad. Skriv hver handling på sin egen linje med kilde, systemet der skal ændres, felter og ønsket resultat. Begynd med en sammenhængende opgave, som medarbejderne faktisk kan tage ansvar for, og lad resten stå uden for forsøget.

En aftale kan lyde: Agenten må læse den tilknyttede ordre og foreslå en ny dato. Den må ikke ændre pris, leverandør eller betalingsoplysninger. En indkøber skal godkende datoen. Først efter en bekræftet opdatering må agenten klargøre en besked til kunden. Tilpas eksemplet til jeres egne regler. De skal afgøre, hvem der må give agenten lov, og hvilke undtagelser en anden person skal tage stilling til.

Dify beskriver rollen Editor som den, der ændrer apps og vidensbaser, mens Normal bruger publicerede apps. Workato beskriver, at Enterprise MCP handler med den autentificerede brugers identitet og adgang efter rolle.^1,2,3

Det første handler om at ændre agentens opsætning. Det andet handler om den konto, agenten bruger til arbejdet. Skriv begge dele ned. En indkøber kan have lov til at bruge agenten uden at måtte ændre dens regler. En udvikler bør omvendt ikke få adgang til alle indkøbsordrer alene ved at have adgang til byggeren. Få forskellen vist med den medarbejderrolle, I faktisk vil bruge.^1,2,3

Følg også oplysningerne: Hvilke dokumenter hentes, hvilke felter sendes til en model, og hvad ender i loggen? Skriv formålet ved hver modtager. Lad it- og databeskyttelsesansvarlige vurdere ruten og aftalerne bag den. Et generelt løfte om central styring fortæller ikke, hvilke systemer og modtagere der får oplysninger i netop jeres opgave. Det skal stå på jeres egen oversigt.

Forbered en normal datoændring, en sag med uklar ordrematchning, et forslag om at ændre et forbudt felt og en sag uden svar fra godkenderen. Brug ufølsomme prøveoplysninger, og aftal testmiljøet. Skriv det ønskede resultat før mødet: forslag, afvisning, ventende sag eller bekræftet ændring. Forklar leverandørerne, hvad I undersøger, og hold fast i de samme cases. En lettere demonstration besvarer ikke det spørgsmål, I kom med.

Nexus beskriver, at den første procedure bygges sammen med teamet og vises i dets egne værktøjer. Kore.ai nævner Forward Deployed Engineers i sit tilbud.^4,5

Brug tilbuddet om hjælp til at aftale, hvem der gør hvad. Leverandøren kan hjælpe med at bygge, men I skal fastlægge, hvad agenten må. Bed hver leverandør skelne mellem det, der kan vises nu, det der skal sættes op, og det der skal udvikles. Skriv også navn på den hos jer, som skal skaffe systemadgang eller sørge for, at godkenderen deltager. De opgaver skal være synlige i planen.^4,5

Saml formål, tilladte handlinger, forbudte felter, konti, godkenderrolle, fejlvej og driftsansvar i ét dokument. Tilføj, hvordan aftalen ændres: Hvem kan foreslå mere ansvar til agenten, hvem vurderer risikoen, og hvad skal vises igen? At gå fra at foreslå en dato til at bekræfte den over for kunden er en større opgave. Det gælder, selv om agenten beholder sit navn, og ændringen ser lille ud på skærmen.

Lad fagteamet og it læse aftalen sammen, før forsøget får lov til at ændre rigtige data. Den ansvarlige for arbejdet skal kunne forklare normalforløbet og finde ventende sager. Den tekniske ansvarlige skal kunne vise, hvor grænserne håndhæves. Brug resultaterne fra demonstrationen til at markere det, der endnu mangler bevis. Underskrifter alene er ikke nok. Dokumentet skal hjælpe den næste kollega med at vælge og drive løsningen.