서론
Agentforce의 지시문에 '반드시 거래처를 확인한 후에 답변해 주세요'라고 적었는데도, 확인 과정이 생략되고 그대로 답변이 되어버린 경우가 있었습니다.
Agentforce로 에이전트를 만들다 보면 이런 상황을 겪게 됩니다.
LLM은 똑똑하지만, 다소 변덕스러운 면이 있습니다.
'반드시'라고 써도 반드시 작동한다고 보장할 수는 없습니다. 업무에 사용하려면 '여기는 매번 같은 동작을 해줬으면 좋겠다'라는 부분이 생깁니다.
여기서 사용할 수 있는 것이 Agent Script입니다.
변덕스러워도 괜찮은 부분은 LLM에게 맡기고, 매번 같은 동작을 해줬으면 하는 부분은 코드로 작성합니다.
Agent Script는 그 경계를 나눌 수 있게 해주는 언어입니다.
이 글에서는 Agent Script를 사용해서 영업 담당자를 위한 직원 에이전트를 3개의 서브 에이전트로 실제로 만들어 보겠습니다.
함께 '만들기 전에 알아두면 좋은 5가지'도 소개합니다.
Agentforce를 다루기 시작한 관리자나 개발자분들이 꼭 읽어보셨으면 하는 내용입니다.
Agent Script란?
에이전트의 정의를 하나의 파일에 코드로 작성하는 언어입니다. Dreamforce 2025에서 발표되었으며, 2025년 11월에 Public Beta가 되었습니다.
Agent Script는 간단히 말해 다음 세 가지를 할 수 있습니다.
- 변수에 상태를 저장할 수 있음 (LLM의 기억에 의존하지 않음)
- 서브 에이전트 간의 전환을 코드로 결정할 수 있음
- 추론 전후에 처리를 삽입할 수 있음
이번에 만들 것은 사내 직원이 사용하는 'Agentforce Employee Agent'입니다.
고객을 위한 'Agentforce Service Agent'와는 별개이며, 영업 담당자 등이 일상적으로 사용하는 어시스턴트를 상정하고 있습니다.
기본 작성 방법
Agent Script는 블록들의 집합으로 이루어져 있습니다.
| 블록 | 역할 |
|---|
| system | 에이전트 전체의 지시, 환영/에러 메시지 |
| ... | |
변수는 문장 속에서 {!@variables.변수명}, | |
식 안에서는 @variables.변수명 | |
| 처럼 작성합니다. | |
값 설정은 set @variables.변수명 = 값,
다른 서브 에이전트로의 전환은 @utils.transition to @subagent.서브에이전트명입니다.
LLM에게 주는 지시문은 |(파이프)로 작성하지만, 한 줄마다 붙일 필요는 없습니다. 덩어리 맨 앞에 한 번만 붙이고, 다음 줄부터는 들여쓰기로 연결합니다.
instructions: ->
|
당신은 직원 에이전트입니다.
사용자의 요청에 정중하게 대응해 주세요.
...
if나 run을 삽입할 때는 그때마다 새로운 |를 작성하여 문맥 덩어리별로 구분합니다.
초안은 Agentforce Builder(Agentforce 스튜디오 애플리케이션에서 열리는 Agentforce 생성용 도구)의 '스크립트' 뷰를 보면서 작성하는 것이 가장 빠르다고 생각합니다. 전체 코드는 기사 마지막에 첨부했습니다.
만들기 전에 알아두면 좋은 5가지
Agent Script로 만든 에이전트를 잘 작동시키기 위해 알고 계시면 좋을 점 5가지를 소개합니다.
1. 추론 전후에 변수 업데이트하기
서브 에이전트에는 before_reasoning과 after_reasoning이라는 블록을 배치할 수 있습니다. 이는 추론의 전과 후에 매번 실행되는 처리입니다. 변수 업데이트, 액션 실행, 다른 서브 에이전트로의 전환 등을 작성할 수 있습니다.
# before_reasoning 샘플
before_reasoning:
set @variables.current_subagent =
그리고 '현재 대응하고 있는 서브 에이전트 이름'을 변수에 저장합니다. 사용처는 앞서 준비 단계에서 소개하겠습니다.
### 2. '매번 같은 동작'을 코드로 작성하기
지시문(instruction)에 '반드시'라고 쓰는 대신, 코드로 작성해 버립니다. 자주 사용하는 것은 다음 세 가지입니다.
#### `if`
으로 지시문을 분기합니다.
① ```
instructions: ->
if @variables.target_account_id == "":
|
거래처가 특정되지 않았습니다....
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
run
으로 액션을 확실하게 실행하고, 그 결과를 변수에 넣습니다.
② ```
run @actions.GetAccountSummaryData
with accountId = @variables.target_account_id
set @variables.opportunity_text = @outputs.opportunityText
#### `available when`
으로 액션을 사용할 수 있는 조건을 좁힙니다.
③ ```
actions:
CreateTodo: @actions.CreateTodo
available when @variables.summary_confirmed == True
자유롭게 이야기해도 좋은 부분과, 흘리고 싶지 않은 부분을 나누어 두는 것만으로도 동작이 상당히 안정됩니다.
3. 서브 에이전트별로 모델 선택하기
model_config를 사용하면, 에이전트 단위에서도, 서브 에이전트 단위에서도 모델을 지정할 수 있습니다. 서브 에이전트 쪽의 지정이 우선됩니다.
subagent Account_Summary:
model_config:
model: "model://sfdc_ai__DefaultBedrockAnthropicClaude45Haiku"
- 정해진 형태로 출력만 하는 서브 에이전트에는, 가볍고 빠른 모델을 사용합니다.
- 아젠다를 짜도록 요청하는 서브 에이전트에는, 추론 능력이 높은 모델을 사용합니다.
그렇게 구분하여 사용하고 있습니다. 비용과 응답 속도 양쪽에 관련되므로, 일찍 결정해 두면 나중에 편합니다.
4. 액션의 입력은 LLM에 맡길지, 코드로 고정할지
액션에 전달하는 입력(with)에는 두 가지 작성 방식이 있습니다.
# LLM에 채워 넣게 할 경우
with recordName=...
# 변수로 고정할 경우
...
...: LLM이 대화 내용에서 값을 채움 - 변수 지정: 코드로 값을 고정합니다. LLM은 건드릴 수 없습니다.
사용처 가이드라인
- 대화에서 추출하고 싶은 값(거래처명 등)은,
...로 LLM에게 맡깁니다. - 잘못되면 곤란한 값(Id 등)은, 변수로 코드로 전달합니다.
이후 소개할 샘플 서브 에이전트의 코드에도 두 가지가 나옵니다.
거래처명을 검색하는 IdentifyRecordByName는, recordName=...로 LLM에게 이름을 추출하게 합니다.
요약(Summary)을 가져오는 GetAccountSummaryData는, accountId = @variables.target_account_id로 Id를 코드에서 전달합니다.
흐름은 다음과 같습니다.
- LLM이 대화에서 거래처명을 추출한다.
IdentifyRecordByName로 검색하여 Id를 확정한다.set_target_account로 Id를 변수에 저장한다. - 이후는, 그 변수를 코드로 전달합니다 (LLM에게 Id를 쓰게 하지 않습니다).
거래처 페이지를 열고 있는 경우도 같습니다. before_reasoning으로 열려있는 페이지의 Id를 target_account_id에 넣어두면, 대화에서 추측하게 할 필요가 없습니다.
여기서 또 하나 주의할 점이 있습니다.
변수로 고정된 값이 빈 상태로 액션을 호출해 버리면 제대로 동작하지 않습니다.
'빈 경우엔 먼저 채우기'라는 분기를 if를 사용해서 준비해 두는 것이 좋습니다.
5. 메모리 사용하기
대화에서 선호도나 사실을 자동으로 추출하여, 사용자별로 저장하고 다음 응답에 반영하는 기능입니다. 매번 같은 전제를 설명하기가 힘들 때 유용합니다.
알아두면 편리한 점
- 에이전트 단위, 사용자 단위로 저장됩니다.
- 사용자당 최대 50건. 초과 시 오래된 것부터 삭제됩니다.
- 대화 로그와는 별개입니다.
- 직원 에이전트를 Lightning Experience에서 사용할 경우, 사용자 개별 옵트인(opt-in)이 필요합니다.
- 저장된 데이터는 Salesforce 내에 머무르며 LLM과는 공유되지 않습니다.
설정 방법
설정은 Script의 context 블록에 작성합니다.
context:
memory:
enabled: True
...
user_profile
은 이름, 이메일, 로케일, 타임존과 같은 프로필 정보를 사용하는 설정입니다. 메모리와는 별개의 기능이며, 프로필 정보가 메모리로 저장되지는 않습니다.
'기억해', '기억하고 있는 것을 보여줘', '메모리를 꺼줘'와 같이 대화에서 관리할 수 있도록 하고 싶다면, 어셋 라이브러리의 표준 서브 에이전트인 'User Memory Management'를 추가합니다. 절차는 나중에 소개하겠습니다.
서브 에이전트 3가지 만들어 보기
여기서는 실제로 만들어 보겠습니다.
- 거래처 요약 (기회/할 일/활동을 가져와 정해진 형태로 요약 출력)
- 방문 준비 아젠다 작성 (거래처 요약에서 얻은 데이터를 이어받아 사용)
- 메모 기록 (표준 서브 에이전트 추가만 하면 됩니다.)
만들기 전에 결정해 둘 것들
Agent Script는 변수, 라우터, 서브 에이전트 순서로 생각하면 작성하기 쉽습니다.
이번에 사용할 변수는 미리 모두 작성해 둡니다.
variables:
currentObjectApiName: mutable string
description: "사용자가 열어둔 레코드의 오브젝트 API명(Account 또는 Opportunity 등). 사용자가 다른 오브젝트에 대해 이야기하는 경우에는 사용하지 않습니다."
...
변수의 포인트
description은 반드시 작성해야 합니다. LLM이 해당 변수를 언제 사용할지 판단하는 자료가 됩니다.currentObjectApiName과 currentRecordId는 사용자가 열어둔 페이지의 정보를 받는 변수이므로, visibility: "External"을 붙입니다. - 데이터를 일시적으로 가지고 있는 변수는 초기값을 ""로 설정해 둡니다.
current_subagent가 은근히 효과적이다
요약본을 출력한 후에, '조금 더 자세히', '기회만 보여줘'라고 했다고 가정해 봅시다.
라우터가 매번 그 한마디만으로 분배하면, 다른 서브 에이전트로 보내져 버리는 경우가 있습니다. 짧은 추가 질문일수록 발생하기 쉽습니다.
그래서 다음과 같이 했습니다.
- 각 서브 에이전트의
before_reasoning에서 자신의 이름을 current_subagent에 저장한다. - 라우터는 이것이 비어있지 않으면, '직전에 〇〇가 대응했다'고 LLM에게 전달한다. - 계속 이어지는 발언이라면 같은 서브 에이전트로 보낸다. 명백히 다른 요청일 때는 이 변수에 의존하지 않고 새로 분배 대상을 결정한다 - 수용처(요청이 모호한 ambiguous_question / 대응 범위 외 off_topic)에 도착하면, 변수를 비어있는 상태로 되돌린다.
라우터
라우터는 start_agent에 이동용 액션을 순서대로 작성합니다.
start_agent agent_router:
label: "Agent Router"
description: "사용자를 환영하고, 요청에 기반하여 적절한 서브 에이전트를 결정한다"
...
분배 판단 자료가 되는 것은 각 액션의 description입니다. 어떤 요청일 때 사용하는지 발화 예시까지 작성해 두면 분배가 안정됩니다.
'대응 범위 외（off_topic）'와 '요청이 모호할 때（ambiguous_question）' 수용처도 잊지 말고 준비해야 합니다. 수용처가 없으면, 어딘가의 서브 에이전트로 강제로 보내져 버립니다.
서브 에이전트 ① 거래처 요약
거래처에 연결된 기회, 할 일, 활동을 가져와 정해진 형태로 요약하는 서브 에이전트입니다.
방침
- 데이터 가져오기는 Flow의 액션으로 확실하게 실행합니다.
- 가져온 결과는 변수에 넣고, LLM에게는 포맷팅과 요약만 요청합니다.
- 정해진 형태의 출력물이므로 가벼운 모델을 지정합니다.
제작 순서는 먼저 Flow를 만들고, 그다음 Sub-Agent입니다.
STEP1: Flow 만들기
기회(Opportunity), ToDo, 활동(Activity)을 가져와 텍스트로 변환하여 반환하는 Flow를 만듭니다.
Flow의 사양은 다음과 같습니다.
(텍스트) - 출력:
opportunityText,
todoText,
eventText
(모두 텍스트)
만드는 방법
- '설정'을 열고, 빠른 검색에서 'Flow'를 찾아 선택합니다.
- '새 Flow' → '처음부터 시작' → '다음' 순서로 진행하며, '자동 실행 Flow (트리거 없음)'을 선택하고 '만들기'를 누릅니다.
- '새 리소스'에서 리소스 유형 '변수(Variable)' 4개를 만듭니다. 모두 데이터 타입은 '텍스트'입니다.
accountId는 '입력 사용 가능'에, 나머지 3개는 '출력 사용 가능'에 체크합니다 (이 체크를 한 변수만 액션의 입력/출력이 됩니다).
Flow 처리 부분
- '+' → '요소 추가' → '레코드 가져오기(Get Records)'를 선택합니다.
- 객체는 '기회(Opportunity)'입니다. 조건은 '계정 ID(Account ID)'가
{!accountId}와 같고, '완료(Is Closed)'가 {!$GlobalConstant.False}와 같습니다. - 정렬 기준은 '마감 예정일(Close Date)'의 오름차순입니다. '저장할 레코드 수'는 '모든 레코드'로 하고, 저장할 항목은 기회명, 단계(Stage), 금액, 마감 예정일 정도로 제한합니다.
- '루프(Loop)'를 추가하여 가져온 컬렉션을 하나씩 처리합니다.
- '새 리소스'에서 '텍스트 템플릿(Text Template)'을 만들어 한 줄 분량의 문장으로 만듭니다.
예: ・{!Loop_Opportunities.Name}（{!Loop_Opportunities.StageName}／{!Loop_Opportunities.Amount}원／마감 예정일 {!Loop_Opportunities.CloseDate}）
- 루프 안의 '할당(Assignment)'에서,
opportunityText에 템플릿을 연산자 '추가'로 더해 나갑니다.
ToDo와 활동도 같은 흐름으로 만듭니다.
- ToDo: 객체는 'ToDo'입니다.
조건은 '관련 계정 ID(Related To ID)'가 {!accountId}이고, '완료(Is Closed)'가 {!$GlobalConstant.False}입니다.
만기일의 오름차순입니다.
제목, 만기일, 상태를 todoText에 - 활동: 객체는 '활동(Activity)'입니다.
조건은 '관련 계정 ID(Related To ID)'가 {!accountId}이고, '시작 시간(Start Date/Time)'이 최근 3개월 이내입니다.
시작 시간의 내림차순입니다.
제목, 시작 시간을 eventText에
'최근 3개월 이내'는 '새 리소스'에서 '수식(Formula)' (데이터 타입은 '날짜/시간')을 만들어, NOW() - 90으로 설정합니다.
마지막으로, 0건일 때의 대응을 추가합니다. 0건이면 텍스트가 비게 되어 LLM이 '데이터 없음'인지 '가져오기 실패'인지 판단할 수 없게 됩니다.
각 '레코드 가져오기' 뒤에 '결정(Decision)'을 두고, 0건일 때는 '할당'으로 '해당 없음'을 넣습니다.
마지막으로 '저장'합니다.
'레이블', 'API 참조명'을 넣고, '설명'에 액션으로 사용할 때의 설명을 작성한 후, 저장하면 '활성화'합니다.
아래는 완성된 Flow 이미지입니다.
기회 가져오기 부분
ToDo 가져오기 부분
활동 가져오기 부분
완성된 Flow 메타데이터 샘플 (길어서 접었습니다)
<?xml version=
- 건수가 많으면 텍스트가 길어져 LLM 응답이 느려집니다. 조건이나 기간으로 필요한 건수에 한정하는 것이 좋습니다.
- ToDo와 행동은 거래처에 직접 연결되는 것만 포함합니다. 기회(商談)에 연결되는 것도 포함하고 싶다면, 기회의 ID도 조건에 추가해 주세요.
- 에이전트를 사용하는 사용자가 이 플로우를 실행할 권한을 가지고 있는지 확인하는 것도 좋습니다.
- 만드는 방법은 예시일 뿐입니다. 항목이나 텍스트의 형태는 업무에 맞춰 조정해 보세요.
##### 보충 설명
실제로는 레코드나 레코드 컬렉션 그대로 반환하는 것도 가능합니다. (Script의 액션 정의에서는 `list[object]`에 `complex_data_type_name: "lightning__recordInfoType"`을 지정하면 됩니다.)
그래도 텍스트로 만든 이유는 LLM에게 전달할 내용을 직접 결정하고 싶었기 때문입니다.
- 레코드 그대로 전달하면, 무엇이 전달될지는 레코드의 구조에 따라 달라집니다.
- 텍스트라면, 항목이나 순서나 건수나 날짜 표기 방식까지 플로우 측에서 정할 수 있습니다.
- 형식을 LLM에게 맡기지 않으므로 매번 같은 형태가 됩니다.
물론 단점도 있습니다. 텍스트로 만들면 구조가 사라집니다.
획득한 레코드의 ID로 업데이트하고 싶거나, 답변에 레코드 링크를 붙이고 싶을 때는 불편합니다. 그럴 경우에는 레코드로 반환하거나, 텍스트에 ID를 섞는 형태가 됩니다.
이번에는 LLM이 요약만 할 것이기 때문에, 텍스트로 충분했습니다.
#### STEP2: 서브 에이전트 만들기
거래처 요약의 서브 에이전트는 캔버스가 아니라, Agentforce Builder의 '스크립트' 뷰에서 코드를 작성하여 만듭니다. 플로우의 액션도 코드 안에서 정의합니다.
- 애플리케이션 런처에서 'Agentforce 스튜디오'를 엽니다.
- '에이전트' 탭에서 대상 에이전트를 클릭합니다 (Agentforce Builder가 새 탭으로 열립니다).
- 에디터를 '스크립트' 뷰로 전환합니다.
- `variables`에 사전 준비 변수를 추가합니다. -
아래의 `subagent Account_Summary:` 코드를 추가합니다. - '저장'하고 구문 오류가 없는지 확인합니다.
- '미리보기'에서 거래처 요약을 요청하여 작동시켜 봅니다.
액션의 `target`에는 플로우의 API 참조명을 지정합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
target: "flow://Get_Account_Summary_Data"
subagent Account_Summary:
label: "거래처 요약"
description: "거래처의 기회・ToDo・행동을 모아서 정형화된 요약을 출력합니다"
...
실제로 실행해 본 이미지는 이렇습니다.
출력 이미지 전문은 다음과 같습니다.
거래처 요약
## 1. 진행 중인 기회
보수 계약 갱신(2027년도)
상태: Negotiation/Review | 금액: 1,800,000원 | 완료 예정일: 2026년 10월 27일 생산관리 시스템 개편
상태: Proposal/Price Quote | 금액: 12,000,000원 | 완료 예정일: 2026년 11월 12일 공장 IoT 센서 도입
상태: Needs Analysis | 금액: 4,500,000원 | 완료 예정일: 2026년 12월 12일 품질 관리 대시보드
상태: Qualification | 금액: 2,400,000원 | 완료 예정일: 2027년 1월 11일 해외 거점 전개
상태: Prospecting | 금액: 30,000,000원 | 완료 예정일: 2027년 4월 11일## 2. 미완료 ToDo
견적서 최종본 송부 → 기한: 2026년 10월 16일 (Not Started)
보수 계약 갱신 조건을 법무팀에 확인 → 기한: 2026년 10월 18일 (Waiting on someone else)
품질 관리 부서 히어닝 준비 → 기한: 2026년 10월 25일 (Not Started)
해외 거점 담당자 소개 요청 → 기한: 2026년 11월 2일 (Not Started)## 3. 최근 행동
- 생산관리 시스템 개편 제안 설명회 (2026년 10월 8일 14:00)
- 공장 견학 (2026년 9월 25일 10:00)
- 보수 계약 업데이트 조건 회의 (2026년 9월 13일 15:00)
## 4. 궁금한 점
- 견적서 최종본 송부가 기한을 맞이하고 있습니다 (2026년 10월 16일)
- 유지보수 계약 갱신 조건 확인이 법무팀 대기 상태입니다
어떤 상담이나 건에 대해 자세히 듣고 싶으신 것이 있나요?
### 서브 에이전트② 방문 준비 아젠다 작성
거래처 요약(サマリー)에서 얻은 데이터를 사용하여, 다음 방문의 아젠다와 상대방에게 확인하고 싶은 질문 초안을 만드는 서브 에이전트입니다.
'다음 방문 준비를 하고 싶다'고 말을 걸면 초안을 내주고, 그 이후에는 '좀 더 짧게 해줘', '예산 이야기를 넣어줘' 같은 벽치기(brainstorming)도 할 수 있습니다.
#### 방침
- 서브 에이전트①에서 저장한 변수(`opportunity_text` 등)를 이어 사용한다 - 아직 얻지 못한 거래처의 경우에만 플로우를 실행한다
- 아젠다를 짜도록 하므로, 추론력이 높은 모델을 지정한다
- 데이터에 없는 것은 추측하지 않도록 요청한다
#### 변수 인계 구조
변수는 서브 에이전트를 넘나들며 공유됩니다. 서브 에이전트①에서 요약을 낸 후라면, 얻은 텍스트가 변수에 남아있기 때문에, 서브 에이전트②는 같은 데이터를 다시 가져갈 필요가 없습니다.
다만, 거래처를 전환했을 때 이전 거래처의 데이터를 사용하게 되면 곤란합니다. 그래서 `summary_account_id`라는 변수에 '어떤 거래처의 데이터가 이미 확보되었는지'를 저장해 둡니다.
- 서브 에이전트①과 서브 에이전트②에서 플로우 실행 후,
`summary_account_id`에 거래처 ID를 저장한다 - 서브 에이전트②에서는,
`summary_account_id`와 `target_account_id`가 다를 때만 플로우를 실행한다
'확보 여부'의 판별을 LLM에게 맡기지 않고, 코드로 작성한 점이 포인트입니다.
#### 만드는 방법
거래처 요약과 마찬가지로 '스크립트(Script)' 뷰에서 작성합니다.
- 'Agentforce 스튜디오' → '에이전트' 탭에서 대상 에이전트를 엽니다.
- 에디터를 '스크립트' 뷰로 전환합니다.
- `variables`에 `summary_account_id`를 추가합니다 (사전 준비 변수 참조) - 서브 에이전트①의
`subagent Account_Summary:`
에, `set @variables.summary_account_id = @variables.target_account_id`가 들어가 있는지 확인합니다 - 아래의
`subagent Visit_Prep:`
코드를 추가합니다 - 라우터에
`go_to_Visit_Prep`를 추가합니다 - '저장'하고, 구문 오류를 확인합니다
- '미리보기(Preview)'에서, 'OO사 요약을 내줘' → '다음 방문 준비를 하고 싶다' 순서로 말을 걸어봅니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
subagent Visit_Prep:
label:
생산관리시스템(MES) 개편 제안 설명회 이후, 제안 내용 및 견적 최종본에 대해 확인하거나 조정이 필요한 부분이 있습니까?
- 유지보수 계약 갱신 조건과 관련하여, 귀사 측에서 필요한 조치나 판단 사항이 있습니까?
- IoT 센서 데모는 언제쯤 진행하는 것을 예상하고 계십니까?
- 해외 거점 전개(横展開)를 위해 담당자분을 소개받을 수 있는 시기는 언제쯤 될 것 같습니까?
4. 사전에 준비해야 할 사항
- 생산관리시스템 개편의 견적 최종본을 확인하고, 송부 상황을 정리합니다.
- 생산관리시스템 개편 제안서의 내부 검토 진행 상황을 확인합니다.
- 유지보수 계약 갱신 조건에 관한 법무팀 검토 현황을 확인합니다.
- IoT 센서 데모 일정 후보를 정리합니다.
- 품질 관리 부서 대상 인터뷰 준비 상황을 확인합니다.
- 해외 거점 담당자 소개 요청과 관련하여, 확인 사항을 정리합니다.
방문 시에는 생산관리시스템 개편 및 유지보수 계약 갱신을 중심으로 진행하는 구성으로 괜찮겠습니까?
서브 에이전트③ 메모리 기록
