StrategyMap

비즈니스 사용자가 원하는 것은 단순한 Q&A 답변이 아니라, 실제 도구와 업무 규칙 안에서 실행 가능한 의사결정인 경우가 많다. 예를 들어 S&OP 업무에서 재고 이동을 추천하려면 현재 재고, 수요 약속, 서비스 수준 조건을 먼저 확인해야 한다. 최종 추천 문장이 그럴듯해도, 이런 선행 검증을 건너뛰었다면 운영 관점에서는 잘못된 답이다.

이 문제는 에이전트가 어떤 도구를 쓸 수 있는지 아는 것만으로 해결되지 않는다. 현재까지 어떤 단계가 완료되었는지, 어떤 단계가 지금 가능한지, 아직 어떤 단계가 막혀 있는지를 알아야 한다. 긴 실행 기록에는 이 정보가 숨어 있지만, 에이전트가 매 순간 raw trace에서 절차 상태를 다시 추론하는 것은 불안정하다.

완전히 고정된 workflow script도 충분하지 않다. script는 순서를 강하게 보장하지만, 실제 업무에서는 중간 관찰값이나 사용자 조건에 따라 다음 행동이 달라질 수 있다. 반대로 자율적인 trace 기반 agent는 유연하지만, process state가 길고 noisy한 history 안에 묻힌다. 필요한 것은 더 긴 프롬프트나 더 많은 tool catalog가 아니라, 실행 중에 현재 절차 상태를 명시적으로 보여주는 계층이다.

StrategyMap은 사람이 검토한 업무 절차를 milestone과 dependency로 표현하고, 실행 중에는 Working Map으로 completed, admissible, blocked 상태를 드러낸다. 에이전트는 전체 절차를 외워서 움직이는 것이 아니라, 현재 확인된 process state에서 다음으로 유효한 지점을 고른다. 그래서 StrategyMap은 workflow를 프롬프트에 붙이는 방식이 아니라, 업무 지식을 실행 시점의 상태 표현으로 바꾸는 방법이다.

Business users often need more than an answer. They need a decision or service outcome that can be executed through real tools under explicit business rules. In an S&OP allocation task, for example, an agent should not recommend a supply transfer before checking inventory, demand commitments, and service-level constraints. A final recommendation may sound plausible, but it is operationally invalid if prerequisite checks were skipped.

This problem is not solved by giving the agent more tools. The agent must know which process states are completed, which next steps are admissible, and which future steps remain blocked. Long traces contain some of this information, but requiring the agent to infer process state from raw history at every turn is fragile.

Fully scripted workflows are also insufficient. They make prerequisite order explicit, but become brittle when local context changes. Autonomous trace-based agents are flexible, but their execution state remains implicit in long and noisy histories. The missing abstraction is not a longer prompt or a larger tool catalog, but an explicit execution-time layer for process state.

StrategyMap represents reviewed process knowledge as milestones and dependencies, then instantiates it as a Working Map during execution. The Working Map exposes completed, admissible, and blocked states, so the agent can choose the next valid objective from checked process progress. In this sense, StrategyMap is not just workflow text in a prompt; it turns workflow knowledge into runtime state.

이 프로젝트에서 가장 크게 배운 점은 업무 절차 지식을 긴 프롬프트로 넣는 것만으로는 부족하다는 점이다. 복잡한 도구 사용 업무에서는 Strategy Map처럼 현재 무엇이 완료되었고, 무엇이 다음으로 가능하며, 무엇이 아직 막혀 있는지를 실행 중에 관리하는 방식이 더 중요했다.

좋은 안내가 항상 더 짧은 실행을 뜻하지도 않았다. S&OP에서는 StrategyMap을 쓸 때 더 많은 대화 턴과 비용이 들 수 있었다. 중요한 것은 단계 수를 줄이는 것이 아니라, 유효한 단계를 밟는 것이었다. 즉, 절차를 빨리 끝내는 것보다 필요한 확인을 빠뜨리지 않고 진행하는 것이 더 중요했다.

결과를 설명하려면 정확도만으로는 부족했다. 경로 일치도(path conformity), 마일스톤 정렬도(milestone alignment), 필요한 도구 사용 범위(tool coverage) 같은 절차 지표가 있어야 에이전트가 왜 좋아졌는지 볼 수 있었다. 단순히 마지막 답변이 달라진 것이 아니라, 더 의존성에 맞는 경로를 따라갔는지를 확인하는 과정이 필요했다.

또한 단순히 절차를 보여주는 것과 Strategy Map으로 실행 중 상태를 관리하는 것은 달랐다. 순서가 있는 체크리스트나 고정 지도는 업무 흐름을 알려주지만, 현재 세션에서 어떤 선행 조건이 실제로 충족되었는지는 관리하지 못한다. Working Map이 더 좋은 결과를 낸 이유는 이 차이에 있었다.

한계도 분명하다. StrategyMap은 비용을 줄이는 방법이 아니라, 추가 토큰, 실행 시간, 단계를 더 나은 업무 품질과 절차 품질로 바꾸는 방식에 가깝다. 또 지도가 잘못 작성되었거나 오래되면 잘못된 행동을 그럴듯하게 만들 수 있다. 실제 적용을 위해서는 작성, 검토, 배포, 실행 기록 기반 유지보수를 갖춘 관리 가능한 업무 산출물로 다뤄야 하고, 외부에서 만든 업무 흐름과 실제 운영 로그에서도 검증해야 한다.

The main lesson is that workflow knowledge is not enough as long prompt text. In complex tool-use tasks, Strategy Map was useful because it managed what had been completed, what was currently admissible, and what remained blocked during execution.

Good guidance also does not always mean shorter execution. In S&OP, StrategyMap could require more turns and higher cost. The important target was not fewer steps, but valid steps: the agent should avoid skipping prerequisite checks even when that makes execution longer.

Accuracy alone was not enough to explain the result. Process metrics such as path conformity, milestone alignment, and tool coverage were necessary to see why the agent improved. They helped distinguish better procedural execution from merely different final-answer wording.

It also mattered that static context was not the same as Strategy Map guidance. Ordered checklists and static maps can describe the workflow, but they do not track which prerequisites have actually been satisfied in the current session. The full Working Map was stronger because it maintained this state during execution.

The limitations are equally important. StrategyMap does not reduce cost by default; it converts additional tokens, runtime, and steps into better task and process quality. A stale or misspecified map can also make an invalid action look justified. For deployment, maps should be treated as governed process artifacts with authoring, review, publishing, and trace-based maintenance, and they still need validation on externally authored workflows and real operational logs.