Lag arbeidsflytinstruksjoner med din agent

Du trenger ikke starte med et tomt ark når du lager en arbeidsflytinstruksjon. Begynn med å løse en reell oppgave sammen med agenten din. Når resultatet er nyttig, kan du be agenten om å gjøre metoden dere utviklet sammen om til en gjenbrukbar arbeidsflyt.

Agenten lager første utkast. Din rolle er å gjennomgå antakelsene og avgjøre hvor arbeidsflyten trenger tydeligere begrensninger, slik at en kollega kan få et pålitelig resultat.

Hver arbeidsflyt tilhører én agent. Agenten gir den overordnede rollen og kapasitetene; arbeidsflyten beskriver prosedyren og begrensningene for én repeterbar oppgave.

Start fra en vellykket kjøring

Det er enklere å lage en arbeidsflyt etter at agenten har sett oppgaven, kildematerialet, tilbakemeldingen din og et akseptabelt resultat.

1. Gi agenten en reell oppgave og det faktiske inputet den trenger.
2. Gå gjennom resultatet og korriger manglende kontekst, svak begrunnelse eller feil format.
3. Når resultatet er bra, be agenten trekke ut den repeterbare metoden.
4. La agenten utarbeide utkast til arbeidsflytnavn, beskrivelse, instruksjon og eventuelle referansefiler den anbefaler.
5. Gå gjennom utkastet sammen før du gjør arbeidsflyten offentlig.

Du kan spørre:

Gjør det vi nettopp gjorde om til en gjenbrukbar arbeidsflyt for teamet. Utkast navn, beskrivelse og instruksjon. Skilj mellom den gjenbrukbare metoden og detaljer som bare gjelder dette tilfellet. Før vi ferdigstiller, list opp antakelser og begrensninger jeg bør gjennomgå.

Dette gir agenten jobben med å utarbeide utkastet. Det gir deg jobben med å avgjøre hvilke deler som må kontrolleres.

Instruksjonen er et vanlig sted for begrensninger

Arbeidsflytinstruksjonen følger arbeidsflyten og gjelder hver gang den kjøres. Det gjør den til et av de vanligste stedene å definere begrensninger som påkrevde input, godkjente kilder, output-format, kvalitetskrav og handlinger som krever bekreftelse.

Det er ikke det eneste kontrollaget:

Ikke stol på instruksjonsteksten som erstatning for tilgangskontroller. Hvis en handling må begrenses teknisk, bruk agentautorisasjon og tillatelser i tillegg til en tydelig instruksjon.

Gå gjennom agentens første utkast

Du trenger ikke skrive om hver setning. Fokuser gjennomgangen på avgjørelser som er viktige for teamet.

Når skal den brukes?

• Hvilken forespørsel eller situasjon skal velge denne arbeidsflyten?
• Når skal agenten ikke bruke den?
• Er beskrivelsen spesifikk nok til å skille den fra lignende arbeidsflyter?

Hvilket input er påkrevd?

• Hva må en kollega levere før arbeidet starter?
• Hvilket manglende input skal få agenten til å stille et spørsmål?
• Hvilke detaljer hører til hver kjøring i stedet for den permanente instruksjonen?

Hvilke kilder og regler gjelder?

• Hva er systemet for referanse?
• Hvilken vedlagt fil inneholder godkjente vurderingskriterier eller mal?
• Hvis to kilder er i konflikt, hvilken har prioritet?
• Hvordan skal agenten merke fakta den ikke kan verifisere?

Hvordan skal output se ut?

• Hvilke seksjoner eller felt er påkrevd?
• Hvilket detaljnivå er nyttig?
• Trenger output kildehenvisninger, lenker eller en tillitsmerking?
• Hvor skal resultatet sendes når en destinasjon er oppgitt?

Hvor må agenten stoppe?

• Hvilke handlinger krever bekreftelse?
• Skal agenten lage et utkast i stedet for å sende eller publisere?
• Hvilke data må ikke vises i en offentlig arbeidsflyt eller delt resultat?

Dette er begrensningene det er verdt å gjøre eksplisitte. La agenten håndtere formuleringen, og bekreft at teksten gjenspeiler dine avgjørelser.

En struktur dere kan gjennomgå sammen

Agenten kan bruke følgende struktur for sitt første utkast. Behandle det som et rammeverk for gjennomgang, ikke et skjema du må fylle ut selv:

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

En enkel arbeidsflyt trenger kanskje bare noen få seksjoner. En arbeidsflyt med høy risiko kan trenge mer eksplisitte kilde-, validerings- og godkjenningsregler. Be agenten holde instruksjonen så kort som mulig uten å skjule avgjørelser teamet er avhengig av.

Eksempel: samskap en lead-kvalifiseringsarbeidsflyt

Anta at du ber agenten undersøke en innkommende lead og lage et utkast til svar. Under kjøringen korrigerer du selskapsstørrelse, forklarer at CRM er referansesystemet, bruker teamets ICP-mal og ber om en kortere e-post.

Når resultatet er godkjent, ber du agenten gjøre samtalen om til en arbeidsflyt. Agenten utarbeider prosedyren. Du legger så til begrensningene som skal gjelde utover denne leaden:

• sjekk CRM før offentlig research;
• bruk vedlagt ICP-mal for vurdering;
• siter kilder for selskapsstørrelse, lokasjon og nåværende rolle;
• merk et ikke-verifisert påkrevd faktum som Ukjent;
• returner Kontosammendrag, Bevis, ICP-score, Risikoer, Anbefalt neste steg og Utkast til svar;
• lag et e-postutkast og send det aldri uten bekreftelse.

Agenten kan nå innarbeide disse avgjørelsene i instruksjonen. Du trenger ikke foreskrive hvert researchsteg. Du må gjøre teamets kilder, outputkrav og godkjenningsgrenser entydige.

Gi tilbakemelding på begrensninger i klart språk

Du kan skjerpe utkastet ved å fortelle agenten hva som må endres:

• “Be om CRM-posten før du starter hvis den mangler.”
• “Behandle CRM som referansesystem når selskapsnavn er i konflikt.”
• “Hver faktisk påstand i sammendraget må ha en kildehenvisning.”
• “Hold svaret under 150 ord, men tilpass tonen til innkommende melding.”
• “Lag e-posten som utkast. Send den aldri automatisk.”
• “Denne arbeidsflyten skal ikke kjøres for eksisterende muligheter.”

Be agenten oppdatere arbeidsflyten og oppsummere hvilken begrensning hver endring gjelder. Det gjør det lettere å oppdage en regel som er misforstått eller plassert i feil seksjon.

Hold riktige ting utenfor instruksjonen

Noen opplysninger bør ikke bli permanent arbeidsflyttekst:

• kundenavn, engangsfrister og måldestinasjoner for enkeltsaker hører hjemme i kjøringsforespørselen;
• passord, tokens og private påloggingsopplysninger hører ikke hjemme i instruksjon eller vedlagt fil;
• tidsplaner og hendelser hører til en automatisering;
• tekniske tilgangsgrenser hører til agentautorisasjon og tillatelser;
• personlig tilbakemelding som bare gjelder ett resultat kan bli i den chatten.

Instruksjonen skal inneholde den gjenbrukbare metoden og atferdsbegrensningene, ikke alle detaljer rundt arbeidet.

Test og forbedre sammen

Kjør arbeidsflyten med minst to realistiske input, helst med en annen kollega. Etter hver kjøring, spør:

• Ble arbeidsflyten aktivert for riktig oppgave?
• Ba den om inputene den trengte?
• Fulgt den ønsket kildeprioritet?
• Var output konsistent uten å bli rigid?
• Stoppet den ved nødvendig godkjenningsgrense?
• Er problemet repeterbart, eller gjelder det bare dette tilfellet?

Be agenten revidere instruksjonen for repeterbare mangler. Hold engangskorrigeringer i kjøringen. Når metoden fungerer for andre enn den som laget den, del arbeidsflyten med teamet ditt.