소개

참고: “주제”는 이 문서 전체에서 최신 제품 명명 규칙에 따라 “하위 에이전트”로 이름이 변경되었습니다.

테스트 환경에서는 에이전트가 잘 작동할 수 있지만, 동일한 워크플로를 두 번 처리할 경우 완전히 다른 경로를 따를 수 있습니다. 이 근본적인 한계는 이전 Agentforce 모델이 실행을 처리하는 방법을 보여줍니다. 의도 해석에서부터 작업 선택에 이르기까지 모든 결정은 LLM에 의해 실시간으로 이루어지며, 워크플로를 통한 경로가 보장되지 않습니다.

LLM은 동일한 입력에 대한 응답으로 일관되지 않은 결과를 생성할 수 있습니다. 컨텍스트, 시스템 프롬프트 또는 토큰 생성의 미묘한 변화만으로도 에이전트가 다른 경로로 갈 수 있습니다. 많은 상호작용의 경우 이러한 변동성은 허용됩니다. 그러나 감사 가능성, 재현 가능성, 추적 가능성이 필요한 다단계 워크플로는 그렇지 않습니다. 대출 승인, 재고 전송 또는 환자 분류 프로세스는 각 단계를 각기 다른 방식으로 설명하는 에이전트에 의존할 수 없습니다.

새로운 Agentforce Builder 및 Agent Script는 결정적 실행과 LLM 추론을 분리하여 이 문제를 해결합니다. Agentforce의 하이브리드 모델은 에이전트가 모든 워크플로 실행에서 정확하게 정의된 구조를 따르도록 보장하며, 판단, 자연어 이해 또는 컨텍스트 해석이 정말 필요한 경우에만 LLM 추론을 사용합니다.

이전 버전의 Agentforce 에이전트가 간단한 반응형 루프로 작동했습니다. 의도 해석에서 다음 작업 선택에 이르기까지 모든 결정은 사용자의 가장 최근 입력만을 기반으로 LLM이 실시간으로 내렸습니다. 보증된 실행 경로, 지속 상태, 단계 순서를 적용하는 메커니즘이 없었습니다.

실행 경로를 보장할 수 없음

모든 결정은 LLM의 실시간 추론에 따라 이루어졌기 때문에 입력, 시스템 프롬프트 또는 모델 버전의 약간의 변동만으로도 동일한 요청에 대해 다른 작업이 선택되었습니다. 이전 모델은 엄격하게 테스트하기 어려웠습니다. 스테이징에서 통과한 워크플로가 프로덕션 환경에서는 다르게 동작할 수 있고, 디버깅이나 감사 목적으로 특정 실행 경로를 재현할 수 있는 신뢰할 만한 방법이 없었습니다.

각 상호 작용은 LLM의 전체 비용을 지불합니다.

간단한 대화 시나리오에서도 하위 에이전트 선택, 작업 선택, 최종 응답 생성과 같은 최소 3개의 LLM 주기가 필요했습니다. 다단계 과업은 5개 이상의 주기로 확장됩니다. 대용량 또는 대기 시간에 민감한 워크플로를 설계하는 설계자에게 이는 단순히 성능 문제가 아니었습니다. 아키텍처에 이 둘을 구분하는 메커니즘이 없기 때문에, 판단이 필요하지 않은 단계에 대해서는 추론 루프를 단축할 수 없습니다.

비결정적 실행으로 인한 감사 격차

규제된 산업에서 감사 가능성은 특정 트랜잭션에 대해 특정 프로세스가 특정 방식으로 수행되었음을 증명할 수 있음을 의미합니다. 순전히 결정적이지 않은 모델은 이러한 보증을 제공할 수 없습니다. 실행 경로가 실행마다 달라지면 감사 내역도 달라지며, ‘에이전트가 결정한’이라는 답변은 규정 준수 심사에서 타당한 변명이 되지 않습니다.

상태가 대화에서 유지되지 않았음

단일 턴 처리에 의존하면 에이전트는 이전 단계에 대한 영구적인 기억을 유지하지 못한다는 의미입니다. 대화가 조금만 벗어나도 에이전트는 이전에 캡처한 컨텍스트를 잃어버려 사용자가 처음부터 다시 시작하게 만들 수 있습니다. 다단계 트랜잭션 워크플로의 경우 신뢰도 한도가 생성되었습니다. 프로세스의 단계가 많을수록 완료 전에 컨텍스트가 손실될 가능성이 높습니다.

완료된 단계가 기억되지 않음

상태 관리가 없으면 에이전트는 사용자가 이미 완료한 필수 단계를 기록하지 못했습니다. 이로 인해 예측할 수 없는 반복이 발생하여, 에이전트가 사용자가 이미 완료한 단계로 돌아갑니다. 사용자 경험 문제 외에도, 에이전트가 순서를 강제할 수 없게 되어 신뢰할 수 있는 순차적 워크플로 설계가 불가능하다는 더 심각한 아키텍처 문제가 발생했습니다.

새로운 Agentforce, GA는 2026년 2월부터 순수한 확률적 LLM 추론에서 하이브리드 모델로 전환합니다. LLM을 통해 모든 결정을 라우팅하는 대신 결정적 실행을 LLM 추론과 구분하여 각각 적합한 사항만 처리할 수 있습니다. 이를 지원하기 위해 Agentforce는 두 가지 작성 도구를 도입했습니다: 코드 기반 개발을 위한 Agent Script 및 Agentforce Studio, 코드 없는 빌드 환경.

Agentforce 빌더

Agentforce Builder는 새로운 에이전트를 개발하는 데 적합한 환경입니다. Agentforce Studio 내에서 호스팅되며 기존 설정 환경을 대체합니다. 이 환경은 계속 사용할 수 있지만 더 이상 기본 작성 경로가 아닙니다. Builder에서는 시각적 Canvas 보기 또는 Script 보기 중 하나에서 작업하며, 에이전트의 동작을 정의하는 Agent Script를 편집합니다.

Agent Script

Agent Script는 에이전트의 구성, 비즈니스 논리, 프롬프트 지침 등 에이전트의 행동 방식을 모두 정의하는 선언적 도메인 특화 언어(DSL)입니다. 여러 줄에 걸치거나 중첩된 하위 속성을 포함할 수 있는 키-값 쌍으로 구조화되어 있으며, 기본 그래프 아키텍처에 대한 지식이 없어도 사람이 읽을 수 있도록 설계되었습니다.

에이전트 스크립트를 사용하면 같은 에이전트에서 결정적 논리 지침과 프롬프트 지침의 두 가지 근본적으로 다른 유형의 지침을 표현할 수 있습니다. 결정적 논리 지침은 LLM의 참여 없이 코드로 실행되는 조건 및 작업 시퀀스를 정의합니다. 프롬프트 지침은 LLM이 런타임 시 해석하는 자연어 지침을 정의합니다. 둘 사이의 경계는 명시적이고 의도적이며, 그 경계를 어디에 둘지 파악하는 것이 새로운 Agentforce로 구축할 때 내리게 되는 핵심 설계 결정 중 하나입니다.

실무에서의 결정적 논리

지침이 결정적일 경우 에이전트는 사용자가 입력한 방식과 관계없이 정해진 실행 경로를 따릅니다. 아래 예는 고객 인텔리전스 대시보드를 로드하는 하위 에이전트를 보여줍니다. 고객 ID를 확인하고 프로필 데이터, 주문 내역, 지원 티켓을 가져온 다음, 고객 생애 가치 및 이탈 위험을 계산합니다. 이러한 단계에는 LLM 추론이 필요하지 않습니다.

이 논리는 특정 조건이 충족될 때마다 고정된 순서로 작업을 호출합니다.

프롬프트 지침 및 의도적인 LLM 전환

결정적 논리가 코드로 표현할 수 있는 조건 및 순서를 처리하는 경우, 프롬프트 지침은 판단, 해석 또는 자연어 생성을 요구하는 모든 사항을 처리합니다. Atlas Reasoning Engine이 프롬프트 명령이 포함된 노드에 직면하면 LLM 호출이 트리거됩니다. 그렇지 않으면 결정적으로 실행됩니다.

아래 예는 제품 및 서비스에 대한 하위 에이전트를 보여줍니다. 지침은 LLM에 응답하는 방법, 정보를 조회할 시기, 모호한 상황을 처리하는 방법을 알려주는 다중 줄 프롬프트입니다. 이는 가능한 사용자 입력 범위가 조건부 논리로 예측하기에 너무 넓거나 응답의 품질이 LLM의 컨텍스트 해석 및 자연 회신 생성 능력에 따라 달라지는 경우에 적합한 패턴입니다.

노드의 프롬프트 지침은 LLM 호출을 트리거합니다. 이는 우연이 아니라, Agent Script가 LLM 경계를 명확하고 강제 가능하게 만드는 메커니즘입니다. 즉, 이를 런타임 추론에 맡기지 않고 명확히 구분하고 강제합니다.

이 하위 에이전트는 결정적 논리와 LLM 간의 제어권 이양 과정을 보여줍니다.

3단계 실행 파이프라인

Agentforce Builder 및 Agent Script는 작성 레이어이지만 Agent Graph 및 Atlas Reasoning Engine은 실제로 에이전트를 실행합니다. 설계에 따라 해당 구성 요소에 직접 액세스할 수 없습니다. 작성 및 실행을 분리하면 플랫폼이 스크립트가 작성된 방식과 상관없이 결정적 동작을 적용할 수 있습니다.

파이프라인은 세 가지 단계를 거칩니다.

1. 당신이 일하는 곳은 작성입니다. 에이전트 스크립트는 Agentforce 빌더의 캔버스 보기 또는 스크립트 보기에서 읽을 수 있으며 편집할 수 있습니다. 이는 직접 상호 작용하는 유일한 레이어입니다.
2. 컴파일은 Salesforce 컴파일러가 에이전트 스크립트를 에이전트 그래프로 변환하는 단계로, 이는 인간이 읽는 것이 아니라 기계 실행에 최적화된 일련의 실행 계획입니다. 이 레이어에서는 디버깅할 수 없습니다. 컴파일은 런타임이 효율적으로 이동할 수 있는 표현을 생성합니다.
3. 런타임 실행은 Atlas Reasoning Engine이 주도하는 작업입니다. 에이전트 그래프를 읽고 현재 세션 상태를 기반으로 이동한 후 각 노드에서 결정적 실행 여부 또는 LLM 호출 여부를 결정합니다. 엔진은 가드 절 및 조건부 라우팅을 추론하는 대신 명시적으로 적용합니다.

에이전트 그래프

에이전트 그래프는 사람이 읽을 수 있는 스크립트와 실제 런타임 실행 사이에 있는 중간 표현입니다. 구조는 스크립트를 작성한 설계자가 아니라 이를 사용하는 상태 기계에 최적화되어 있습니다. 스크립트에 정의된 실행 계획을 적용하는 데 Reasoning Engine이 사용하는 산출물이므로, 그 존재와 의미를 이해하는 것이 중요합니다.

Atlas Reasoning Engine

Atlas Reasoning Engine은 상태 머신 실행기입니다. 매 턴마다 세션 상태에 따라 에이전트 그래프를 탐색하고, 결정적 노드는 코드처럼 실행되며, 프롬프트 명령이 존재할 때만 LLM 호출을 트리거합니다. 또한 가드 절을 적용하고 조건부 라우팅을 처리합니다. Reasoning Engine은 하이브리드 추론 모델이 실제로 구현되는 곳이며, 스크립트가 경계를 정의하고 엔진이 이를 준수합니다.

에이전트 그래프는 LLM 래퍼가 아닙니다. 결정적 실행과 확률적 추론을 구분하는 하이브리드 추론 엔진입니다. 규칙은 간단합니다. 결정을 코드로 표현할 수 있는 경우 논리로 작성해야 합니다. 결정에 판단, 해석 또는 자연어 생성이 필요한 경우 LLM에서 처리해야 합니다. 이 설계 결정은 새로운 Agentforce 모델에서 가장 중요한 아키텍처 선택입니다. LLM 경계가 속하는 곳은 솔루션의 비용, 대기 시간, 감사 가능성, 신뢰도에 직접적인 영향을 미칩니다.

Atlas Reasoning Engine은 들어오는 모든 사용자 턴을 평가하고 두 경로 중 하나로 분기합니다.

경로 A: 결정적 실행

이 경로에는 LLM 노출이 없습니다. 런타임 시 컴파일된 코드처럼 동작합니다. Reasoning Engine은 사용자의 의도를 분류하고 논리 명령이 일치한다고 판단하면 LLM을 완전히 우회합니다. 컴파일된 에이전트 스크립트는 상단부터 하단까지 순차적으로 실행되며, if-else 규칙은 매 턴마다 조건 없이 실행됩니다. Flow, Apex 또는 REST API 작업은 결정적 매개변수로 호출되며, 프롬프트 구성이나 모델 호출과는 관련이 없습니다. 결과는 전체 감사 로깅과 함께 신뢰 계층을 통해 전달됩니다.

경로 B: LLM 논리

논리 명령만으로 의도를 해결할 수 없는 경우 Reasoning Engine이 이 경로를 따릅니다. 에이전트 그래프를 탐색하고 각 노드를 평가합니다. 프롬프트 명령이 있는 노드는 LLM 호출을 트리거합니다. 노드가 없는 노드는 결정적으로 실행됩니다. 프롬프트 명령의 존재는 트리거이며 런타임 시 추론되지 않고 스크립트에서 명시적입니다.

LLM 호출 트리거

실행 수명 주기에서 LLM이 호출되는 8개 지점이 있습니다. 하위 에이전트 분류, 즉 사용자의 요청과 일치하는 하위 에이전트를 결정하는 것은 하나의 경우에 해당하지만, 분류가 명확할 경우 짧은 회로 경로로 전체 LLM 호출을 우회할 수 있습니다. 에이전트가 다음에 수행할 조치를 결정하는 과정, 즉 에이전트 추론은 항상 LLM을 거칩니다. 응답 생성 역시 마찬가지입니다. 여기서 최종 응답은 채워진 프롬프트로부터 조합됩니다.

나머지 트리거는 보다 운영적인 측면을 포함합니다. 근거 검증은 출력이 검색된 데이터에 기초하는지 확인하고, 작업 시뮬레이션은 실시간 실행 대신 미리보기 및 시뮬레이션 환경에서 응답을 모사하며, 구조화된 출력 생성은 응답이 정의된 스키마를 따라야 하는 경우를 처리합니다. 또한 현지화와 진행률 표시기 생성은 사전에 작성된 기본값이 없는 경우에 형식 지정 및 일시적인 메시지 생성을 담당합니다.

결정적으로 유지되는 항목

그래프 탐색 및 상태 전이는 LLM이 관여하지 않습니다. before_reasoning 및 after_reasoning 수명 주기 블록은 프롬프트 명령이 없는 작업 노드만 포함하는 한 결정적으로 실행됩니다. 수학, 데이터 가져오기, 유효성 검사 및 조건부 논리는 모두 코드에서 처리됩니다. Flow, Apex 또는 REST API를 직접 실행하는 작업은 결정적 경로에 유지됩니다. 프롬프트 명령이 없는 노드는 LLM 호출 없이 실행됩니다.

팀과 이 경계에 대해 명시적으로 설명하는 것이 중요합니다. 불필요한 모든 LLM 호출은 대기 시간, 비용, 가변성을 추가합니다. 설계자는 기본적으로 결정적 논리를 우선 적용하고, 실제로 작업에 추론 기능이 필요한 경우에만 LLM을 사용해야 합니다.

설계 지침: 기본적으로 논리를 코드로 구현

조건, 변수 할당 또는 작업 필터로 표현할 수 있는 프롬프트 명령을 작성할 때 에이전트 스크립트 논리 지침을 사용합니다. 불필요한 모든 LLM 호출은 대기 시간, 비용, 가변성을 추가합니다.

기본 위치는 결정적이어야 합니다. 규칙으로 코딩할 수 있는 모든 에이전트 동작을 분리하고 에이전트 스크립트로 이동합니다. 자연어 합성, 컨텍스트 판단 또는 복잡한 해석이 필요한 나머지 과업은 프롬프트를 포함하는 노드에 속합니다. 제한 사항이 아니라 의도한 대로 작동하는 경계입니다. LLM은 가장 적합한 항목을 처리하며 기타 모든 항목은 코드로 실행됩니다.

에이전트 스크립트의 기본 실행 단위는 사용자 전환이 아닙니다. 구문 분석 - 하위 에이전트의 세 가지 수명 주기 블록을 통한 단일 전체 주기입니다. Atlas Reasoning Engine은 하위 에이전트가 무언가를 처리해야 할 때마다 구문 분석을 시작합니다. 이는 세 가지 상황에서 발생합니다: 하위 에이전트에 처음 진입할 때, 작업이 완료되어 결과가 반환되는 모든 도구 호출 후, 그리고 동일한 하위 에이전트 내에서 새로운 사용자 전환이 있을 때입니다.

구문 분석 경계를 이해하는 것은 각 블록의 실행 횟수를 결정짓기 때문에, 특정 논리가 정확히 한 번만 실행된다고 보장할 수 있는지를 판단하는 데 중요합니다.

모든 하위 에이전트는 다음 세 가지 실행 영역을 정의합니다.

before_reasoning와 after_reasoning 모두 완전히 결정적입니다. LLM을 포함하지 않고 작업을 실행하고 변수를 설정하며 조건부 논리를 적용합니다. 이로 인해 스크립트 내에서 신뢰할 수 있는 저비용 블록이 됩니다.

사용 시기 before_reasoning

before_reasoning는 예외 없이 모든 구문 분석의 시작 부분에 실행됩니다. 하위 에이전트에 첫 번째 진입 시 실행되고 도구 호출을 마치거나 하위 에이전트 내에서 새 사용자가 전환된 후 다시 실행됩니다. run @actions.X의 before_reasoning은 코드입니다. LLM이 따르거나 따르지 않을 수 있는 프롬프트 블록 내 명령과 달리, before_reasoning은 조건 없이 실행됩니다.

세션 초기화에 이 블록을 사용합니다. 컨텍스트 레코드를 가져오고 Apex 또는 Flow에서 세션 변수를 설정합니다. 또한 LLM이 도구를 보게 되기 전에 인증 및 권한 검사를 수행해야 하기 때문에, 이곳에 포함되어야 합니다. 컨텍스트 하이드레이션도 여기에 해당합니다. 즉, 데이터 검색 작업을 호출하여 LLM이 직접 요청하지 않고 사전 채워진 변수를 받을 수 있도록 합니다. 모든 구문 분석에서 증분해야 하는 카운터 또는 감사 변수는 여기서 설정해야 합니다. before_reasoning의 set 지시문은 파이프 지시문이 아닌 방식으로 보장되기 때문입니다.

여기 속하지 않는 것은 세션당 한 번만 실행해야 하는 논리입니다. before_reasoning는 첫 번째 항목뿐 아니라 모든 구문 분석에서 실행되기 때문입니다. 현재 턴의 사용자 입력에 의존하는 항목도 여기에 속하지 않습니다. 그 입력이 아직 처리되지 않았기 때문입니다. 그리고 전환은 절대로 before_reasoning에 있어서는 안 됩니다. 여기서 transition to 지침은 모든 구문 분석에서 조건 없이 실행되어 루프를 만듭니다.

세션당 한 번 초기화가 필요하다면, 이를 명시적으로 보호하세요:

한 번의 사용자 턴은 진입 시 한 번, 그리고 각 도구 호출 후에도 구문 분석을 다시 유발할 수 있습니다. 이 기능에는 세 가지 실질적인 결과가 있습니다. before_reasoning의 초기화 작업은 다중 작업 플로우에서 사용자 턴마다 한 번 이상 실행됩니다. 여기서 증분된 카운터 변수는 턴 수가 아니라 구문 분석 수를 반영합니다. 그리고 부작용이 있는 작업, 외부 API 호출 또는 레코드 쓰기와 같은 작업은 모든 구문 분석마다 재실행이 명시적으로 허용되는 경우가 아니라면 before_reasoning에 두지 않아야 합니다.

before_reasoning는 생성자가 아닙니다. 모든 구문 분석마다 실행되는 사전 점검입니다. 그에 맞게 설계하세요.

after_reasoning 사용 시기

논리 루프가 완료되면 LLM이 응답하고 작업 결과가 수집된 후 after_reasoning이 실행됩니다. 여기가 작업 후 결정적 검사를 수행하는 곳입니다. 즉, 작업 출력 평가와 결과에 따른 분기가 여기에 해당합니다. 결정적 전환, 즉 LLM의 판단이 아닌 변수 상태에 따라 다음 하위 에이전트로 이동하는 것도 여기에 해당합니다. 다음 턴 전에 변수 정리를 하거나, LLM 라우팅 결정 없이 예측 가능한 순서로 하위 에이전트를 연결해야 할 때 오케스트레이션 시퀀싱을 하는 것도 여기에 해당합니다.

after_reasoning를 가드레일 레이어로 취급하세요. LLM이 작업을 완료한 후, 비즈니스 규칙과 상태 관리를 강제하여 LLM이 생성한 내용과 상관없이 중요한 프로세스 흐름이 예측 가능하도록 합니다.

is_displayable: True를 현명하게 사용하세요

오케스트레이션 플로를 설계하는 모든 설계자는 이 플랫폼 동작을 이해해야 합니다. 작업에 is_displayable: True가 설정되면 LLM이 해당 출력을 표시하기로 결정하는 즉시 플랫폼은 추론 루프를 종료합니다. 이 종료는 즉시 발생하므로 after_reasoning는 실행되지 않습니다.

이것은 알려진 플랫폼 동작이지만, 오케스트레이션에 직접적인 영향을 미칩니다. 표시 가능한 작업이 흐름에 포함될 경우 after_reasoning에 배치한 논리는 건너뛰어집니다.

해답은 간단합니다. 반드시 실행되어야 하는 논리는 현재의 after_reasoning 블록이 아니라 후속 하위 에이전트의 before_reasoning 블록에 신뢰성 있게 배치해야 합니다.

설계 지침: 초기화 논리를 어디에 배치할지

하위 에이전트를 설계할 때 논리를 어디에 배치할지 결정하는 것은 매우 중요합니다. 이 프레임워크는 가장 일반적인 시나리오를 다룹니다.

기본 원칙은 간단합니다. LLM에 작업을 “항상 실행”하라고 지시하는 프롬프트 명령을 작성해도, 이는 제안에 불과합니다. LLM은 컨텍스트에 따라 따를 수 있거나 따를 수 없습니다. run 지시문을 before_reasoning에 넣으면, 그것은 코드입니다. 이는 예외 없이 모든 구문 분석에서 실행됩니다.

조건부 작업 가용성은 런타임 변수 상태를 기반으로 에이전트 스크립트가 LLM에서 작업을 표시하거나 숨기는 메커니즘입니다. available when 조건이 false로 평가되면 LLM에 표시된 도구 목록에서 작업이 완전히 제거됩니다. None, False, 0 또는 빈 문자열을 포함한 모든 잘못된 값은 작업을 억제합니다.

이는 LLM에 “아직 호출하지 마세요”라는 프롬프트 명령이 아닙니다. 이는 하드 플랫폼 수준의 게이트입니다. LLM은 액세스할 수 없는 작업을 호출할 수 없습니다.

이 예에서는 validation_passed가 true로 평가될 때까지 LLM에 execute_transfer가 표시되지 않습니다. 게이트는 명령이 아니라 플랫폼에 의해 적용됩니다.

설계 지침: LLM에서 게이트 변수를 설정해서는 안 됩니다.

available when 절의 모든 변수에 연결된 작업이 실행되기 전에 변수를 설정하는 결정적 코드 경로를 지정합니다. before_reasoning 또는 reasoning의 결정적 run 및 set 블록을 사용하여 변수를 알려진 상태로 유지합니다. LLM에 게이트 변수를 설정하도록 맡기면, 게이트가 방지하도록 설계된 변동성이 다시 도입됩니다. 대화에 따라 LLM에서 설정하거나 설정하지 않을 수 있습니다. 즉, 게이트가 열리거나 열리지 않을 수 있습니다.

작업 루프 문제

작업 루프는 LLM이 종단 상태에 도달하지 않고 동일한 작업을 반복적으로 호출하면 발생합니다. 두 가지 조건이 동시에 참인 경우 발생합니다. 작업이 실행된 후에도 available when 조건이 충족된 상태로 유지되며, 추론 지침이 LLM에 해당 조건을 중지하도록 명시적으로 지시하지 않습니다.

플랫폼에서 호출한 후에는 작업이 자동으로 억제되지 않습니다. 게이트가 열려 있고 추론 지침이 모호한 경우 LLM은 모든 구문 분석에서 무기한으로 동일한 작업을 호출합니다.

available when @variables.interest != ""을 예로 들어보십시오. 작업이 실행되지만 관심 변수가 비어 있지 않은 경우 다음 구문 분석에서 게이트가 계속 열립니다. LLM은 작업을 사용 가능한 것으로 보고 중지하라는 지침이 없으며 다시 호출합니다.

두 가지 신뢰할 수 있는 방법으로 루프를 중단할 수 있습니다. 첫 번째는 작업의 후실행 논리에서 게이트 변수를 닫힌 상태로 설정하는 것입니다. 따라서 다음 구문 분석에서 available when가 false로 평가됩니다. 두 번째는 첫 번째 실행 후 게이트를 닫는 별도의 has_run 부울을 사용하는 것입니다. 두 가지 접근 방식 모두 게이트에 결정적 마감 상태를 제공하며, 이는 플랫폼이 작업을 억제하는 데 필요한 조건입니다.

은행 송금은 이러한 패턴이 실제로 함께 작동하는 방식을 이해하는 데 유용한 렌즈입니다. 워크플로우는 한 계정에서 다른 계정으로 돈을 이동하는 것처럼 간단하게 보입니다. 구현에는 복잡한 여러 단계가 필요합니다. 송금을 실행하기 전에 에이전트는 계정 세부 사항을 수집하고, 금액을 확인하고, 송금 한도를 확인하고, 사용 가능한 잔액을 확인한 후에만 송금 작업을 노출해야 합니다. 각 단계는 이전 단계에 따라 다릅니다. 아무 것도 LLM 판단에 남겨 둘 수 없습니다.

입력 수집 및 검증

첫 번째 하위 에이전트가 소스 계정, 대상 계정, 그리고 송금 금액을 사용자로부터 수집합니다. 세 가지가 모두 존재하고 유효할 때까지 진행되지 않습니다. 에이전트 스크립트는 순서대로 각 필드를 확인합니다. 소스 계정이 누락된 경우 요청합니다. 대상이 누락된 경우 요청합니다. 금액이 0 또는 음수인 경우 요청합니다. 모든 확인이 완료된 후에만 validation_passed 변수가 true로 설정됩니다.

아래의 스크립트는 실행에서 이를 보여줍니다. 각 오류 지점에서 validation_passed이 명시적으로 false로 설정되어 있으며, LLM에 계속 진행하지 말라는 지시가 표시됩니다. 결정적 확인은 조건 없이 실행되고 프롬프트 명령은 사용자 대면 응답을 처리합니다.

비즈니스 규칙 적용

에이전트가 입력을 확인한 후 송금 금액이 설정된 송금 한도를 초과하는지 여부를 확인합니다. 여기서 비즈니스 규칙이 명령이 아닌 코드가 됩니다. 제한은 LLM의 이유가 아니라 스크립트에 정의되고 모든 구문 분석에서 결정적으로 확인되는 하드 임계값입니다.

금액이 한도를 초과하면 validation_passed가 다시 false로 설정되고, LLM은 사용자에게 최대 허용 금액 송금, 여러 번에 나누어 송금, 또는 더 높은 한도를 위해 지원팀에 문의하는 세 가지 옵션을 제공합니다. 에이전트는 사용자가 예외를 해결할 때까지 진행할 수 없습니다. 여기에 명시된 프롬프트 명령은 대화식으로 옵션을 제시하고 사용자의 응답을 처리하는 방식으로 LLM 추론이 적합한 작업을 정확하게 수행합니다. 비즈니스 규칙 자체는 결정적이지만 해당 규칙에 대한 대화는 결정적이지 않습니다.

아래 스크립트는 제한 검사가 작동하는 방식을 보여줍니다. 결정적 조건은 제한 변수에 대해 전송 금액을 평가하고, 임계값이 위반되는 경우 validation_passed을 false로 설정하고, 사용자 대면 응답을 처리하는 프롬프트 명령에 위임합니다.

가드 절을 적용하세요

금액 및 제한 확인이 완료되면 에이전트가 소스 계정 잔고를 가져와 자금이 충분한지 확인합니다. 가드 절은 전제 조건이 충족되지 않을 경우 에이전트가 작업을 시도하지 못하도록 합니다. LLM에 잔액을 확인하도록 지시하는 프롬프트 명령과 달리, 에이전트 스크립트의 가드 절은 확인을 무조건적으로 수행합니다. LLM은 실행 여부를 결정하지 않습니다.

잔액이 부족하면 에이전트는 부족분을 계산하고 사용자에게 구체적인 대안을 제시합니다. validation_passed은(는) 이 검사가 통과될 때까지 false로 설정되어, 전송 작업의 진행이 제한됩니다.

아래 스크립트는 잔액을 가져오는 결정적 작업 호출을 표시한 다음, 조건부 확인을 통해 평가합니다. 잔액이 아직 검색되지 않은 경우에만 가져오기가 실행되므로 후속 구문 분석에서 API 호출이 중복되지 않습니다.

오류를 명확하게 표시하세요

가드 절이 상태를 설정합니다. 오류 메시지가 이를 전달합니다. validation_passed가 false인 경우 에이전트는 사용자에게 문제를 다시 시작하지 않고 해결할 수 있는 충분한 정보를 제공해야 합니다. 모호한 오류 메시지는 마찰을 유발하며, 구조화된 오류 메시지는 문제를 더 빠르게 해결할 수 있습니다.

아래 스크립트는 실제로 잔액 부족 오류 메시지를 보여줍니다. 단순히 사용자에게 전송이 실패했음을 알리는 것은 아닙니다. 사용 가능한 잔액, 요청 금액, 계산된 부족이 표시되며, LLM에서 생성하지 않고 세션 변수에서 조합된 구체적인 다음 단계를 제공합니다.

부족 계산은 LLM이 아닌 스크립트에서 수행됩니다. 사용 가능한 잔액을 전송하는 제안된 대안은 세션 상태에서 결정적으로 파생됩니다. 여기에서 LLM의 역할은 순전히 프레젠테이션 방식이며, 스크립트가 이미 구조화된 메시지를 전달합니다.

전송 작업을 제한하세요

이전 단계의 모든 유효성 검사는 동일한 변수를 설정하거나 지웁니다. validation_passed. 이제 해당 변수가 가장 중요한 작업을 수행합니다. execute_transfer 작업은 조건부로 사용할 수 있습니다. 즉, validation_passed가 true인 경우에만 LLM의 도구 목록에 나타납니다. 모든 이전 검사를 통과하고 해당 변수를 설정할 때까지 LLM의 관점에서 작업이 존재하지 않습니다.

이는 프로덕션 워크플로에 적용된 이전 게이트 섹션의 패턴입니다. 전송 작업은 프롬프트 명령에 의해 숨겨지지 않습니다. 플랫폼에 의해 숨겨집니다. 어떠한 대화 압박이나 모호한 표현도 전제 조건이 충족되기 전에 LLM이 이를 호출하게 만들 수 없습니다.

아래 스크립트는 게이트 구성 방법을 보여줍니다. available when 절은 validation_passed를 직접 참조하며 작업 매개 변수는 이전 단계에서 수집 및 검증된 세션 변수에 바인딩됩니다.

세 가지 매개 변수(from_account, to_account 및 amount) 모두 세션 변수에서 결정적으로 전달됩니다. 이 작업을 사용할 수 있게 되면 모든 값이 확인되었습니다. LLM은 대화 컨텍스트에서 매개 변수를 어셈블하는 것이 아니라 상태에서 매개 변수를 읽는 것입니다.

워크플로 전반의 상태를 추적하세요

이전 섹션의 패턴은 전체 워크플로에서 세션 상태가 유지되므로 작동합니다. 첫 번째 단계에서 수집한 계정 번호는 네 번째 단계에서 사용할 수 있습니다. 한 단계에서 설정된 유효성 검사 결과가 다른 단계의 체크 게이트 작업에 적용됩니다. 대화가 편향될 수 있으며, 사용자는 후속 질문을 할 수 있으며, 에이전트는 계속해서 정확하게 진행 중인 위치를 파악할 수 있습니다.

아래의 변수 블록에 이 워크플로의 전체 세션 상태가 표시됩니다. 각 변수에는 정의된 유형, 기본값 및 설명이 있습니다. 오케스트레이션 작업의 대부분은 두 가지 변수로 처리됩니다. validation_passed는 모든 게이트에서 액션 가용성을 제어하고, validation_information는 검사가 실패한 이유에 대해 인간이 읽을 수 있는 컨텍스트를 가져옵니다. 이 컨텍스트는 LLM이 기본 상태에 대해 설명할 필요 없이 사용자에게 표시할 수 있습니다.

모든 변수가 알려진 기본 상태에서 시작됩니다. 문자열은 기본적으로 공백으로, 숫자는 0으로, validation_passed 부울은 false로 설정됩니다. 즉, 게이트는 기본적으로 닫혀 있습니다. 워크플로는 각 단계마다 진행 권한을 적극적으로 획득해야 하며, 게이트가 처음부터 열린 상태로 시작하여 확인을 통해 닫히는 방식이 아닙니다.

은행 이체 예제는 결정적 논리가 올바른 도구인 곳을 설명하지만, 항상 가장 적합한 선택은 아닙니다. 경계를 이해하는 것은 패턴을 이해하는 것만큼이나 중요합니다.

결정적 논리는 워크플로에 보증된 실행 순서가 필요한 경우, 오류로 인한 심각한 결과가 있는 경우, 프로세스에서 재현 가능한 감사 내역을 생성해야 하는 경우 또는 비즈니스 규칙이 조건 및 임계값으로 표현될 수 있을 만큼 잘 정의된 경우에 적합한 선택입니다. 금융, 헬스케어, 보험 워크플로는 일반적으로 이 범주에 속합니다.

엄격한 결정적 제약이 없는 순수한 LLM 추론은 상호 작용의 가치가 정밀도가 아닌 유연성에 있으면 더 적합합니다. 개방형 고객 지원, 비즈니스 프로세스가 여전히 발전하고 있는 초기 단계의 제품, 그리고 위험이 낮은 정보성 질의는 모두 LLM 추론의 가변성이 문제가 아니라 특징인 경우입니다.

실제로 대부분의 프로덕션 에이전트는 둘 다 필요합니다. 경계의 위치를 결정하는 것은 결정적과 확률적 중 하나를 선택하는 이진적 선택이 아니라, 에이전트 워크플로의 각 부분마다 노드 수준에서 내리는 설계 결정입니다.

경계는 설계 결정입니다.

은행 이체 예제는 결정적 실행과 LLM 추론 간의 경계가 프로덕션 에이전트를 구축할 때 결정적으로 가장 중요한 아키텍처 결정이라는 설계 철학을 보여줍니다.

너무 경직된 경계를 설정하면, 경직되고 유지 관리가 어렵고 실제 대화의 자연스러운 변화를 처리하지 못하는 에이전트가 만들어집니다. 반대의 방향으로 경계를 잘못 가져오면 유연하지만 예측할 수 없는 에이전트가 생성되며, 테스트를 잘 수행하지만 프로덕션에서 다르게 동작하며 신뢰할 수 있는 감사 추적을 생성하거나 중요한 거래를 신뢰할 수 없는 에이전트가 생성됩니다.

새로운 Agentforce 모델은 해당 경계를 의도적으로 설정할 수 있는 도구를 제공합니다. Agent Script를 사용하면 결정적 논리와 프롬프트 지침을 동일한 파일에서 표현할 수 있으며, 경계가 명확히 드러나도록 명시적인 구문을 사용할 수 있습니다. Atlas Reasoning Engine은 런타임 시 논리와 프롬프트를 적용합니다. before_reasoning 및 after_reasoning 블록은 LLM 호출의 양쪽에 보장된 실행 영역을 제공합니다. 조건부 작업 가용성은 전제 조건이 충족된 경우에만 LLM이 작업을 수행할 수 있도록 합니다.

이러한 기능들은 독립적으로 존재하지 않습니다. 이 기능들은 함께 작동하여 기업에서 미션 크리티컬 워크플로를 신뢰할 수 있는 에이전트를 구축할 수 있는 일관된 아키텍처를 만듭니다. 하이브리드 추론 모델은 결정성과 유연성이 모두 아키텍처에서 역할을 한다는 것을 인식합니다. 각각의 적용 위치를 정확하게 결정하는 것은 설계자의 업무입니다.

에이전트 스크립트 레시피

Agentforce 개발자 가이드

Agentforce의 에이전트 그래프: 하이브리드 추론을 통한 안내형 결정주의

Gulal Kumar는 20년 이상의 경험을 보유한 Salesforce의 소프트웨어 엔지니어링 아키텍트입니다. 그의 전문 지식은 AI, 통합, API, 엔터프라이즈 아키텍처에 걸쳐 있으며, 안전하고 복원 가능하며 혁신적인 AI 솔루션을 통해 비즈니스 전환을 촉진하는 데 중점을 둡니다. 그와 LinkedIn에서 연결하십시오.

Miriam McCabe는 선임 디렉터이며 Architect Evangelism 팀의 리더입니다. 그녀의 업무는 전 세계 Salesforce 아키텍트 커뮤니티가 에이전트 시대를 주도할 수 있도록, 심도 있는 기술 콘텐츠, 라이브 프로그래밍, 그리고 커뮤니티 참여를 통해 지원하는 데 중점을 둡니다. 그녀를 LinkedIn에서 팔로우하십시오.