문제점: 현재의 LLM 에이전트 프레임워크는 채팅 기록(chat history)을 상태(state)를 위한 단일 진실 공급원(single source of truth)으로 취급합니다. 이는 아키텍처적으로 커널이 오직 stdin/stdout 로그를 통해서만 상태를 유지하는 것과 동일합니다. 이는 일시적으로는 작동하지만, 부하가 걸리면 예측 가능한 방식으로 실패합니다.

세 가지 측정 가능한 실패 모드:

1. 감지되지 않는 실행 루프 (Undetected execution loops) — 워치독(watchdog)이 없음. 확인 메시지가 컨텍스트(context)에서 벗어났기 때문에 에이전트가 write_file('config.json', data)를 다시 실행합니다. max_iterations에 도달할 때까지 토큰이 소모됩니다.
2. 조용한 상태 오염 (Silent state corruption) — LLM이 도구 호출(tool call)을 위해 잘못된 JSON을 생성합니다. 일부 프레임워크는 이를 삼키고 null로 진행합니다. 다른 것들은 중단합니다. 어느 것도 파일 시스템을 롤백(roll back)하지 않습니다. 절반만 작성된 파일이 그대로 남습니다.
3. 이차적 토큰 비용 (Quadratic token cost) — 반복될 때마다 컨텍스트가 성장합니다 (O(n²) 어텐션 (attention)). 예산 책정(budgeting)도 없고, 절단(truncation) 전의 신호도 없습니다.

이것들은 버그가 아닙니다. 확률적 시스템(LLM)을 범용 결정론적 기계(deterministic machine)로 취급함으로써 발생하는 아키텍처적 결과입니다. 도구 호출 환각(tool-call hallucination) 비율이 2-5%로 기록됨에 따라 (ToolAlpaca, API-Bank), 모델이 스스로 상태를 관리하도록 의존하는 것은 약 50회의 도구 호출 이후에는 유지 불가능합니다.

AEP 접근 방식: 컨텍스트 내의 상태(state-in-context) 대신, 우리는 8개의 레지스터 주소 공간(R0-R7)을 가진 마이크로커널 런타임(microkernel runtime)에 의해 운영되는 **결정론적 샌드박스 (deterministic sandbox)**를 정의합니다:

레지스터 (Register)	기능 (Function)
R0	프로그램 카운터 (Program counter)
...

이 레지스터들은 LLM 컨텍스트에 존재하지 않습니다. 이들은 런타임(Python, Rust, Go 등 무엇이든)에 존재합니다. LLM은 마이크로커널에 의해 라우팅되는 도구 호출을 통해서만 이들과 상호작용하며, 채팅 메시지를 통해서는 절대 상호작용하지 않습니다. 이는 컨텍스트(압축 가능)를 운영 상태(정확함)로부터 분리합니다.

회복 탄력성 메커니즘 (AEP-0008):

워치독 (Watchdog, R1): 모든 도구 실행 후, 런타임은 샌드박스를 해싱(hashing)합니다. 만약 hash == previous_hash라면, 루프 카운터를 증가시킵니다. 카운터가 임계값(threshold, 기본값 3) 이상이 되면, 해당 작업은 WATCHDOG_LOOP와 함께 배출(ejected)됩니다. 이는 단순히 호출 횟수뿐만 아니라, 상태 진전 없이 반복되는 사이클을 포착합니다.

ACID 트랜잭션 (R4, R6): 모든 변이(mutation)는 스키마 검증(schema validation)을 통과해야 합니다. 위반 시:

1. WAL(Write-Ahead Logging) 재생을 통한 롤백 (R6가 이전 샌드박스(sandbox)를 복구)
2. R4에 구조화된 에러 주입: {code, expected schema, received payload, recovery hint}
3. 런타임(runtime)이 R4를 도구 결과(tool result)로 반환 — 모델이 이를 파싱하고 스스로 수정(self-corrects)
4. 동일한 도구에서 3회 연속 롤백 발생 → 워치독(watchdog) 중단

최종 효과: 유효하지 않은 JSON은 파일 시스템에 절대 닿지 않습니다. 손상된 상태는 외부 프로세스가 읽기 전에 복구됩니다.

벤치마크 — 통제된 방법론 (Controlled methodology):

파이프라인: 에이전트가 자연어 지침으로부터 20개의 CSV 스프레드시트(다양한 스키마, 혼합된 인코딩, 최대 15개 열)를 변환합니다. 베이스라인(Baseline): AEP 런타임 없이 동일한 에이전트 + 동일한 모델 (Claude 3.5 Sonnet, max_iterations=90). 각 실험군당 n=50, 셔플링(shuffled) 적용, temp=0.

지표 (Metric)	베이스라인 (Baseline)	AEP 런타임 (AEP Runtime)	차이 (Delta)
소비된 토큰 (평균)	312,450	62,890	-79.9%
...

방법론 참고 사항 (인용 전 필독):

• 토큰에 대한 95% 신뢰 구간 (CI): 베이스라인 ±4.2%, AEP ±3.1%
• 스프레드시트 파이프라인만 테스트됨 — 코드 생성(code gen), 웹 스크래핑(web scraping) 또는 순수 CoT(Chain of Thought) 데이터는 아직 포함되지 않음
• 스키마 정확도(Schema accuracy)는 페이로드 전달 검증(payload-passing validation)을 측정하며, 의미론적 출력 정확도(semantic output correctness)를 측정하는 것이 아님
• 전체 피스처 세트(fixture set) + 실행 스크립트는 benchmark/fixtures/ 및 benchmark/run_benchmark.sh에 있음

80%의 토큰 감소는 다음과 같이 세분화됩니다: 컨텍스트 압축(context compression, WAL 확인 후 도구 메시지 제거)에서 55%, 루프 제거(loop elimination)에서 20%, 빠른 롤백(fast rollback, 5-8회 반복 대비 1-2회 반복)에서 5%.

현재 제공되는 것:

저장소(Repo): https://github.com/ferreiratechnology2025-max/CogniX

핵심 사양(core spec, AEP-0001부터 AEP-0012까지)은 v1.1.0에서 동결되었습니다. 컴플라이언스 키트 (Compliance Kit) (compliance/)에는 11개의 YAML 테스트가 포함되어 있습니다:

1. 상태 변화(state delta) 없이 N 사이클 동안 워치독(Watchdog) 배출
2. 유효하지 않은 스키마(schema) 발생 후 롤백(Rollback)을 통한 샌드박스(sandbox) 복구
3. R4가 코드를 포함한 구조화된 에러(structured error)를 캡처함
4. apply() 호출 전 WAL(Write-Ahead Logging) 영속화
5. 병렬 실행(concurrent execution) 중 태스크 격리(Task isolation)
6. 컨텍스트 예산(Context budget) 한도 도달 시 배출
7. 멱등성 도구(idempotent tools)를 위한 워치독 우회
8. 롤백(Rollback)이 관련 없는 샌드박스(sandbox) 상태에 영향을 주지 않음
9. 강제 해시 충돌(hash collision) 동작
10. WAL 락 경합(lock contention) 타임아웃
11. 독립적인 벤치마크 재현성

커뮤니티에 요청하는 사항:

• 명세(spec) 감사: (spec/ 내의 AEP-0001부터 0012까지) 만약 R6 트랜잭션 시맨틱(transaction semantics)이 귀하의 유스케이스(use case)와 일치하지 않는다면, 차이점을 설명하는 이슈(issue)를 생성해 주세요.
• 런타임(runtime) 포팅: Rust 또는 Go로 포팅해 주세요. Python 런타임은 개념 증명(POC) 단계이며, 명세(spec)는 언어에 구애받지 않습니다(language-agnostic).
• 독립적으로 벤치마크 실행: run_benchmark.sh는 일반적인 사양의 하드웨어(commodity hardware)에서 약 3분이 소요됩니다.

프로토콜은 공개되었습니다. 테스트는 준비되어 있습니다. 엔지니어링 결과가 모든 것을 말해줍니다.