워크플로

워크플로 는 에이전트에 저장된, 이름이 있고 다시 쓸 수 있는 절차입니다. 당신의 팀 이 특정한 종류의 일을 어떻게 하는지 Okou에게 가르쳐 두어, 다음에 그 일이 필요한 사람이 프롬프트를 다시 쓰지 않아도 되게 합니다.

처음 Okou에게 무언가를 부탁할 때는 프롬프트를 씁니다. 두 번째에는 같은 프롬프트를 살짝 고쳐서 붙여 넣습니다. 세 번째쯤이면 누군가 "팀 프롬프트 모음"이라고 이름 붙인 Notion 문서에서 긴 프롬프트를 복사하고 있습니다. 바로 그때가 워크플로로 저장할 때입니다.

워크플로가 푸는 문제

한 번뿐인 일이라면 한 번뿐인 채팅으로 충분합니다. 하지만 거의 모든 팀에는 되풀이되는 일이 쌓여 있습니다. 입력은 달라도 모양은 같죠.

• 고객이 문의를 보낸다 → 이력을 찾아본다 → 고객의 언어로 답장 초안을 쓴다 → 티켓을 기록한다
• 버그 리포트가 올라온다 → 재현 단계를 뽑는다 → 심각도를 분류한다 → 구조화된 이슈를 만든다
• 월요일 아침 → 지난주 숫자를 가져온다 → 그 전주와 비교한다 → 요약을 올린다

워크플로가 없으면 이것들은 각각 모두가 외워야 하는 200단어짜리 프롬프트입니다. 워크플로가 있으면 각각이 이름 하나가 됩니다. triage-bug-report, weekly-metrics, customer-reply.

워크플로 자체에는 일정도 트리거도 없습니다. 그것은 절차 입니다. 스스로 돌게 하려면 자동화를 붙이세요.

워크플로에 들어가는 것

노드 그래프도, YAML 설정도, 트리거 섹션도 없습니다. 지침은 대개 처음에 통했던 채팅 프롬프트와 꽤 비슷하게 생겼습니다.

좋은 설명은 필요할 때 작동하는 워크플로와 한 번도 작동하지 않는 워크플로를 가릅니다. "고객이 보낸 버그 리포트를 분류해 심각도와 함께 GitHub에 등록" 이 "버그 관련 일" 보다 낫습니다.

워크플로는 에이전트에 속합니다

모든 워크플로는 정확히 하나의 에이전트 에 속합니다. 그래서 행동이 예측 가능합니다. 워크플로는 그 에이전트의 말투, 기본값, 커넥터 권한으로 돌아갑니다.

• 비공개 워크플로 — 당신에게만 보입니다. 개인 Gmail이나 개인 CRM 좌석에 묶인 개인 자동화에 알맞습니다.
• 공개 워크플로 — 워크스페이스 전체에 보이며, 팀이 닿을 수 있는 에이전트 위에 있습니다.

같은 절차가 두 에이전트에 있으면 결과가 달라질 수 있습니다. 각자 고유한 목소리와 권한을 가져오기 때문입니다. 다른 에이전트에게 워크플로를 넘기려면 복사 하세요. 그러면 갈라져 나오고, 이후 둘은 각자의 길을 갈 수 있습니다.

에이전트 소유가 워크플로의 손이 닿는 범위를 어떻게 결정하는지는 Agents를 보세요.

워크플로 만들기

Workflows 페이지에서 시작하기

1. Workflows 를 열고 New workflow 를 고릅니다.
2. 이 워크플로를 소유할 에이전트를 선택합니다.
3. Okou가 생성 안내 프롬프트와 함께 채팅을 엽니다. 원하는 결과, 예상 입력, 도구, 산출물, 승인 경계를 설명하세요.
4. Okou가 만들기 전에 제안된 이름, 설명, 지침, 파일, 공개 범위를 검토합니다.

기존 에이전트 채팅에서 시작해, 이미 잘된 작업을 워크플로로 만들어 달라고 할 수도 있습니다. 성공한 첫 실행을 같은 채팅에 남겨 두면 Okou가 구체적인 입력과 당신의 수정, 실제 산출물을 그대로 담을 수 있습니다.

지침에 무엇을 넣나

자격 증명은 지침과 파일 밖에 두세요. 서비스는 Connectors 로 연결하고, 소유 에이전트에는 이 워크플로에 필요한 권한만 주세요.

자동화하기 전에 테스트하기

1. 대표적인 입력으로 워크플로를 수동으로 한 번 실행합니다.
2. 소유 에이전트가 필요한 커넥터와 권한에 모두 닿는지 확인합니다.
3. 결과 채팅에서 빠진 맥락, 예상치 못한 쓰기, 최종 산출물의 모양을 살핍니다.
4. Instructions 나 첨부 파일을 고치고, 결과가 반복 가능해질 때까지 다시 실행합니다.
5. 수동 실행이 정확해진 뒤에야 자동화를 붙이세요. 좁은 이벤트 필터나 낮은 빈도의 일정으로 시작해 첫 몇 번의 실행을 확인합니다.

수동 검증은 워크플로 문제와 트리거 문제를 갈라 줍니다. Run now 가 실패하면 워크플로나 그 접근 권한부터 고치세요. Run now 는 되는데 이벤트가 전혀 발생하지 않으면 자동화 설정을 살피세요.

Okou는 워크플로를 어떻게 고르나

이름으로 불러낼 필요가 없습니다. 들어온 요청이 설명과 맞으면 Okou가 알아서 불러옵니다. customer-reply-draft 라는 워크플로가 "우리 목소리와 우리 문서를 써서 고객 이메일 답장 초안을 쓴다" 로 설명돼 있으면, 고객 이메일을 전달하는 것만으로 작동합니다. 이름을 말할 필요가 없죠.

특정한 것을 강제하려면 그렇게 말하세요. "이 메일에는 customer-reply-draft 워크플로를 써 줘."

기본 제공 워크플로

모든 Okou 에이전트에는 Okou가 관리하는 여러 부서 공통 워크플로가 함께 제공됩니다. 리서치와 분석, 재무와 회계, 법무와 컴플라이언스, 제품, 마케팅, 고객 지원, 팀 커뮤니케이션 등입니다. 이것들은 커넥터 배선이 아니라 업무 절차로, 되풀이되는 종류의 일을 어떻게 다룰지 Okou에게 가르칩니다.

맛보기입니다.

• deep-dive — 구조화된 리서치와 해법 설계. 먼저 사실을 모으고 그다음 선택지를 탐색
• prd-writing — 구조화된 문제 정의와 수용 기준을 갖춘 제품 요구사항
• copywriting — 채널 전반의 마케팅 카피(블로그, 이메일, 소셜, 랜딩 페이지)
• competitor-matrix — 기능 비교표, 포지셔닝 해부, 수주/실주 분석
• customer-reply — 채널과 긴급도에 맞춘, 공감적이고 브랜드에 맞는 답변
• nda-screening — 들어온 NDA를 GREEN / YELLOW / RED로 분류하고 라우팅
• status-updates — 어떤 청중에게도 맞춘 진행 보고와 이해관계자 업데이트

당신이 만든 워크플로는 이것들과 나란히 놓이고, 설명이 더 잘 맞으면 우선합니다.

언제 만들어야 하나

솔직한 기준: 사실상 같은 프롬프트를 두 번 넘게 썼다면 — 또는 동료가 그걸 쓰는 모습이 그려진다면 — 저장하세요.

구체적인 신호입니다.

• 그 일에 팀이 이미 쓰는 이름이 있다("아침 브리핑", "경쟁사 스캔")
• 프롬프트가 매번 바뀌면 안 되는 특정 도구, 채널, 템플릿을 지목한다
• 산출물의 모양이 고정돼 있다(요약, 초안, 등록된 이슈)
• 한 사람 이상이 그것을 실행해야 한다
• 일정이나 이벤트로 돌리고 싶다 — Automations 참고

흔한 패턴

• 접수 창구. 입력 하나(이메일, 버그 리포트, 스레드)를 받아 구조화된 산출물(이슈, 초안, 한 행)을 만듭니다.
• 주기 브리핑. 예약 자동화와 짝지어 매일 또는 매주 돌고 눈에 띄는 곳에 올립니다.
• 대화 중 도우미. 채널에서 @Okou 로 불려 찾기·요약·분류 같은 좁은 하위 작업 하나를 합니다.
• 묶음 생산자. 한 번의 실행으로 여러 형식의 묶음 — 블로그 초안에 소셜 게시물, 카드까지 — 을 만듭니다.
• 이벤트 응답자. 이벤트 자동화와 짝지어 새 이메일, 병합된 PR, 새 Notion 페이지가 실행을 시작합니다. Automations 참고.

피해야 할 함정

• 너무 좁음. 아주 특정한 입력에만 맞는 워크플로는 쉽게 깨집니다. 한 예시의 세부가 아니라 일의 모양을 겨냥하세요.
• 너무 모호함. "마케팅 좀 도와줘" 는 너무 넓어서 Okou가 언제 적용할지 모릅니다. 설명은 구체적으로.
• 자격 증명을 박아 넣기. API 키를 지침에 붙여 넣지 마세요. 대신 커스텀 커넥터를 쓰면 자격 증명이 플랫폼에 남아 모델의 손이 닿지 않습니다.
• 산출물 모양이 묻힘. 결과물이 어떤 모습이어야 하는지 밝히세요. "항목 세 개짜리 번호 목록", "150단어 이내의 답장 초안" 처럼요.
• 에이전트를 잊음. 워크플로는 호스트 에이전트가 인가받은 커넥터만 쓸 수 있습니다. 워크플로가 Gmail에 닿지 못하면 지침이 아니라 에이전트의 Authorization 탭을 보세요.

다음으로 볼 것

• 당신 없이도 돌게 하려면 Automations로 트리거를 붙이세요.
• 누가 어떤 권한으로 워크플로를 실행하는지는 Agents.
• 워크플로가 건드릴 수 있는 범위를 제한하려면 Permissions.
• 처음부터 끝까지 쓰인 다섯 가지 예시는 Example workflows.