PilotDeck 2.0 오픈소스, 채팅보다 오피스 산출물 제공에 초점

PilotDeck 2.0 오픈소스가 10월 15일 분명한 약속과 함께 공개됐다. 에이전트 작업의 일관성을 2,000개의 상호작용 메시지에 걸쳐 유지하고 완성된 오피스 파일을 제공하겠다는 것이다. 이번 릴리스는 칭화대학교 THUNLP, ModelBest, OpenBMB, AI9Stars가 내놓았다. 이는 업무를 논의하는 어시스턴트와 업무를 안정적으로 끝마치는 에이전트 사이에 지속돼 온 간극을 겨냥한다.

이 구분은 또 하나의 모델 리더보드보다 더 중요하다. PilotDeck은 AI 작업의 유용한 단위가 응답, 프롬프트, 또는 개별 도구 호출이 아니라고 본다. 대신 지침, 파일, 메모리, 실행 기록, 최종 산출물을 담고 복구할 수 있는 작업 공간을 그 단위로 제시한다.

이에 따라 이번 릴리스는 두 가지 기존 경로에 도전한다. 호스팅형 어시스턴트는 대개 기존 생산성 제품군 안에서 편리한 접근성을 제공한다. Claude Code와 Codex 같은 개발자 중심 에이전트는 유연하고 도구 기반의 실행을 선호한다. PilotDeck은 두 번째 경로를 일반적인 오피스 업무로 확장하면서도 운영 계층은 개방하고 모델 선택권은 유지하려 한다.

매력적인 설계이지만, 아직은 설계상의 주장에 머문다. 이 프로젝트는 2,000개 메시지 세션이 정확한 문서, 스프레드시트 또는 프레젠테이션을 일관되게 만들어 낸다는 독립 평가를 공개하지 않았다. 최근 오피스 에이전트 연구는 대화 길이가 아니라 최종 산출물의 품질이 여전히 어려운 과제임을 시사한다.

PilotDeck 2.0 오픈소스가 에이전트 작업의 단위를 바꾸다

PilotDeck 2.0은 단일 채팅이 아니라 지속적인 프로젝트 작업 공간을 에이전트 작업의 기본 컨테이너로 다룬다.

프로젝트의 오픈 리포지터리는 PilotDeck을 작업 지향 AI 에이전트 생산성 플랫폼으로 설명한다. 10월 15일 발표에서는 원클릭 설치, 시각적 구성, 장기 실행 작업의 연속성, Word·Excel·PowerPoint용 신규 스킬을 강조했다.

소프트웨어 자체는 이미 2026년 5월에 오픈소스로 공개됐다. 2.0 발표는 프로젝트의 첫 공개 코드 릴리스라기보다 제품 확장으로 이해하는 편이 적절하다. 초점이 개방형 에이전트 인터페이스에서 오피스용 파일을 제공하도록 설계된 시스템으로 이동했다.

PilotDeck은 핵심 조직 단위를 WorkSpace라고 부른다. 각 WorkSpace는 실제 작업 디렉터리를 중심으로 프로젝트 파일, 세션, 메모리, 확장 기능, 실행 상태를 연결한다. 별도의 세션은 서로 다른 목표를 추구하면서도 같은 프로젝트 파일과 장기 컨텍스트를 공유할 수 있다.

이 구조는 긴 과제에서 발생하는 실질적인 문제를 해결한다. 일반적인 채팅은 대화 기록이 길어질수록 유용한 세부 정보를 잃기 쉽다. 또한 대화 밖에 있는 파일의 현재 상태와도 연결이 약하다.

반면 PilotDeck은 메시지, 도구 결과, 작업 상태, 생성된 산출물을 기록한다. 문서에 따르면 과거 세션은 설정과 최근 압축 컨텍스트를 복원할 수 있다. 이후 에이전트는 계속 진행하기 전에 실제 작업 디렉터리를 다시 읽는다.

이러한 분리는 중요하다. 과거 작업의 요약은 해당 작업이 파일을 올바르게 변경했다는 증거가 아니다. 현재 환경을 다시 확인하면 에이전트가 실제로 어떤 일이 일어났는지 감지할 가능성이 높아진다.

이번 릴리스는 Word 문서, 스프레드시트, 프레젠테이션을 만드는 스킬도 내세운다. 스킬은 작업 지침과 운영 지식을 재사용할 수 있도록 묶은 것이다. 에이전트에게 원본 자료를 검토하고, 산출물을 구성하며, 결과를 검증하는 방법을 알려줄 수 있다.

이 접근은 챗봇에 내보내기 버튼 세 개를 추가하는 것과 다르다. 완전한 오피스 작업에는 여러 파일 읽기, 사실 추출, 값 계산, 콘텐츠 초안 작성, 서식 적용, 완성된 패키지 점검이 필요할 수 있다. PilotDeck은 이러한 단계를 하나의 복구 가능한 실행 환경 안에 담으려 한다.

발표된 2,000개 메시지 기능은 신중하게 해석해야 한다. 이는 시스템이 컨텍스트 예산 관리와 압축을 통해 처리할 수 있다고 밝힌 상호작용 기록을 가리킨다. 감독, 오류 또는 컨텍스트 손실 없이 2,000개의 자율 작업을 연속 수행한다는 뜻은 아니다.

이 차이가 이 글의 핵심 긴장을 규정한다. 더 긴 연속성은 에이전트가 실제 업무를 끝낼 여지를 넓힌다. 동시에 잘못된 가정, 오래된 파일 또는 결함 있는 도구 결과가 이후 모든 과정에 영향을 줄 기회도 늘어난다.

그럼에도 이번 릴리스는 오피스 에이전트를 둘러싼 대화를 바꾼다. 사용자가 소프트웨어를 가장 최근 답변의 유창함이 아니라 작업 공간에 남겨진 산출물로 판단하도록 요구한다.

핵심 메커니즘은 메모리, 파일, 복구 가능한 실행이다

PilotDeck의 주요 기술적 주장은 안정적인 산출물 제공에는 모델의 즉각적인 컨텍스트 창 바깥에 있는 지속 상태가 필요하다는 것이다.

모델은 모든 이전 메시지, 문서, 도구 출력을 영원히 담아 둘 수 없다. 각 모델에는 한 번의 요청에서 처리할 수 있는 정보량이 제한된 컨텍스트 창이 있다. 장기 실행 에이전트는 무엇을 보존하고, 압축하고, 검색하고, 다른 위치에 저장할지 결정해야 한다.

PilotDeck의 제품 아키텍처는 시스템이 각 요청에 대해 핵심 지침, 프로젝트 지침, 스킬, 과거 메시지, 도구 결과, 장기 메모리를 조합한다고 설명한다. 이후 선택한 모델의 컨텍스트 용량에 맞춰 이 자료를 할당한다.

대용량 도구 결과는 모델 입력을 반복적으로 차지하는 대신 파일로 저장할 수 있다. 과거 메시지는 필수 작업 관계를 보존하는 요약으로 압축할 수 있다. 장기 메모리는 세션 압축과 별도로 유지된다.

이 구분은 흔한 혼란의 한 원인을 줄인다. 세션 압축은 원시 대화 기록이 너무 커진 뒤에도 현재 과제를 이어 가도록 돕는다. 장기 메모리는 별도 세션에 걸쳐 재사용 가능한 지식을 전달한다.

어느 메커니즘도 정확성을 보장하지는 않는다. 압축된 요약은 나중에 중요해지는 단서를 빠뜨릴 수 있다. 저장된 메모리는 잘못된 해석을 보존할 수 있다. 이점은 자동적인 진실이 아니라 운영상의 연속성이다.

PilotDeck은 모델 라우팅을 통해 또 하나의 계층을 더한다. 사용자는 여러 제공업체를 구성하고 작업 복잡도에 따라 서로 다른 모델을 배정할 수 있다. 경량 모델은 일상적인 작업을 처리하고, 더 높은 성능의 모델은 추론 비중이 큰 단계를 맡는다.

라우터는 모델 요청이 실패할 때를 위한 대체 체인도 지원한다. PilotDeck은 사용 통계를 기록하고 구성된 기준선과의 차이를 추정할 수 있다. 문서에서는 추정 금액이 실제 제공업체 청구액과 같지 않다고 경고한다.

따라서 모델 선택은 작업 공간 자체와 분리된다. 팀은 모든 프로젝트를 한 공급업체의 모델에 묶는 대신 지원되는 프로토콜을 통해 서비스를 연결할 수 있다. 이는 PilotDeck과 폐쇄형 생산성 어시스턴트의 가장 분명한 차이 중 하나다.

시스템은 파일 편집, 명령 실행, 웹 접근, 외부 서비스를 위한 도구도 제공한다. MCP, 즉 Model Context Protocol은 호환되는 서비스가 에이전트 실행 흐름 안에서 호출 가능한 도구로 나타나도록 한다. 특정 작업 공간에 다른 접근 권한이 필요할 경우 프로젝트 수준 구성은 전역 연결을 재정의할 수 있다.

도구는 권한 경계 안에서 작동한다. PilotDeck은 실행 전 매개변수와 권한을 확인하며, 파일 접근은 작업 디렉터리와 기타 승인된 경로에 따라 달라진다고 설명한다. 이는 에이전트가 접근할 수 있는 대상을 정의할 수 있는 가시적인 위치를 만든다.

런타임은 반복 루프를 통해 이러한 구성 요소를 조정한다. 모델이 작업을 선택하고, 도구가 환경을 변경하거나 점검하며, 그 결과가 모델로 돌아간다. 실행은 완료, 취소, 복구 불가능한 실패 또는 구성된 루프 한도에 도달하면 끝난다.

코딩 에이전트가 이미 유사한 패턴을 사용하기 때문에 이는 익숙하게 들린다. PilotDeck의 승부수는 오피스 특화 스킬 및 산출물 점검과 결합할 때 동일한 운영 모델이 더 폭넓은 지식 업무를 처리할 수 있다는 데 있다.

프레젠테이션 작업은 이 차이를 잘 보여 준다. 일반적인 어시스턴트는 채팅 응답으로 슬라이드 텍스트 초안을 작성할 수 있다. 작업 공간 에이전트는 원본 문서를 검토하고, 덱을 만들고, 구조를 점검하고, 복잡한 슬라이드를 수정한 뒤 입력 자료 옆에 편집 가능한 파일을 남길 수 있다.

스프레드시트 과제는 다른 요구를 제기한다. 에이전트는 데이터 유형, 수식, 레이블, 통합 문서 구조를 보존해야 한다. 그럴듯한 텍스트 설명은 전달된 파일 내부의 깨진 참조를 보완할 수 없다.

그래서 재사용 가능한 프로세스 지침이 중요하다. AI workflow를 개발하는 팀에는 안정적인 입력, 명시적인 점검, 검토 가능한 출력이 필요하다. PilotDeck은 이를 프롬프트 전반에 흩어 두는 대신 프로젝트 디렉터리를 중심으로 묶는다.

메커니즘은 일관적이다. 지속 파일은 현실을 고정하고, 세션 기록은 실행 이력을 보존하며, 압축은 컨텍스트 증가를 제한하고, 스킬은 반복 작업을 안내한다. 남은 질문은 이러한 계층이 까다로운 과제에서 누적 오류를 얼마나 잘 견디느냐이다.

오피스 에이전트는 이제 답변이 아니라 산출물로 경쟁한다

PilotDeck은 호스팅형 오피스 어시스턴트와 개발자 에이전트 플랫폼 모두에 다중 파일 작업을 완수할 수 있음을 입증하라는 압박을 가한다.

호스팅형 어시스턴트는 사람들이 이미 사용하는 애플리케이션 가까이에 있다는 이점이 있다. Microsoft와 Google은 문서, 스프레드시트, 이메일, 캘린더 옆에 AI 기능을 배치할 수 있다. 이러한 배포 방식은 설정 부담을 줄이고 어시스턴트가 익숙한 업무 흐름에 접근하도록 한다.

이 경로는 사용자를 공급업체가 통제하는 환경 안에 두기도 한다. 모델 선택, 오케스트레이션 세부 사항, 심층 실행 동작은 수정 가능성이 제한적인 경우가 많다. 조직은 각 제공업체가 제공하는 통합 및 제어 범위 안에서 작업해야 한다.

PilotDeck은 반대 경로를 택한다. 코드는 GNU Affero General Public License 버전 3을 사용한다. AGPL 약관은 검사와 수정을 허용하는 동시에 적용 대상 네트워크 사용 시나리오에서는 소스 공유 의무를 부과한다.

이러한 개방성은 에이전트 동작을 검토하려는 개발자, 연구자, 조직에 중요할 수 있다. 하지만 작업도 필요하다. 누군가는 시스템을 배포하고, 제공업체를 구성하고, 자격 증명을 관리하고, 권한을 정의하고, 스킬을 평가하고, 업데이트를 유지해야 한다.

리포지터리는 Windows, macOS, Linux용 데스크톱 패키지와 설치 경로를 제공한다. 공개 릴리스 이력도 2.0 발표 이후 빌드와 수정이 계속됐음을 보여 준다. 이러한 활동은 프로젝트가 유지되고 있다는 인상을 뒷받침하지만, 프로덕션 신뢰성을 측정하는 것은 아니다.

개발자 중심 에이전트는 다른 형태의 압박을 받는다. 이들의 도구 기반 실행은 모델이 리포지터리를 탐색하고, 파일을 편집하고, 명령을 실행하며, 테스트 실패 후 작업을 수정할 수 있음을 보여 왔다. 오피스 에이전트는 점점 이 운영 패턴을 차용하고 있다.

PilotDeck은 코딩 에이전트 인터페이스, 모델 라우터, 메모리 시스템, 검색 프레임워크, 스킬과 관련된 아이디어와 구성 요소를 명시적으로 활용한다. 이 프로젝트의 기여는 이러한 요소를 지속적인 작업을 위한 범용 작업 공간으로 전환하려는 시도다.

그렇다고 PilotDeck이 모든 코딩 에이전트를 직접 대체한다는 뜻은 아니다. 소프트웨어 리포지터리는 유난히 강력한 피드백을 제공한다. 테스트는 실패할 수 있고, 컴파일러는 잘못된 구문을 거부할 수 있으며, 버전 관리는 정확한 변경 사항을 드러낼 수 있다.

오피스 산출물에는 종종 이에 준하는 검증 절차가 부족합니다. 프레젠테이션은 정상적으로 열리면서도 근거 없는 주장을 담을 수 있습니다. 스프레드시트는 유효한 수식을 포함하고도 잘못된 비즈니스 가정을 적용할 수 있습니다. 보고서는 서식 요건을 충족하면서도 결정적인 출처를 누락할 수 있습니다.

따라서 경쟁의 경계는 실행 투명성과 애플리케이션 편의성 사이에 놓입니다. PilotDeck은 작업 공간, 모델, 도구, 스킬에 대한 통제권을 제공합니다. 호스팅형 제품군은 널리 배포된 오피스 애플리케이션 및 ID 시스템과 더 긴밀하게 통합됩니다.

어느 쪽도 최종 단계의 검증 문제를 해결하지는 못했습니다. 로컬에서 실행되는 오픈 에이전트도 완성도는 높지만 틀린 산출물을 만들 수 있습니다. 깊이 통합된 상용 어시스턴트도 요청을 오해하거나 중요한 작업을 미완성으로 남길 수 있습니다.

이는 엔터프라이즈 구매자에게 중요합니다. 모델 품질은 시스템의 한 부분일 뿐이기 때문입니다. 이들은 권한 설계, 감사 가능성, 파일 호환성, 복구 동작, 데이터 처리 방식, 작업별 지침을 유지하는 데 필요한 노력도 평가해야 합니다.

PilotDeck의 작업 공간 모델은 이러한 운영 계층을 더 쉽게 점검할 수 있게 합니다. 사용자는 파일, 실행 기록, 도구 호출, 구성된 확장 기능을 볼 수 있습니다. 이러한 가시성은 디버깅과 내부 검토를 뒷받침합니다.

하지만 관측 가능성을 정확성과 혼동해서는 안 됩니다. 완전한 로그는 에이전트가 어떻게 잘못된 결과에 도달했는지 설명할 수 있습니다. 사람, 테스트 또는 보조 시스템이 이를 인식하지 않는 한 오류를 막지는 못합니다.

2.0 릴리스는 경쟁사가 이 구분을 피하기 어렵게 만듭니다. 오피스 에이전트가 완료된 작업을 약속한다면, 공급업체는 매력적인 채팅 시연 이상의 것을 보여줘야 합니다. 길고 분기되는 워크플로를 거친 뒤에도 최종 파일이 계속 사용할 수 있다는 증거가 필요합니다.

2,000개 메시지 실행은 신뢰성 벤치마크가 아니다

PilotDeck의 핵심 장기 실행 주장은 작업 정확성이 늘어난 길이 속에서도 유지될 때에만 의미가 있습니다.

프로젝트 측은 PilotDeck 2.0이 2,000개의 상호작용 메시지에 걸쳐 장기 실행 작업을 정상 궤도에 유지할 수 있다고 말합니다. 이는 구체적인 용량 주장입니다. 그러나 공개 발표에는 그 길이와 성공적인 오피스 산출물을 연결하는 독립 벤치마크가 제시되지 않았습니다.

상호작용 횟수 역시 작업 난이도를 완벽하게 나타내는 지표는 아닙니다. 2,000번의 짧은 확인은 일관되지 않은 소스 파일을 다루는 40단계 과제보다 적은 추론을 요구할 수 있습니다. 긴 대화 기록은 생산적인 반복, 반복적인 실패, 또는 둘 다를 나타낼 수 있습니다.

더 강력한 검증은 최종 산출물이 세부 평가 기준을 충족하는지 여부입니다. 올바른 정보를 담고, 필요한 구조를 보존하며, 편집 가능한 상태를 유지하고, 예상된 소프트웨어에서 열려야 합니다. 또한 근거 없는 추가 내용도 피해야 합니다.

기존 연구는 신중해야 할 이유를 제공합니다. 2024년 OfficeBench 평가는 현실적인 오피스 워크플로와 여러 애플리케이션에 걸쳐 에이전트를 시험했습니다. GPT-4 Omni는 보고된 통과율 47%로 가장 높은 성과를 냈지만, 신뢰할 수 있는 오피스 자동화에 필요한 수준에는 여전히 미치지 못했습니다.

연구진은 중복 작업, 환각, 애플리케이션 간 전환의 어려움과 실패를 연결했습니다. 이러한 문제는 에이전트가 문서, 스프레드시트, 프레젠테이션, 외부 정보를 조율해야 할 때 특히 중요해집니다.

더 새로운 연구는 산출물 수준의 평가를 통해 관련된 결론에 도달합니다. 2026년 office-agent 벤치마크는 실무자 요청에서 도출한 100개의 장기 과제를 포함합니다. 각 과제는 평균 2.32시간의 인간 노동이 필요하며, 세부적인 코드 기반 검사를 통해 평가됩니다.

이 연구는 평가 대상 언어 모델 에이전트가 인간 작업자보다 더 빠르고 낮은 추론 비용으로 작업을 완료했다고 밝혔습니다. 그러나 어느 모델도 산출물 품질에서 인간 기준선에 근접하지 못했습니다.

벤치마크는 또한 인간이 수행하는 작업 시간이 길수록 에이전트 점수가 낮아지는 경향이 있음을 발견했습니다. 연구진은 이 패턴을 지속적인 계획 수립 요구, 세밀한 파일 조작, 구조적 실수가 누적될 기회 증가로 설명했습니다.

운영 방식 비교는 PilotDeck과 특히 관련이 있습니다. 코딩 전용 설정은 벤치마크에서 14.41점을 기록해, 코딩과 컴퓨터 사용을 결합한 하이브리드 설정의 13.77점보다 약간 높았습니다. 컴퓨터 사용 전용 설정은 0.78점이었습니다.

이 수치는 해당 벤치마크와 그 특정 프레임워크에 속합니다. PilotDeck의 성능 수치로 사용해서는 안 됩니다. 그럼에도 PilotDeck의 스킬 뒤에 있는 더 폭넓은 생각, 즉 직접 파일을 조작하는 방식이 긴 시각적 클릭 연쇄보다 더 신뢰할 수 있을 수 있다는 점을 뒷받침합니다.

또한 남은 문제도 드러냅니다. 프로그래밍 방식의 편집은 일부 인터페이스 오류를 줄이지만, 의미적 품질을 보장하지는 않습니다. 코드는 정확히 맞는 셀에 잘못된 결론을 넣을 수 있습니다.

PilotDeck에는 주장에 걸맞은 공개 평가가 필요합니다. 유용한 테스트는 소스 파일과 고수준 과제에서 시작해 작업 공간에 남은 실제 Word 문서, 워크북 또는 프레젠테이션을 채점하는 방식일 것입니다.

평가에서는 완전 실패, 부분 완료, 근거 없는 주장, 서식 결함, 사람이 수정하는 데 걸린 시간을 보고해야 합니다. 또한 모델 성능과 에이전트 프레임워크가 가져온 개선을 구분해야 합니다.

장기 세션 테스트에는 별도의 실패 분석이 필요합니다. 연구자들은 컨텍스트 압축이 요구사항을 잃는지, 오래된 기억이 더 새로운 지침을 덮어쓰는지, 복구가 올바른 파일 상태에서 재개되는지를 점검해야 합니다.

보안은 또 다른 불확실성을 더합니다. 명령 접근 권한, 외부 도구, 프로젝트 자격 증명을 가진 에이전트는 챗봇보다 더 넓은 행동 범위를 가집니다. 권한 검사는 도움이 되지만, 관리자는 시스템이 악성 문서, 프롬프트 인젝션, 과도하게 넓은 도구 접근을 어떻게 처리하는지도 테스트해야 합니다.

오픈 리포지터리는 외부 연구자에게 이러한 질문을 검토할 수 있는 능력을 제공합니다. 이는 실질적인 장점입니다. 하지만 프로젝트의 장기 실행 표현이 신뢰할 수 있는 무인 작업의 증거가 되기 전에 독립적인 테스트는 여전히 이뤄져야 합니다.

현재로서는 신중한 해석이 분명합니다. PilotDeck은 장기 작업을 유지하기 위한 설득력 있는 아키텍처를 제시하지만, 그 작업이 올바르게 끝난다는 증거는 아닙니다.

PilotDeck 2.0의 중요성을 결정할 세 가지 신호

PilotDeck의 다음 단계는 산출물 벤치마크, 반복 가능한 실제 업무 활용, 엄격한 확장 기능 거버넌스에 달려 있습니다.

첫 번째 신호는 독립적인 오피스 산출물 평가입니다. 동일한 모델, 소스 파일, 지침, 채점 기준을 사용해 PilotDeck을 다른 에이전트 프레임워크와 비교해야 합니다.

이 비교는 작업 공간, 메모리, 라우팅, 스킬이 기반 모델을 넘어 결과를 개선하는지 드러낼 것입니다. 지연 시간이나 토큰 사용량만이 아니라 완료 품질과 사람의 수정 노력을 측정해야 합니다.

강력한 결과는 지속적인 실행 아키텍처가 장기 작업을 개선한다는 PilotDeck의 핵심 주장을 뒷받침할 것입니다. 약한 결과는 이 시스템이 주로 에이전트가 불확실한 결정을 계속 내릴 수 있는 시간만 늘린다는 점을 시사할 것입니다.

두 번째 신호는 반복적인 업무 현장 활용의 증거입니다. 가장 유용한 사례는 정해진 입력 집합으로 주간 운영 보고서를 만드는 것처럼 명확한 승인 기준을 갖춘 반복 작업일 것입니다.

사용자는 산출물이 수정 없이 승인되는 빈도, 세션에 개입과 복구가 필요한 빈도, 반복되는 오류의 종류를 추적해야 합니다. 이러한 사례를 공개적으로 축적하는 것이 개별 시연보다 더 설득력 있을 것입니다.

신뢰할 수 있는 사용을 위해서는 정직한 실패 상태도 필요합니다. 에이전트는 필수 정보가 없을 때 중단하고, 해결되지 않은 충돌을 드러내며, 완료된 작업과 부분 출력물을 구분해야 합니다. 그럴듯한 파일을 조용히 만드는 것은 성공적인 납품이 아닙니다.

세 번째 신호는 스킬과 외부 도구에 관한 거버넌스입니다. 재사용 가능한 스킬은 가치 있는 워크플로를 담을 수 있지만, 취약한 가정, 안전하지 않은 명령, 오래된 요구사항을 포함할 수도 있습니다.

팀에는 설치하는 확장 기능에 대한 버전 관리, 검토, 권한 제한, 테스트 사례가 필요합니다. 프로젝트별 스킬은 결과물에 책임지는 사람들이 이해할 수 있는 상태로 유지되어야 합니다.

메모리에도 같은 수준의 검토가 적용됩니다. 사용자는 시스템이 무엇을 보존하는지, 저장된 지식을 어떻게 업데이트하는지, 잘못된 기억을 어떻게 제거하는지 제어할 수 있어야 합니다. 아무도 에이전트가 왜 계속 잘못된 결정을 반복하는지 설명할 수 없다면 지속적인 컨텍스트는 부담이 됩니다.

PilotDeck 2.0이 중요한 이유는 이러한 운영 문제를 오피스 자동화의 중심에 놓기 때문입니다. 완성도 높은 답변을 최종 제품으로 취급하지 않습니다. 작업 공간과 그 안에서 전달된 파일을 제품으로 봅니다.

이러한 관점은 일반적인 어시스턴트 소프트웨어보다 더 많은 것을 요구합니다. 에이전트는 상태를 보존하고, 도구를 운영하며, 중단에서 복구하고, 검토를 견딜 수 있는 산출물을 만들어야 합니다.

오픈소스 모델은 PilotDeck에 유용한 앞으로의 경로를 제공합니다. 연구자는 벤치마크를 만들 수 있고, 개발자는 동작을 감사할 수 있으며, 팀은 실제 워크플로에 맞게 스킬을 조정할 수 있습니다. 프로젝트의 약 2,000개 메시지 연속성 주장은 테스터에게 구체적인 목표도 제공합니다.

결정적인 질문은 더 이상 PilotDeck 2.0 오픈 소스가 에이전트의 대화를 계속 유지할 수 있는지가 아닙니다. 팀이 에이전트에게 복잡한 과제를 맡기고 나중에 돌아와, 남겨진 파일을 신뢰할 수 있는지입니다. 권한을 확대하기 전에 하나의 반복 워크플로에서 이 결과를 테스트하고, 모든 산출물을 채점하며, 모든 사람의 수정을 기록해야 합니다.