Opprett arbeidsflytinstruksjoner med Okou

Du trenger ikke å skrive en arbeidsflytinstruksjon fra en tom side. Begynn med å fullføre en reell oppgave med agenten din. Når resultatet er nyttig, be agenten om å gjøre metoden dere utviklet sammen om til en gjenbrukbar arbeidsflyt.

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

Med My Okou inneholder personlige instruksjoner (Instructions) hver medlems preferanser; en arbeidsflyt i arbeidsområdet inneholder den repeterbare prosedyren og teamstandardene. Private arbeidsflyter tilhører den nåværende brukeren, og offentlige arbeidsflyter deles i arbeidsområdet. Kjøringen bruker den utførende medlemmets personlige instruksjoner (Instructions), minne, kontoer og tillatelser. I Legacy Agents forblir arbeidsflyter knyttet til én agent. Se Instruksjoner og opplevelsesmoduser.

Start fra en vellykket kjøring

Det er lettere å opprette en arbeidsflyt etter at agenten har sett oppgaven, kildematerialet, tilbakemeldingene dine og et akseptabelt resultat.

1. Gi agenten en reell oppgave og den faktiske inndataen den trenger.
2. Gå gjennom resultatet og korriger manglende kontekst, svak resonnering eller feil format.
3. Når resultatet er bra, be agenten om å trekke ut den repeterbare metoden.
4. Be agenten utarbeide navn, 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. Utarbeid navn, beskrivelse og instruksjon. Skill den gjenbrukbare metoden fra detaljer som bare gjelder for denne saken. Før vi ferdigstiller den, list opp antakelsene og begrensningene jeg bør gjennomgå.

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

Instruksjon er et vanlig sted for begrensninger

Arbeidsflytinstruksjonen følger med arbeidsflyten og gjelder hver gang den kjøres. Det gjør den til et av de vanligste stedene å definere begrensninger som påkrevde inndata, godkjente kilder, utdataformat, kvalitetsstandarder og handlinger som krever bekreftelse.

Det er ikke det eneste kontrollnivået:

Ikke stol på instruksjonstekst som erstatning for tilgangskontroller. Hvis en handling må være teknisk begrenset, bruk også den faktiske connector-godkjenningen og navngitte tillatelser samt en tydelig instruksjon.

Gjennomgå agentens førsteutkast

Du trenger ikke å omskrive hver setning. Fokuser gjennomgangen på beslutningene som betyr noe for teamet.

Når skal det 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?

Hvilken inndata kreves?

• Hva må en teamkollega levere før arbeidet starter?
• Hvilke manglende inndata bør 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 vinner?

• Hva er sannhetskilden?
• Hvilken vedlagt fil inneholder den godkjente rubrikken eller malen?
• Hvis to kilder er i konflikt, hvilken har prioritet?
• Hvordan skal agenten merke fakta den ikke kan verifisere?

Hvordan må utdata se ut?

• Hvilke seksjoner eller felt kreves?
• Hvilket detaljeringsnivå er nyttig?
• Trenger utdata sitater, lenker eller en tillitsmerking?
• Hvor skal resultatet gå når en destinasjon er angitt?

Hvor må agenten stoppe?

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

Dette er begrensningene som er verdt å gjøre eksplisitte. La agenten håndtere formuleringen, og bekreft deretter at formuleringen gjenspeiler beslutningen din.

En struktur dere kan gjennomgå sammen

Agenten kan bruke følgende struktur til førsteutkastet sitt. Behandle det som en gjennomgangsramme, 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 regler for kilde, validering og godkjenning. Be agenten holde instruksjonen så kort som mulig uten å skjule en beslutning teamet er avhengig av.

Eksempel: samskape en arbeidsflyt for leadkvalifisering

Anta at du ber agenten om å undersøke én innkommende lead og utarbeide et svar. Under kjøringen korrigerer du selskapsstørrelsen, forklarer at CRM er sannhetskilden, bruker teamets ICP-rubrikk og ber om en kortere e-post.

Etter at resultatet er godkjent, be agenten om å gjøre samtalen om til en arbeidsflyt. Agenten utarbeider prosedyren. Deretter legger du til begrensningene som bør overleve utover denne leaden:

• sjekk CRM før du gjør offentlig research;
• bruk den vedlagte ICP-rubrikken for poengsetting;
• siter kilder for selskapsstørrelse, plassering og nåværende rolle;
• merk et ikke-verifisert påkrevd faktum som Unknown;
• returner Account summary, Evidence, ICP score, Risks, Recommended next step og Reply draft;
• opprett et e-postutkast og send det aldri uten bekreftelse.

Agenten kan nå innarbeide disse beslutningene i instruksjonen. Du trenger ikke å foreskrive hvert forskningssteg. Du må gjøre teamets kilder, utdataavtale og godkjenningsgrense entydige.

Gi tilbakemelding om begrensninger i vanlig språk

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

• “Be om CRM-posten før du starter hvis den mangler.”
• “Behandle CRM som sannhetskilden når selskapsnavn er i konflikt.”
• “Hver faktapåstand i briefen trenger en kildelenke.”
• “Hold svaret under 150 ord, men tilpass tonen til den innkommende meldingen.”
• “Opprett e-posten som et utkast. Send den aldri automatisk.”
• “Denne arbeidsflyten skal ikke kjøre for eksisterende muligheter.”

Be agenten om å oppdatere arbeidsflyten og oppsummere hvilken begrensning hver endring adresserer. Det gjør det lettere å fange opp en regel som ble misforstått eller plassert i feil seksjon.

Hold de riktige tingene utenfor instruksjonen

Noen opplysninger bør ikke bli permanent arbeidsflyttekst:

• kundenavn, engangsfrister og casespesifikke destinasjoner hører hjemme i kjøringsforespørselen;
• passord, tokens og private legitimasjoner hører ikke hjemme i en instruksjon eller vedlagt fil;
• tidsplaner og hendelser hører hjemme i en automatisering;
• tekniske tilgangsgrenser hører hjemme i koblingstillatelser og navngitte tillatelser;
• personlig tilbakemelding som bare gjelder ett resultat, kan bli værende i den chatten.

Instruksjonen bør bære den gjenbrukbare metoden og atferdsbegrensningene, ikke alle detaljene rundt arbeidet.

Test og forbedre sammen

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

• Aktiverte arbeidsflyten for den riktige oppgaven?
• Ba den om inndataene den trengte?
• Fulgte den den tiltenkte kildeprioriteten?
• Var utdataene konsistente uten å bli rigide?
• Stoppet den ved den påkrevde godkjenningsgrensen?
• Er problemet repeterbart, eller gjelder det bare denne saken?

Be agenten om å revidere instruksjonen for repeterbare hull. Behold engangskorrigeringer i kjøringen. Når metoden fungerer for noen andre enn den opprinnelige opphavspersonen, del arbeidsflyten med teamet ditt.