무엇이 하네스이고 무엇이 아닌지 가르는 기준은 3가지다. 첫째, AI 모델과 외부 행동 사이를 중개하는가. 파일 수정, 데이터베이스 조회, 결제 같은 실제 행동은 AI 모델의 문장이 아니라 하네스의 실행을 거쳐 일어나야 한다. 둘째, 실행 과정에 기계적 통제를 거는가. 금지 행동은 프롬프트의 문장이 아니라 도구 정의, 권한, 실행 전 검증에서 차단되어야 한다. 셋째, 실행 경로와 결과를 기록해 재현하고 검증할 수 있는가. 이 세 조건을 모두 충족할 때 비로소 하네스라 부른다. 이 기준으로 보면 하네스가 아닌 것들이 분명해진다. 정교하게 다듬은 프롬프트 템플릿 하나는 하네스가 아니다. 지시는 있지만 통제가 없다. 프롬프트는 말로 지시하고 하네스는 구조로 강제한다. AI 모델 API를 얇게 감싼 래퍼(wrapper)도 하네스가 아니다. 중개는 하지만 통제도 기록도 없다. 로그를 보여 주기만 하는 대시보드도 하네스가 아니다. 기록은 있지만 실행에 개입하지 못한다.
--- 「01 하네스」 중에서

맥락 엔지니어링(context engineering)은 AI 모델이 답을 만들 때 참조하는 정보의 집합, 곧 컨텍스트를 설계하는 일이다. 컨텍스트에는 시스템 지시, 사용자 요청, 검색된 문서, 이전 대화, 도구 실행 결과처럼 추론 시점에 AI 모델의 입력창에 올라가는 모든 것이 포함된다. 앤스로픽은 컨텍스트를 유한한 자원으로 보고, 그 안에 담기는 토큰의 유용성을 최적화하는 전략의 묶음을 맥락 엔지니어링이라고 정의했다. 이 정의의 핵심은 채우기가 아니라 고르기에 있다. 맥락 엔지니어링은 입력창을 채우는 일이 아니라, 지금 작업에 필요한 사실과 규칙과 상태를 선택하고 압축하며 그 출처와 최신성을 관리하는 일이다.
--- 「03 맥락 구성」 중에서

오케스트레이션의 실체는 흐름을 적어 둔 곳에 있다. 단일 에이전트라면 단계의 순서와 재시도 상한을 정한 설정이, 여러 에이전트라면 각자의 역할 지시문과 워크플로 정의가 그것이다. 적용의 핵심은 핸드오프 지점마다 무엇을 넘기는지의 형식을 문서나 스키마로 고정하고, 모든 루프에 종료 조건과 사람 이관 규칙을 값으로 적는 일이다. 조직으로 치면 업무 분장표와 인수인계 양식을 만드는 일과 같아서, 흐름도를 그릴 수 있는 사람이면 누구나 이 설계에 참여할 수 있다.
--- 「06 오케스트레이션」 중에서

언어 모델은 버전과 내부 설정이 바뀔 수 있어 완전한 재현은 어려울 수 있지만, 재구성만큼은 기록 설계로 보장할 수 있다. 기록이 없으면 그 재구성부터 막힌다. 실패가 명세, 맥락, 도구, 권한, AI 모델 중 어디에서 났는지 가려내는 실패 귀인(failure attribution, 어떤 결과가 실패로 끝날 경우 그 원인을 분석하는 과정)도 막힌다. 모든 실패가 “AI 모델이 틀렸다”로 뭉뚱그려지고 고칠 대상을 찾지 못해 같은 오류가 반복된다. 조직적으로는 책임 공방이 벌어진다. 개발팀은 도구를, 도구팀은 AI 모델을, 현업은 시스템 전체를 탓하지만 누구도 근거를 제시하지 못한다. 마지막은 책임의 문제다. 감사자와 규제 기관 앞에서 누가 어떤 권한으로 왜 그 행동을 승인했는지 증명하지 못하면 조직은 결과에 대한 책임을 감당할 수 없고 도입 자체가 중단되기도 한다. 관찰 가능성이 운영 편의가 아니라 핵심 설계 요소인 이유가 여기에 있다.