Show HN: Airbyte Agents – 여러 데이터 소스 간 에이전트 컨텍스트

Michel 입니다 (Airbyte 공동 창업자 및 CEO). 우리는 지난 6 년간 데이터 커넥터 (data connectors) 를 구축해 왔습니다. 오늘 우리는 에이전트가 운영 시스템 전반에 걸쳐 정보를 발견하고 행동을 취할 수 있도록 하는 통합 데이터 레이어인 Airbyte Agents (https://docs.airbyte.com/ai-agents/) 를 출시합니다.

여기서는 빠른 설명을 드립니다: https://www.youtube.com/watch?v=ZosDytyf1fg

에이전트가 실제 워크플로우로 이동함에 따라, 그들은 더 많은 도구에 접근할 필요가 있습니다 (예: Slack, Salesforce, Linear). 이는 엄청난 API 파이프라인 (API plumbing) 을 의미합니다: 인증, 페이징, 필터링, 스키마 처리, 그리고 시스템 간 엔티티 매칭 등.

대부분의 MCP 는 이를 해결하지 않습니다. 그들은 API 의 얇은 래퍼일 뿐이며, 에이전트는 여전히 약한 원시 (primitives) 를 상속받으며 대부분의 경우 잘못 작동합니다, 특히 여러 도구를 사용할 때.

더 깊은 문제는 API 가 이미 무엇을 조회할지 알고 있다고 가정한다는 점입니다 (엔드포인트, Object ID, 필드 등을 생각해보세요). 반면 에이전트는 보통 한 단계 앞선 곳에서 시작합니다: 추론을 시작하기 전에 먼저 무엇이 중요한지 발견해야 합니다.

따라서 우리는 Airbyte Agents 를 데이터와 당신의 에이전트 사이의 컨텍스트 레이어로 구축했습니다. 핵심은 우리가 Context Store 라고 부르는 것입니다: Our replication connectors 로 채워진 에이전트 검색을 최적화한 데이터 인덱스입니다. 지난 6 년간 데이터 커넥터 작업이 여기서 유용하게 쓰입니다!

이는 에이전트가 데이터를 구조화된 방식으로 발견할 수 있게 해주며, 필요시 상류 시스템으로 직접 읽기 및 작성을 허용합니다.

우리가 이 작업을 시작하게 된 계기는 우리 SDK 로 마이그레이션하는 과정에서 겪은 비정상적인 trace (추적) 입니다. 그 질문은 "이번 분기에 이탈 위험이 있는 고객은 누구인가?"였습니다. trace 는 47 단계로 이루어져 있었습니다. 대부분 API 호출이었습니다. 에이전트는 먼저 여러 계정을 찾아야 했고, 이를 올바른 고객으로 매핑해야 했고, 티켓을 찾아야 했으며... 그리고 에이전트가 최종 응답을 할 때, 대답은 괜찮아 보였지만 옳지 않았습니다. 그것뿐만 아니라, 그 속도는 끔찍하게 느렸습니다. 그래서 우리는 무언가를 해야 했습니다.

그 47 단계의 에이전트는 Airbyte Agents 가 특히 잘 작동하는 질문 중 하나입니다. 다른 예시들: - "이번 달에 닫히는 모든 엔터프라이즈 거래를 보여주세요 (Open support tickets 포함)." - "Github 이슈가 열린 지원 티켓을 모두 찾아주세요"

이것들은 단순해 보일 수 있지만, 에이전트가 런타임에 모든 컨텍스트를 조립할 필요가 없을 때 답변의 품질은 크게 달라집니다.

우리가 제품의 초기 버전을 갖게 된 후, 저는 주말 동안 벤치마킹 하르ネス (벤치마크 테스트 도구) 를 구축하여 그것이 작동하는지 확인했습니다. 또한 재미로, 저는 벤치마크 작성을 좋아합니다 :). Airbyte Agent MCP 를 호출 vs 여러 벤더 MCP 를 직접 호출을 비교했습니다. 검색과 검색 (retrieval, search) 을 테스트했습니다.

간단함을 위해, 저는 토큰 소비를 측정 단위로 사용했습니다. 저는 그것이 에이전트가 얼마나 잘 작동하는지 나타내는 좋은 대안이라고 생각합니다. 실패한 에이전트 (예: 47 단계가 걸린 에이전트) 는 어디에도 도달하지 못한 채 많은 토큰을 소비하며, 성공한 에이전트는 바로 핵심에 도달합니다.

측정할 때 발견한 내용은 다음과 같습니다: Gong 은 자체 MCP 보다 최대 80% 적은 토큰을 사용했고, Zendesk 는 최대 90%, Linear 는 최대 75%, Salesforce 는 최대 16% (Salesforce 의 자체 SOQL 이 여기서는 잘 작동함).

물론 usual obvious bias 가 있습니다: 우리는 벤치마킹하는 것을 구축한 것입니다. 그래서 테스트 하르ネス를 공개했습니다: https://github.com/airbytehq/airbyte-agents-benchmarks. 그것을 파고들면 좋으며, 발견한 것이 있다면 알려주세요!

• 사전에 데이터를 인덱싱 (indexing) 하거나, 에이전트가 실시간으로 API 를 호출하도록 허용하나요?
• 여러 시스템 간 엔티티 매칭 (entity matching) 을 어떻게 수행하나요?

더 나은 방향으로 개선할 수 있는 의견, 댓글, 아이디어를 듣고 싶습니다. 우리가 놓치고 있을 수 있는 명확한 사항도 알려주시면 감사하겠습니다. 현재는 계속해서 구축 (building) 을 계속하는 데 열정적입니다.