AI 에이전트 88%가 프로덕션에 실패하는 이유: 5계층 하네스 아키텍처가 그 답이다
GPT-4가 처음 나왔을 때, 저도 그랬고 주변 개발자들도 다들 비슷한 착각을 했습니다. "모델만 좋으면 되는 거 아닌가?" 프롬프트 몇 줄 붙여서 프로토타입 만들고, 그럴싸하게 돌아가는 것 같으니 프로덕션 배포. 그리고 얼마 지나지 않아 에이전트가 엉뚱한 파일을 삭제하거나, 컨텍스트를 잃고 무한루프를 돌거나, 토큰을 무지막지하게 태우는 상황을 맞닥뜨리게 됩니다.
여러 하네스 엔지니어링 관련 자료들이 공통적으로 인용하는 수치가 있습니다. AI 에이전트 프로젝트의 88%가 프로덕션에 도달하지 못한다는 것입니다 (Faros.ai, Milvus Blog). 모델이 나빠서가 아닙니다. 모델을 둘러싼 주변 시스템이 없어서입니다. 프롬프트를 잘 쓰는 것에서 시작해, 컨텍스트를 잘 조립하는 것을 거쳐, 이제는 에이전트가 동작하는 환경 전체를 설계하는 단계로 넘어왔습니다. 이 세 번째 단계가 **하네스 엔지니어링(Harness Engineering)**입니다.
이 글에서는 프로덕션 등급 AI 에이전트를 만들기 위한 5계층 하네스 아키텍처의 각 계층이 무엇이고, 없으면 어떤 일이 생기고, 어떻게 구현하는지 코드와 함께 살펴봅니다. 읽고 나면 각 계층에 바로 적용해볼 수 있는 코드 패턴을 가져갈 수 있습니다. Python 중급 이상을 기준으로 설명합니다.
핵심 개념
하네스(Harness)가 왜 필요한가
자동차에 비유하면 모델은 엔진입니다. 하네스는 그 엔진이 실제로 도로를 달리게 만드는 모든 것, 변속기, 브레이크, 계기판, 안전벨트까지입니다.
하네스(Harness): 언어 모델 주변에서 컨텍스트 조립, 도구 접근, 메모리 지속성, 제어 루프 실행, 품질 게이트 적용을 담당하는 운영 계층. 모델을 텍스트 생성기에서 자율 실행 행위자로 전환시키는 인프라입니다.
GPT-4급 모델이 여러 회사에서 쏟아지는 지금, 제품의 실질적인 차별화는 모델을 얼마나 잘 감싸느냐로 넘어왔습니다. 그리고 이 감싸는 작업 전체를 체계적으로 다루는 분야가 하네스 엔지니어링입니다.
5계층 아키텍처 전체 구조
프로덕션 등급 하네스는 다음 5개 계층으로 구성됩니다. 각 계층은 독립적으로 설계하고 테스트할 수 있어야 합니다.
| 계층 | 이름 | 한 줄 역할 | 없으면? |
|---|---|---|---|
| 1 | Tool Orchestration | 에이전트가 외부 세계에 손을 뻗는 방법 | 텍스트 생성기에서 멈춤 |
| 2 | Verification Loops | "했다"와 "제대로 했다" 사이의 검증 관문 | 완료 선언했지만 실제론 실패 |
| 3 | Context & Memory | 대화와 작업 사이의 기억과 상태 관리 | 긴 작업에서 목표를 잃어버림 |
| 4 | Guardrails | 절대 넘어선 안 되는 선을 강제하는 정책 | 에이전트가 파일을 지워버림 |
| 5 | Observability | 무슨 일이 일어났는지 사후에 파악할 수 있는 눈 | 실패해도 원인을 모름 |
계층 1 — Tool Orchestration (도구 오케스트레이션)
에이전트가 파일 시스템, 셸 명령어, 내부 API, 외부 서비스에 접근할 수 있도록 연결하는 중추입니다. 이게 없으면 에이전트는 텍스트만 생성하는 도구에 머뭅니다.
2024년 말 Anthropic이 공개한 MCP(Model Context Protocol)가 이 계층의 표준화를 크게 앞당겼습니다. 도구와 모델 사이의 통신 방식을 표준화해서, 한 번 구현한 도구가 호환 클라이언트 전체에서 동작합니다. 쉽게 말해 도구를 플러그인처럼 끼우고 빼는 공통 인터페이스가 생긴 것입니다.
# MCP 기반 도구 등록 예시 (Claude Agent SDK)
from anthropic import Anthropic
client = Anthropic()
tools = [
{
"name": "read_file",
"description": "파일 내용을 읽어 반환합니다",
"input_schema": {
"type": "object",
"properties": {
"path": {
"type": "string",
"description": "읽을 파일의 절대 경로"
}
},
"required": ["path"]
}
},
{
"name": "run_tests",
"description": "지정된 테스트 스위트를 실행하고 결과를 반환합니다",
"input_schema": {
"type": "object",
"properties": {
"test_path": {
"type": "string",
"description": "테스트 파일 또는 디렉토리 경로"
}
},
"required": ["test_path"]
}
}
]
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=4096,
tools=tools,
messages=[{"role": "user", "content": "src/auth.py를 읽고 테스트를 실행해줘"}]
)계층 2 — Verification Loops (검증 루프)
솔직히 이게 가장 중요하면서도 가장 많이 빠뜨리는 계층입니다. 에이전트가 "작업 완료"를 선언한다고 해서 실제로 완료된 게 아닐 수 있거든요.
에이전트가 결과를 실제로 검증하지 않고 완료를 선언하는 경향을 현장에서 "승리 선언 편향(Victory Declaration Bias)" 이라 부릅니다. 제가 처음 에이전트를 배포했을 때 가장 많이 당한 게 이거였습니다. 에이전트가 실패한 작업을 "성공했다"고 보고하고 다음 단계를 진행하는 상황이 생기거든요. PEV(Plan-Execute-Verify) 패턴이 이를 해결하는 핵심 구조입니다.
# PEV 패턴 구현 예시
async def pev_loop(task: str, max_retries: int = 3) -> dict:
plan = await agent.plan(task) # 1. 계획 수립
for attempt in range(max_retries):
result = await agent.execute(plan) # 2. 실행
# 검증은 에이전트 자신이 아닌 독립 함수에게 맡깁니다
verification = await verifier.check(
task=task,
plan=plan,
result=result
) # 3. 검증
if verification.passed:
return {"status": "success", "result": result}
# 검증 실패 시 피드백을 반영해 계획을 수정하고 재시도
plan = await agent.replan(
original_task=task,
failed_result=result,
feedback=verification.feedback
)
return {"status": "failed", "last_result": result}위상 게이트(Phase Gate): 이전 단계의 검증을 통과하지 못하면 다음 단계로 진행할 수 없도록 강제하는 아키텍처 패턴. 에이전트가 중간 결과를 건너뛰고 최종 출력만 생성하는 것을 방지합니다.
계층 3 — Context & Memory (컨텍스트 & 메모리)
LLM의 컨텍스트 윈도우는 유한합니다. 긴 작업이나 멀티세션 에이전트에서는 이전 작업 내용, 결정 히스토리, 현재 목표 상태를 어딘가에 지속적으로 관리해야 합니다.
실제로 이 구분을 처음 적용했을 때 "중기 메모리를 어떻게 정의할지"가 가장 헷갈렸습니다. 실무에서 쓰는 기준을 공유하자면,
- 단기 메모리: 현재 세션 내 대화 히스토리. 컨텍스트 윈도우 안에 직접 유지합니다.
- 중기 메모리: 현재 작업의 중간 결과, 실행한 도구 목록, 부분 성과물. 작업이 끝나면 버리거나 장기로 승격합니다.
- 장기 메모리: 사용자 선호도, 프로젝트 컨벤션, 반복 등장하는 도메인 지식. 세션이 바뀌어도 유지합니다.
# 계층적 메모리 관리 예시
# mem0: 에이전트에 장기 기억을 제공하는 Python 라이브러리 (pip install mem0ai)
from mem0 import Memory
memory = Memory()
class StatefulAgent:
def __init__(self, user_id: str):
self.user_id = user_id
self.session_history = [] # 단기: 세션 내에서만 유지
async def process(self, message: str) -> str:
# 장기 기억에서 현재 메시지와 관련된 맥락 검색
long_term = memory.search(
query=message,
user_id=self.user_id,
limit=5
)
# 단기 + 장기 기억을 합성해 시스템 프롬프트 구성
context = self._build_context(
session=self.session_history,
long_term=long_term
)
response = await llm.complete(system=context, user=message)
# 단기 기억 업데이트
self.session_history.append({"role": "user", "content": message})
self.session_history.append({"role": "assistant", "content": response})
# 중요한 정보(프로젝트 컨벤션, 사용자 선호 등)를 장기 기억에 저장
memory.add(
messages=[
{"role": "user", "content": message},
{"role": "assistant", "content": response}
],
user_id=self.user_id
)
return response
def _build_context(self, session: list, long_term: list) -> str:
# 장기 기억을 시스템 프롬프트 앞부분에 삽입
memory_context = "\n".join(f"- {m['memory']}" for m in long_term)
return f"과거 기억:\n{memory_context}\n\n"계층 4 — Guardrails (가드레일)
AI가 생성한 코드가 보안 취약점을 도입하는 사례가 꾸준히 보고되고 있습니다 (arXiv 2511.07669). 에이전트가 파일을 삭제하거나, 외부로 데이터를 전송하거나, 설정을 바꾸는 행동은 되돌리기 어렵습니다. 가드레일은 이런 고위험 행동에 강제 검문소를 두는 계층입니다.
# 고위험 행동 가드레일 구현
from enum import Enum
from typing import Callable
class RiskLevel(Enum):
LOW = "low"
MEDIUM = "medium"
HIGH = "high"
CRITICAL = "critical"
# 도구를 등록하는 시점에 위험도와 정책을 함께 정의하는 것이 좋습니다
ACTION_POLICIES = {
"read_file": RiskLevel.LOW,
"write_file": RiskLevel.MEDIUM,
"delete_file": RiskLevel.CRITICAL,
"send_http_request": RiskLevel.HIGH,
"run_shell_command": RiskLevel.HIGH,
}
async def guarded_execute(
action: str,
params: dict,
human_approval_fn: Callable
) -> dict:
risk = ACTION_POLICIES.get(action, RiskLevel.HIGH)
if risk == RiskLevel.CRITICAL:
# CRITICAL 행동은 사람의 명시적 승인이 필요합니다
approved = await human_approval_fn(
action=action,
params=params,
reason=f"위험도 CRITICAL: {action} 실행 승인이 필요합니다"
)
if not approved:
return {"status": "rejected", "reason": "사용자 미승인"}
elif risk == RiskLevel.HIGH:
# HIGH는 정책 검사 후 자동 승인 가능
if not policy_check(action, params): # 정책 검사 헬퍼
return {"status": "blocked", "reason": "정책 위반"}
return await execute_action(action, params) # 실제 도구 실행헬스케어 영역에서는 한 걸음 더 나아갑니다. 모델이 약물 케어 플랜을 출력하면, 가드레일 계층이 결정론적 의료 사전 도구로 약물 상호작용을 즉시 교차 검증합니다. 모델의 판단을 믿는 게 아니라, 검증 가능한 외부 소스와 대조하는 방식입니다.
계층 5 — Observability (관측 가능성)
에이전트가 프로덕션에서 실패했을 때, "왜 실패했나"를 파악하려면 로그만으론 부족합니다. 어떤 계층에서 무슨 도구를 호출했고, 토큰을 얼마나 썼고, 어디서 루프가 깨졌는지 추적할 수 있어야 합니다.
트레이싱을 나중에 붙이려다가 호되게 고생한 적이 있습니다. 아키텍처가 얽히고 나면 어디에 무엇을 달아야 할지 파악하는 것 자체가 일이 됩니다. 첫 에이전트부터 넣어두는 게 훨씬 낫습니다.
# LangSmith를 이용한 에이전트 트레이싱
# LangSmith: 에이전트 실행 흐름, 토큰 사용량, 실패 지점을 추적하는 관측 도구
# pip install langsmith
from langsmith import traceable
@traceable(name="agent-main-loop", tags=["production"])
async def agent_loop(task: str) -> str:
"""@traceable이 함수 실행 전체를 자동으로 트레이스합니다."""
plan = await create_plan(task)
results = []
for step in plan.steps:
result = await execute_step(step)
results.append(result)
return synthesize_results(results)
# 개별 단계에도 적용하면 단계별 소요 토큰과 시간이 모두 기록됩니다
@traceable(name="execute-step")
async def execute_step(step) -> dict:
result = await run_tool(step.tool, step.params) # 실제 도구 호출
return {"step_type": step.type, "result": result}엔터프라이즈 데이터 파이프라인 사례에서 컨텍스트 드리프트·스키마 불일치·상태 저하로 인한 AI 장애의 65%가 하네스 레이어에서 차단됐다고 합니다 (Milvus Blog). 그 차단이 가능하려면 관측 가능성이 먼저 있어야 합니다.
실전 적용
예시 1: Anthropic 3-에이전트 코딩 하네스
Anthropic 내부에서 실제로 사용하는 구조로 알려진 3-에이전트 패턴입니다. 짧은 브리프 하나가 전체 제품 스펙으로 변환되고, 코드가 구현되고, 검증까지 자동으로 이어집니다.
import asyncio
from anthropic import Anthropic
client = Anthropic()
async def planner_agent(brief: str) -> dict:
"""짧은 브리프 → 완전한 제품 스펙 (JSON 반환)"""
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=8192,
system="""당신은 제품 아키텍트입니다.
입력된 간단한 요구사항을 기술 스펙으로 확장하세요.
반드시 JSON 형식으로 반환하세요:
{"features": [...], "api_contracts": {...}, "test_criteria": [...]}""",
messages=[{"role": "user", "content": brief}]
)
return parse_spec(response.content[0].text) # JSON 파싱 헬퍼
async def generator_agent(spec: dict, sprint_idx: int) -> dict:
"""스펙 → 스프린트 단위 코드 구현"""
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=8192,
system="당신은 시니어 엔지니어입니다. 명세에 따라 코드를 구현하세요.",
messages=[{
"role": "user",
"content": f"Sprint {sprint_idx} 구현:\n{spec['features'][sprint_idx]}"
}]
)
return {"code": response.content[0].text, "sprint": sprint_idx}
async def evaluator_agent(code: dict, test_criteria: list) -> dict:
"""테스트 실행 후 결과를 분석해 통과/실패 판정"""
# run_tests: pytest / Playwright 등 실제 테스트 도구를 호출하는 헬퍼
test_results = await run_tests(code["code"], test_criteria)
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=2048,
system="테스트 결과를 분석하고 통과/실패 판정과 구체적인 피드백을 제공하세요.",
messages=[{"role": "user", "content": f"테스트 결과:\n{test_results}"}]
)
return {
"passed": "PASS" in response.content[0].text,
"feedback": response.content[0].text
}
async def three_agent_harness(brief: str) -> str:
spec = await planner_agent(brief) # 계획 수립
final_code = []
for sprint_idx in range(len(spec["features"])):
retries = 0
while retries < 3:
code = await generator_agent(spec, sprint_idx) # 구현
evaluation = await evaluator_agent( # 계층 2: 검증 루프
code, spec["test_criteria"]
)
if evaluation["passed"]:
final_code.append(code)
break
# 피드백을 스펙에 반영해 다음 시도에 활용
spec["features"][sprint_idx] += f"\n피드백: {evaluation['feedback']}"
retries += 1
return assemble_final_code(final_code) # 스프린트별 코드를 최종 결과물로 조합| 구성 요소 | 주로 담당하는 하네스 계층 | 역할 |
|---|---|---|
planner_agent |
1 (Tool Orchestration) | 요구사항 → 실행 가능한 스펙 변환 |
generator_agent |
1, 3 (Tool + Memory) | 스프린트 구현, 이전 피드백 컨텍스트 유지 |
evaluator_agent |
2 (Verification Loop) | 독립적인 검증 — 자기 출력을 스스로 검증하지 않음 |
while retries < 3 |
2 (Verification Loop) | 검증 실패 시 피드백 반영 자동 재시도 |
예시 2: 엔터프라이즈 코딩 에이전트 — 5계층 통합 구성
PR을 만들고 리뷰하는 AI 에이전트에 5계층을 모두 적용하는 TypeScript 구성입니다. 실무에서 자주 맞닥뜨리는 시나리오입니다.
// TypeScript로 5계층 통합 하네스 구성
import Anthropic from "@anthropic-ai/sdk";
import { Client as LangSmithClient } from "langsmith";
import { traceable } from "langsmith/traceable"; // 계층 5: Observability
import { Memory } from "mem0ai"; // 계층 3: Context & Memory
const client = new Anthropic();
const langsmith = new LangSmithClient();
const memory = new Memory();
// 계층 4: Guardrails — 차단할 고위험 작업 목록
const BLOCKED_OPERATIONS = ["force_push", "delete_branch_main", "drop_table"];
// traceable()로 감싸면 모든 실행이 LangSmith에 자동 기록됩니다
const codingAgentHarness = traceable(
async (task: string, repoContext: string) => {
// 계층 3: 프로젝트 장기 메모리 로드
const projectMemory = await memory.search({ query: task, limit: 10 });
// 계층 4: 작업 사전 위험도 검사
const isBlocked = BLOCKED_OPERATIONS.some(op => task.includes(op));
if (isBlocked) {
return { status: "blocked", reason: "정책 위반 작업 감지" };
}
// 계층 1: 도구 정의 (Tool Orchestration)
const tools: Anthropic.Tool[] = [
{
name: "read_file",
description: "파일 내용을 읽어 반환합니다",
input_schema: {
type: "object" as const,
properties: {
path: { type: "string", description: "읽을 파일 경로" }
},
required: ["path"]
}
},
{
name: "write_file",
description: "파일에 내용을 씁니다",
input_schema: {
type: "object" as const,
properties: {
path: { type: "string", description: "쓸 파일 경로" },
content: { type: "string", description: "파일에 쓸 내용" }
},
required: ["path", "content"]
}
},
{
name: "run_tests",
description: "테스트 스위트를 실행하고 결과를 반환합니다",
input_schema: {
type: "object" as const,
properties: {
test_path: { type: "string", description: "테스트 디렉토리 경로" }
},
required: ["test_path"]
}
}
];
let passed = false;
let attempts = 0;
// 계층 2: PEV 검증 루프
while (!passed && attempts < 3) {
await client.messages.create({
model: "claude-opus-4-7",
max_tokens: 8192,
tools,
system: buildSystemPrompt(projectMemory, repoContext), // 메모리 주입
messages: [{ role: "user", content: task }]
});
// 에이전트 자신이 아닌 독립 함수로 검증합니다
const testResult = await runTestSuite();
passed = testResult.passed;
attempts++;
}
// 계층 3: 작업 결과를 장기 메모리에 저장
await memory.add({ task, result: "completed", attempts });
return { status: passed ? "success" : "failed", attempts };
},
{ name: "coding-agent", tags: ["production"] }
);장단점 분석
가장 뼈아프게 느낀 건 토큰 폭발이었습니다. 처음에 검증 루프를 신나게 넣었다가, 단순한 코드 수정 작업 하나가 원래의 4배 토큰을 쓰는 걸 보고 식겁했습니다. 낮은 위험도 작업은 검증 루프를 경량화하는 것이 현실적입니다.
장점
| 항목 | 내용 |
|---|---|
| 신뢰성 확보 | AI 에이전트 프로젝트 88%가 프로덕션 미달인 현실에서, 5계층 하네스가 그 격차를 줄이는 가장 검증된 수단 |
| 모델 독립성 | 하네스가 일관된 인터페이스를 제공하므로, GPT-4에서 Claude로 교체해도 에이전트 로직 변경 최소화 |
| 정책 집중 | 보안·컴플라이언스·비용 제어를 하네스 단일 계층에 집중해 감사·관리 용이 |
| 계층별 디버깅 | 장애 원인을 특정 계층에서 추적 가능해 디버깅 비용 절감 |
| 자동 진화 가능성 | 관측 데이터를 피드백 삼아 하네스 자체를 자동 개선하는 방향(Agentic Harness Engineering)으로 발전 중 (arXiv 2604.25850) |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 성능 오버헤드 | 검증·재시도 정책이 런타임과 토큰 소비를 최대 2배 증가 | 위험도 낮은 작업은 검증 루프를 경량화하거나 생략 |
| 토큰 폭발 | 자율 루프 전환 시 토큰 사용량이 한 자릿수 배 이상 증가 가능 | 컨텍스트 압축, 요약 전략, 비용 예산 한도 설정 |
| 복잡도 | 5계층 전체를 올바르게 설계하고 테스트하는 데 상당한 엔지니어링 투자 필요 | 단계적 도입. 5→4→2 순서가 실무에서 효과적 |
| 데이터 품질 한계 | 에이전트 실패의 27%는 데이터 품질 문제 — 하네스만으론 해결 불가 (Milvus Blog) | 데이터 파이프라인 품질 관리를 병행 |
| 승리 선언 편향 | 에이전트가 검증 없이 작업 완료를 선언하는 경향 | 검증을 독립된 에이전트 또는 결정론적 함수로 분리 |
컨텍스트 드리프트(Context Drift): 긴 에이전트 실행 과정에서 초기 목표나 상태가 서서히 변질되는 현상. 메모리 계층이 없을 때 특히 심각하게 나타납니다.
실무에서 가장 흔한 실수
-
검증을 에이전트 자신에게 맡기는 것 — 에이전트가 자기 출력을 검증하면 편향이 생깁니다. 자기 버그를 스스로 통과시키는 장면을 실제로 목격하고 나서야 이 원칙이 얼마나 중요한지 실감했습니다. 검증은 별도 에이전트나 결정론적 함수(테스트 실행, 스키마 검증 등)로 분리하는 것이 좋습니다.
-
가드레일 없이 고위험 도구를 등록하는 것 — "일단 다 붙이고 나중에 제한하자"는 접근은 프로덕션에서 위험합니다. 도구를 등록하는 시점에 위험도와 정책을 함께 정의하는 것이 장기적으로 훨씬 안전합니다.
-
관측 가능성을 마지막에 추가하는 것 — 트레이싱과 비용 추적은 나중에 붙이기가 매우 어렵습니다. 아키텍처가 얽히고 나면 어디에
@traceable을 달아야 할지 파악하는 것 자체가 일이 됩니다. 첫 번째 에이전트를 만들 때부터 계층 5를 넣어두는 것이 결국 빠릅니다.
마치며
하네스 엔지니어링은 AI 에이전트를 '될 것 같은 데모'에서 '실제로 동작하는 제품'으로 끌어올리는 인프라입니다. 이 글을 읽고 나서 에이전트를 다시 볼 때 "이 에이전트에 지금 몇 계층이 있지?"라는 질문이 자연스럽게 떠오른다면 그걸로 충분합니다. 5계층 모두를 한 번에 완벽하게 구현할 필요는 없습니다. 지금 당장 시작할 수 있는 것부터 하나씩 쌓아가는 것으로도 충분히 큰 차이를 만들 수 있습니다.
지금 바로 시작할 수 있는 3단계:
-
관측 가능성부터 켜기 — LangSmith나 Langfuse를 기존 에이전트에 붙이는 건 코드 몇 줄로도 가능합니다.
pip install langsmith후 에이전트 진입점에@traceable을 붙이는 것만으로도 토큰 사용량과 실패 지점을 시각화할 수 있습니다. 조용히 실패하던 중간 결과들이 눈에 보이기 시작할 것입니다. -
가장 위험한 도구 하나에 가드레일 추가하기 — 파일 삭제, 외부 API 호출 등 되돌리기 어려운 도구 하나를 골라 위험도 등급을 매기고 승인 게이트를 추가하면 사고 예방 효과를 즉시 체감할 수 있습니다.
-
PEV 루프 한 곳에 적용하기 — 에이전트 실행 후 결과를 독립적인 함수(테스트 실행, 스키마 검증 등)로 검증하는 코드를 추가하면, 완료 선언이 실제 완료와 얼마나 다른지 바로 확인할 수 있습니다.
참고 자료
- What Is Harness Engineering for AI Agents? | Milvus Blog
- Harness Engineering: Making AI Coding Agents Work in 2026 | Faros.ai
- What Is Harness Engineering AI? The Definitive 2026 Guide | Atlan
- AI Harness Engineering: The Layer That Makes Your LLM Applications Actually Work | Pinggy
- Harness Engineering for AI Coding Agents | Augment Code
- Agentic Harness Engineering: Observability-Driven Automatic Evolution | arXiv 2604.25850
- Making LLMs Reliable: A Five-Layer Architecture for High-Stakes Decisions | arXiv 2511.07669
- Agent Harness Engineering: The Rise of the AI Control Plane | Medium
- GitHub: awesome-harness-engineering | ai-boost