워크플로는 에이전트에 저장된 이름 지정된 재사용 가능한 절차입니다. 당신의 팀이 특정 유형의 작업을 어떻게 하는지 Okou에 가르쳐, 다음에 그게 필요한 사람이 프롬프트를 다시 쓰지 않아도 됩니다.
처음 Okou에 무언가를 요청할 때 프롬프트를 씁니다. 두 번째에는 같은 프롬프트를 약간 수정해 붙여넣습니다. 세 번째에는 누군가 "팀 프롬프트 라이브러리"라고 부른 Notion 문서에서 긴 프롬프트를 복사하고 있습니다. 그때가 워크플로를 저장할 순간입니다.
워크플로가 해결하는 문제
일회성 채팅은 일회성 태스크에 적합합니다. 하지만 거의 모든 팀에는 반복되는 작업 백로그가 있습니다. 입력은 다르고 형태는 같습니다:
- 고객이 문의 → 이력을 확인 → 그 언어로 답장 초안 → 티켓 기록
- 버그 보고가 나타남 → 재현 단계 추출 → 심각도 분류 → 구조화된 Issue 생성
- 월요일 아침 → 지난주 수치 가져오기 → 그 전 주와 비교 → 요약 게시
워크플로가 없으면 각각은 모두가 기억해야 하는 200단어 프롬프트입니다. 워크플로가 있으면 각각은 이름입니다. triage-bug-report, weekly-metrics, customer-reply.
워크플로 자체에는 일정도 트리거도 없습니다. 그것은 절차입니다. 스스로 실행되게 하려면 Automation을 붙이세요.
워크플로에 들어 있는 것
| 필드 | 역할 |
|---|---|
| Name | 문자, 숫자, 내부 하이픈을 사용한 2~64자 소문자 슬러그 — triage-bug-report. 소유 에이전트의 채팅에서 명시적으로 호출하려면 /triage-bug-report를 사용합니다. |
| Display name | 워크스페이스에 표시되는 사람이 읽을 수 있는 라벨. |
| Description | 이 워크플로가 언제 적용되는지 Okou에 알려주는 한 줄. Okou는 수신 요청을 설명과 대조하므로 표현이 중요합니다. |
| Instruction | 절차 자체. 평이한 문장이면 충분합니다. 사용할 도구, 출력 형태, 제약 사항을 언급하세요. |
| Files | 선택적 보조 파일 — 템플릿, 체크리스트, 브랜드 가이드라인, 참조 데이터 — 워크플로와 함께 묶임. |
| Visibility | private(나만) 또는 public(워크스페이스의 모든 사람). |
노드 그래프도, YAML 설정도, 트리거 섹션도 없습니다. 인스트럭션은 보통 처음에 잘 작동했던 채팅 프롬프트와 매우 비슷합니다.
좋은 설명은 발화해야 할 때 발화하는 워크플로와 절대 발화하지 않는 워크플로의 차이입니다. *"triage a customer-facing bug report and file it to GitHub with severity"*가 *"do bug stuff."*보다 낫습니다.
워크플로는 에이전트에 속함
모든 워크플로는 정확히 하나의 에이전트에 속합니다. 그것이 동작을 예측 가능하게 만듭니다. 워크플로는 그 에이전트의 톤, 기본값, 커넥터 부여로 실행됩니다.
- 비공개 워크플로 — 나만 볼 수 있음. 개인 Gmail이나 개인 CRM 자리에 연결된 개인 자동화에 적합.
- 공개 워크플로 — 워크스페이스의 모든 사람이 볼 수 있음. 팀이 도달할 수 있는 에이전트에 둠.
같은 절차가 두 에이전트에 존재하며 서로 다른 결과를 낼 수 있습니다. 각 에이전트가 자신의 목소리와 권한을 가져오기 때문입니다. 워크플로를 다른 에이전트에 넘기려면 복사하세요. 그러면 분기되어 둘이 이후 달라질 수 있습니다.
에이전트 소유권이 워크플로가 건드릴 수 있는 범위를 어떻게 정하는지는 Agents 참조.
워크플로 만들기
Workflows 페이지에서 시작
- Workflows를 열고 New workflow를 선택합니다.
- 워크플로를 소유할 에이전트를 선택합니다.
- Okou가 안내형 워크플로 생성 프롬프트로 채팅을 엽니다. 결과, 예상 입력, 도구, 출력, 승인 경계를 설명하세요.
- Okou가 만들기 전에 제안된 이름, 설명, 인스트럭션, 파일, 가시성을 검토합니다.
기존 에이전트 채팅에서 시작해 이미 잘 작동한 태스크를 워크플로로 바꿔달라고 Okou에 요청할 수도 있습니다. 첫 성공 Run을 같은 채팅에 두면 Okou가 잡아낼 구체적인 입력, 수정, 출력이 생깁니다.
인스트럭션에 넣을 것
| 부분 | 포함 |
|---|---|
| Goal | 워크플로가 만들어야 할 결과. |
| Inputs | 호출자나 자동화가 제공하는 것과 필수 입력. |
| Procedure | 읽거나 업데이트할 연결된 서비스를 포함한 순서 있는 단계. |
| Output | 필요한 형식, 대상, 이름 규칙. |
| Boundaries | 피할 작업, 확인이 필요한 경우, 멈출 때. |
| References | 워크플로 파일로 첨부된 선택적 템플릿, 체크리스트, 예시. |
자격 증명을 인스트럭션과 파일 밖에 두세요. Connectors로 서비스를 연결하고 소유 에이전트에 워크플로에 필요한 권한만 부여하세요.
자동화 전에 테스트
- 대표적인 입력으로 워크플로를 수동 실행합니다.
- 소유 에이전트가 필요한 모든 커넥터와 권한에 접근할 수 있는지 확인합니다.
- 결과 채팅에서 빠진 컨텍스트, 예상치 못한 쓰기, 최종 출력 형태를 검사합니다.
- Instructions나 첨부 파일을 편집하고 결과가 반복 가능해질 때까지 다시 실행합니다.
- 수동 실행이 올바른 뒤에만 자동화를 추가합니다. 좁은 이벤트 필터나 낮은 빈도 일정으로 시작한 다음 처음 몇 번의 발화를 검사합니다.
수동 검증은 워크플로 문제와 트리거 문제를 구분합니다. Run now가 실패하면 먼저 워크플로나 그 액세스를 고치고, Run now는 성공하는데 이벤트가 발화하지 않으면 자동화 구성을 검사합니다.
Okou가 워크플로를 고르는 방식
워크플로를 이름으로 호출할 필요가 없습니다. 수신 요청이 설명과 일치하면 Okou가 자동으로 하나를 로드합니다. *"draft a reply to a customer email using our voice and docs"*로 설명된 customer-reply-draft 워크플로는 고객 이메일을 전달하면 발화합니다. 이름이 필요 없습니다.
특정 워크플로를 강제하려면 말하세요: "Use the customer-reply-draft workflow on this email."
내장 워크플로
모든 Okou 에이전트에는 Okou이 유지 관리하는 교차 기능 워크플로가 포함됩니다. 리서치와 분석, 재무와 회계, 법률과 컴플라이언스, 제품, 마케팅, 고객 지원, 팀 커뮤니케이션. 커넥터 배선이 아니라 도메인 절차로, 각각이 반복되는 작업 유형을 다루는 법을 Okou에 가르칩니다.
일부 예:
deep-dive— 구조화된 리서치와 솔루션 설계. 사실을 모은 뒤 옵션 탐색prd-writing— 구조화된 문제 정의와 수용 기준을 갖춘 제품 요구사항copywriting— 채널 전반의 마케팅 카피(블로그, 이메일, 소셜, 랜딩 페이지)competitor-matrix— 기능 비교 매트릭스, 포지셔닝 분석, 승패 분석customer-reply— 채널과 긴급도에 맞춘 공감적이고 브랜드에 맞는 답장nda-screening— 수신 NDA를 GREEN / YELLOW / RED로 분류하고 라우팅status-updates— 모든 대상에 맞춘 진행 보고와 이해관계자 업데이트
내 워크플로는 이들과 나란히 있으며 설명이 더 정확히 일치하면 우선합니다.
만들 시점
정직한 규칙: 실질적으로 같은 프롬프트를 두 번 넘게 썼다면, 또는 팀 동료가 그걸 쓸 것이라고 상상된다면 저장하세요.
구체적인 신호:
- 팀이 이미 쓰는 이름이 있다(«morning brief», «competitor scan»)
- 프롬프트가 매 Run마다 바뀌지 않아야 할 특정 도구, 채널, 템플릿을 지목한다
- 출력이 고정된 형태다(요약, 초안, 생성된 Issue)
- 한 명 이상이 트리거해야 한다
- 일정이나 이벤트로 실행되길 원한다 — Automations 참조
일반적인 패턴
- 인테이크 폼. 입력(이메일, 버그 보고, 스레드)을 받아 구조화된 산출물(Issue, 초안, 행)을 만듭니다.
- 주기 브리프. 매일 또는 매주 실행되어 눈에 띄는 곳에 게시하는 예약 자동화와 짝을 이룬 워크플로.
- 대화 중 헬퍼. 채널에서
Okou로 트리거되어 하나의 집중된 하위 작업(조회, 요약, 분류)을 수행합니다. - 컴포저. 한 Run에서 블로그 초안 + 소셜 게시물 + 카드 같은 다중 형식 묶음을 만듭니다.
- 이벤트 응답자. 이벤트 자동화와 짝을 이룹니다. 새 이메일, 병합된 PR, 새 Notion 페이지가 Run을 시작합니다. Automations 참조.
피해야 할 함정
- 너무 좁음. 특정 입력 하나에만 맞는 워크플로는 취약합니다. 한 예의 세부가 아니라 작업의 형태를 겨냥하세요.
- 너무 모호함. *"Help with marketing"*은 너무 넓어 Okou가 언제 적용할지 모릅니다. 설명을 구체적으로 쓰세요.
- 하드코딩된 자격 증명. API 키를 인스트럭션에 붙여넣지 마세요. Custom connectors를 사용하세요. 자격 증명은 플랫폼에 남아 모델의 손이 닿지 않는 곳에 있습니다.
- 묻힌 출력 형태. 산출물이 어떻게 생겨야 하는지 명시하세요. "a numbered list of three items" 또는 "a draft reply under 150 words."
- 에이전트 잊기. 워크플로는 호스트 에이전트가 승인된 커넥터만 사용할 수 있습니다. 워크플로가 Gmail에 도달하지 못하면 인스트럭션이 아니라 에이전트의 Authorization 탭을 확인하세요.
다음
- Automations로 트리거를 붙이면 워크플로가 당신 없이 실행됩니다.
- 누가 어떤 권한으로 워크플로를 실행하는지는 Agents 참조.
- 워크플로가 건드릴 수 있는 것을 제한하려면 Permissions 참조.
- 처음부터 끝까지 쓰인 5가지는 Example workflows 참조.