Agent Foundry: 프로젝트와 AI Agent 사이의 Operating Layer

Long-running Agent에서 Context는 Prompt 몇 줄보다 Project State에 가깝다. Goal, Architecture, Existing Assets, Runtime State, Constraints, Dependencies가 계속 누적되고 갱신된다. 따라서 Context Engineering도 가능한 많은 정보를 넣는 문제가 아니라, 현재 Role과 Task가 요구하는 정보를 선택하고 최신 상태로 유지하며 불필요한 Context를 차단하는 문제에 더 가깝다.

Tool Use도 마찬가지다. Agent가 GitHub를 수정하거나 Test를 실행할 수 있다는 사실과, 현재 역할의 Agent가 그 변경을 수행해도 된다는 것은 별개의 문제다. Capability에는 Permission Boundary가 필요하고, 외부 효과가 큰 작업에는 승인 조건과 Rollback 기준이 필요하다. Multi-Agent 역시 Agent의 숫자를 늘리는 것보다 Ownership, Handoff, Review Independence를 어떻게 설계하느냐가 더 중요하다.

결국 프로젝트 안에서 필요한 것은 "더 강한 Agent" 하나가 아니라, Agent가 프로젝트의 현재 상태를 이해하고 허용된 범위 안에서 실행하며, 결과를 검증 가능한 형태로 남기는 Operating Model이라고 보고 있다.

Agent Foundry는 새로운 Agent Runtime이나 Coding Agent를 만들려는 프로젝트가 아니다. Legacy Code, Existing Docs, Workflow / SOP, 또는 새로운 Project가 주어졌을 때 이를 AI Agent가 안정적으로 다룰 수 있도록 Context, Rules, Roles, Work, Tools, Validation을 프로젝트 단위로 구성하는 Operating Layer에 가깝다.

현재 구조에서는 이를 다음과 같은 lifecycle로 보고 있다.

Existing Project / New Project
        ↓
Diagnosis
        ↓
Prescription
        ↓
Compilation
        ↓
Validation / Reconciliation
        ↓
Controlled Apply

Diagnosis는 repository, tracker, runtime, 기존 문서와 convention을 관찰해 프로젝트의 실제 상태를 재구성한다. Prescription은 그 상태에 맞는 운영 방식, 역할, 권한, Work 구조, Evidence 요구사항과 필요한 capability를 제안한다. Compilation은 이를 Agent가 실행할 수 있는 Project Toolkit, Task Toolkit, Execution Contract로 구체화한다. Controlled Apply는 검토된 변경을 실제 프로젝트에 반영하는 mutation layer이며, 넓은 범위의 자동 적용은 core가 충분히 검증된 이후의 단계로 두고 있다.

이 과정에서 중요한 중간 산출물이 Project Profile이다. 프로젝트에 대해 관찰된 사실과 선언된 규칙, 해석을 통해 추론한 내용, 앞으로 적용하려는 규범을 한 덩어리의 Prompt로 섞지 않고 구분하려는 것이다.

observed ≠ declared ≠ inferred ≠ normative

특히 inference는 통제를 강화할 수는 있어도, Agent의 authority를 조용히 확장해서는 안 된다는 원칙을 두고 있다.

상위에는 Constitution → Operating Policies → Harness & Templates라는 공통 Layer를 둔다. Constitution은 프로젝트 운영의 불변 원칙과 authority hierarchy를, Policies는 권한·변경 범위·Safety Rule·Escalation 조건을, Harness는 Role Prompt·Tool Connection·Execution / Review / Validation Pattern을 정의한다.

그 아래에서 실제 Work는 다음처럼 내려간다.

Project Context
→ Objective / Outcome
→ Work Package / Work Item
→ Owner & Authority
→ Acceptance Criteria
→ Execution
→ Review
→ Validation
→ Evidence-backed State Transition

여기서 Task는 단순한 To-do가 아니라 작은 Execution Contract에 가깝다. 무엇을 바꿀 것인지뿐 아니라 무엇을 바꾸지 않을지, 어떤 dependency와 authority boundary가 있는지, 어떤 Evidence가 있어야 완료인지까지 포함한다. Work를 파일 단위나 Agent 숫자에 맞춰 임의로 쪼개기보다, 독립적으로 검증 가능한 outcome, dependency, rollback unit, ownership surface를 기준으로 분해하려는 이유도 여기에 있다.

Multi-Agent 구조에서는 Manager, Worker, Reviewer, Scouter, Validator 같은 역할을 분리해 사용한다. Manager는 목표와 우선순위 및 work decomposition을, Worker는 bounded execution을, Scouter는 필요한 Context와 Risk 탐색을, Reviewer는 독립적인 품질 검토를, Validator는 Test·Runtime State·Artifact 같은 외부 Evidence를 기반으로 완료 조건을 검증한다.

중요한 원칙은 Role before Provider다. 먼저 어떤 책임과 capability가 필요한지를 정의하고, 그 뒤에 적합한 Model이나 Provider를 선택한다. 특정 모델에 운영 구조가 종속되는 것을 피하고, 모델이 바뀌더라도 Role Architecture와 Governance Contract는 유지하려는 방향이다.

Agent 운영에서 가장 애매한 지점 중 하나는 "언제 Done인가"다. 모든 Action을 Human이 직접 확인하는 방식은 확장되지 않지만, Agent가 스스로 "완료했다"고 보고한 것을 그대로 상태 전환의 근거로 사용할 수도 없다.

그래서 Agent Foundry에서는 Evidence controls state transition을 중요한 원칙으로 둔다. 일반 작업은 Agent가 실행, Review, Validation까지 진행할 수 있지만, 완료 판단에는 Test Result, Runtime Read-back, Artifact, Review Result, External-system State 같은 독립된 Evidence가 필요하다. High-risk Change, Evidence 부재, Validation Failure, authority ambiguity가 발생하면 Human에게 Escalation한다.

이때 tracker의 상태, 실제 실행 상태, evidence 상태도 동일한 것으로 취급하지 않는다. 예를 들어 Issue가 Review 단계에 있어도 실행은 retry 중일 수 있고, 구현이 끝났더라도 required evidence가 없다면 Done은 아니다. Long-running Agent에서 이런 상태의 분리가 생각보다 중요했다.

Model이 reasoning을 제공하고, MCP와 Tooling이 외부 시스템 연결을 제공하며, Agent SDK나 Workflow Framework가 execution runtime과 orchestration primitive를 제공한다면, Agent Foundry는 이 구성요소를 특정 프로젝트에 어떤 규칙으로 적용할 것인가를 다루는 상위 Project Operating Layer로 보고 있다.

Model / Reasoning
MCP / Tools / Skills
Agent SDK / Workflow Runtime
        ↓
Agent Foundry
Project Context · Governance · Work Contracts
Roles · Toolkits · Validation · Reconciliation
        ↓
Repository / Tracker / Runtime / External Systems

즉 기존 도구를 대체하기보다 연결하고 제한하는 쪽에 가깝다. Work Tracker는 objective와 lifecycle state의 source of truth로, Repository는 code와 test 및 implementation history의 source of truth로, Runtime과 외부 시스템은 실제 동작 상태의 source of truth로 남겨둔다. Foundry가 모든 상태를 다시 저장하는 두 번째 Project Management System이 되는 것은 피하려고 한다.

현재 Agent Foundry는 private repository에서 실제 프로젝트에 적용하면서 구조를 검증하고 있다. 초기 core에서는 Diagnosis → Prescription → Compilation → Validation 경로를 read-only / preview 중심으로 먼저 증명하고, 광범위한 Controlled Apply는 그 이후 단계로 두고 있다. 프로젝트마다 다른 Context를 처리하더라도 Constitution, Policies, Harness, Role Architecture, Work Contract, Validation, Governance 같은 운영 자산은 재사용될 수 있는지를 확인하는 과정이다.

동시에 Foundry 자체가 새로운 복잡성 계층이 되지 않도록 경계도 계속 조정할 필요가 있다. Agent SDK나 workflow framework가 이미 잘 해결하는 문제를 다시 구현하지 않고, project-level operating decision과 evidence-backed governance에 집중하는 것이 현재의 product boundary다.

여러 유형의 프로젝트에서 반복 적용해도 이 구조가 유효하다는 근거가 쌓이고, public boundary와 documentation이 독립적으로 이해 가능한 수준이 되면 repository를 공개할 계획이다. 그 시점에는 완성된 "Agent Framework"를 공개한다기보다, 실제 프로젝트에서 Agent를 운영하면서 축적한 Project Operating Layer의 contracts, patterns, and implementation을 공개하는 형태에 더 가까울 것 같다.