Okou로 워크플로우 지침 만들기

빈 페이지에서 워크플로우 지침을 작성할 필요는 없습니다. 먼저 에이전트와 함께 실제 작업을 완료하세요. 결과가 유용해지면, 함께 개발한 방법을 재사용 가능한 워크플로우로 바꾸도록 에이전트에게 요청하세요.

에이전트가 첫 초안을 작성합니다. 여러분의 역할은 그 가정을 검토하고, 다른 팀원이 신뢰할 수 있는 결과를 얻으려면 워크플로우의 어느 부분에 더 명확한 제약이 필요한지 결정하는 것입니다.

My Okou에서는 개인 지침(Instructions)이 각 멤버의 선호를 보관하고, 워크스페이스 워크플로는 반복 가능한 절차와 팀 표준을 보관합니다. Private Workflows는 현재 사용자에게 속하며, Public Workflows는 워크스페이스 안에서 공유됩니다. 실행은 실행하는 멤버의 지침, 메모리, 계정, 권한을 사용합니다. Legacy Agents에서는 Workflows가 여전히 하나의 Agent에 연결되어 있습니다. Instructions and experience modes를 참조하세요.

성공한 실행에서 시작하기

에이전트가 작업, 원본 자료, 여러분의 피드백, 그리고 허용 가능한 결과를 이미 본 뒤라면 워크플로우를 만들기가 더 쉽습니다.

1. 에이전트에게 실제 작업과 필요한 실제 입력을 주세요.
2. 결과를 검토하고 누락된 맥락, 약한 추론, 잘못된 형식을 수정하세요.
3. 결과가 좋다면, 재사용 가능한 방법을 추출해 달라고 에이전트에게 요청하세요.
4. 워크플로우 이름, 설명, 지침, 그리고 권장하는 참조 파일이 있으면 그것들도 초안으로 작성하게 하세요.
5. 워크플로우를 공개하기 전에 함께 초안을 검토하세요.

다음과 같이 요청할 수 있습니다:

방금 한 일을 팀이 재사용할 수 있는 워크플로우로 바꿔 주세요. 이름, 설명, 지침을 초안으로 작성해 주세요. 이 사례에만 해당하는 세부사항과 재사용 가능한 방법을 분리해 주세요. 마무리하기 전에 제가 검토해야 할 가정과 제약을 나열해 주세요.

이렇게 하면 초안 작성은 에이전트가 맡고, 어떤 부분을 통제해야 하는지는 여러분이 결정하게 됩니다.

지침은 제약을 두기 좋은 곳입니다

워크플로우 지침은 워크플로우와 함께 이동하며 실행될 때마다 적용됩니다. 그래서 필요한 입력, 승인된 소스, 출력 형식, 품질 기준, 확인이 필요한 작업 같은 제약을 정의하기에 가장 흔한 위치 중 하나입니다.

하지만 이것만이 유일한 통제 계층은 아닙니다:

지침 텍스트를 접근 제어의 대체물로 의존하지 마세요. 어떤 작업을 기술적으로 제한해야 한다면, 명확한 지침과 함께 실제 커넥터 권한 부여와 명명된 권한도 사용하세요.

에이전트의 첫 초안을 검토하기

모든 문장을 다시 쓸 필요는 없습니다. 팀에 중요한 결정에 검토를 집중하세요.

언제 사용해야 하나요?

• 어떤 요청이나 상황에서 이 워크플로우를 선택해야 하나요?
• 에이전트가 언제 이 워크플로우를 사용하면 안 되나요?
• 설명이 비슷한 워크플로우와 구별될 만큼 구체적인가요?

어떤 입력이 필요하나요?

• 작업을 시작하기 전에 팀원이 무엇을 제공해야 하나요?
• 어떤 누락된 입력이 있으면 에이전트가 질문해야 하나요?
• 어떤 세부사항은 영구 지침이 아니라 각 실행에 속하나요?

어떤 소스와 규칙이 우선하나요?

• 기준 시스템은 무엇인가요?
• 승인된 기준표나 템플릿이 들어 있는 첨부 파일은 어느 것인가요?
• 두 소스가 충돌하면 어느 쪽이 우선하나요?
• 에이전트는 확인할 수 없는 사실을 어떻게 표시해야 하나요?

출력은 어떤 모습이어야 하나요?

• 어떤 섹션이나 필드가 필요한가요?
• 어느 정도의 상세함이 유용한가요?
• 출력에 인용, 링크, 신뢰도 라벨이 필요한가요?
• 대상이 지정되면 결과를 어디에 보내야 하나요?

에이전트는 어디에서 멈춰야 하나요?

• 어떤 작업에 확인이 필요한가요?
• 에이전트는 보내거나 게시하는 대신 초안을 만들어야 하나요?
• 어떤 데이터가 공개 워크플로우나 공유 결과에 나타나면 안 되나요?

이것들이 명시적으로 적어 둘 만한 제약입니다. 문구는 에이전트가 작성하게 하고, 그 문구가 여러분의 결정을 반영하는지 확인하세요.

함께 검토할 구조

에이전트는 첫 초안에 다음 구조를 사용할 수 있습니다. 이것은 여러분이 직접 작성해야 하는 양식이 아니라, 검토 프레임워크로 보세요:

# 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.

간단한 워크플로우라면 몇 개의 섹션만 필요할 수 있습니다. 위험이 큰 워크플로우라면 더 명시적인 소스, 검증, 승인 규칙이 필요할 수 있습니다. 팀이 의존하는 결정을 가리지 않으면서도 지침을 가능한 한 짧게 유지하도록 에이전트에게 요청하세요.

예시: 리드 자격 검토 워크플로우를 함께 만들기

에이전트에게 하나의 인바운드 리드를 조사하고 답장을 초안으로 작성해 달라고 요청했다고 가정해 봅시다. 실행 중에 회사 규모를 바로잡고, CRM이 기준 시스템이라고 설명하고, 팀의 ICP 기준표를 적용하고, 더 짧은 이메일을 요청합니다.

결과가 승인되면, 그 대화를 워크플로우로 바꾸라고 에이전트에게 요청하세요. 에이전트가 절차를 초안으로 작성합니다. 그런 다음 이 리드 이후에도 유지되어야 할 제약을 추가합니다:

• 공개 조사 전에 CRM을 확인할 것;
• 점수 산정에는 첨부된 ICP 기준표를 사용할 것;
• 회사 규모, 위치, 현재 역할에 대한 출처를 인용할 것;
• 확인되지 않은 필수 사실은 Unknown으로 표시할 것;
• Account summary, Evidence, ICP score, Risks, Recommended next step, 그리고 Reply draft를 반환할 것;
• 이메일 초안을 만들고, 확인 없이 절대 보내지 않을 것.

이제 에이전트는 그 결정들을 지침에 반영할 수 있습니다. 모든 조사 단계를 직접 지정할 필요는 없습니다. 팀의 소스, 출력 계약, 승인 경계를 명확하게 만들면 됩니다.

평이한 언어로 제약 피드백 주기

에이전트에게 무엇을 바꿔야 하는지 말해 초안을 다듬을 수 있습니다:

• “CRM 기록이 없으면 시작하기 전에 먼저 요청하세요.”
• “회사 이름이 충돌할 때는 CRM을 기준 시스템으로 취급하세요.”
• “브리프의 모든 사실적 주장은 출처 링크가 필요합니다.”
• “답장은 150단어 이내로 유지하되, 인바운드 메시지의 톤에 맞게 조정하세요.”
• “이메일은 초안으로만 작성하세요. 자동으로 보내지 마세요.”
• “이 워크플로우는 기존 기회에 대해 실행되면 안 됩니다.”

에이전트에게 워크플로우를 업데이트하고, 각 변경이 어떤 제약을 다루는지 요약해 달라고 요청하세요. 그러면 오해했거나 잘못된 섹션에 들어간 규칙을 더 쉽게 찾을 수 있습니다.

올바른 항목은 지침 밖에 두기

어떤 정보는 영구적인 워크플로우 텍스트가 되어서는 안 됩니다:

• 고객 이름, 일회성 마감일, 사례별 대상지는 실행 요청에 두어야 합니다;
• 비밀번호, 토큰, 비공개 자격 증명은 지침이나 첨부 파일에 포함되어서는 안 됩니다;
• 일정과 이벤트는 automation에 속합니다;
• 기술적 접근 경계는 커넥터 권한 부여와 명명된 권한에 속합니다;
• 한 번의 결과에만 적용되는 개인 피드백은 그 채팅에 남겨 두어도 됩니다.

지침은 작업을 둘러싼 모든 세부사항이 아니라, 재사용 가능한 방법과 행동 제약을 담아야 합니다.

함께 테스트하고 다듬기

최소 두 개의 현실적인 입력으로, 가능하면 두 번째 팀원과 함께 워크플로우를 실행하세요. 각 실행 후 다음을 물어보세요:

• 워크플로우가 올바른 작업에서 활성화되었나요?
• 필요한 입력을 요청했나요?
• 의도한 소스 우선순위를 따랐나요?
• 경직되지 않으면서도 출력이 일관되었나요?
• 필요한 승인 경계에서 멈췄나요?
• 이 문제는 반복 가능한가요, 아니면 이 사례에만 적용되나요?

반복 가능한 공백이 있으면 에이전트에게 지침을 수정하라고 요청하세요. 일회성 수정은 run에 남겨 두세요. 이 방법이 원래 만든 사람 외의 다른 사람에게도 효과가 있으면, 워크플로우를 팀과 공유하세요.