X 발표의 핵심

Perplexity는 2026년 3월 11일 X에서 자사 API를 에이전트 개발용 full-stack, model-agnostic 플랫폼으로 확장했다고 밝혔다. 메시지의 초점은 통합이다. 모델 제공자, search 계층, retrieval 스택, 실행 환경을 각각 별도 공급자에서 조합하는 대신, 더 많은 구성요소를 Perplexity 단일 플랫폼에서 제공하겠다는 뜻이다.

메인 게시물은 플랫폼 포지셔닝을 강조했지만, 이어진 스레드는 제품 구성을 더 구체적으로 설명했다. Perplexity는 하나의 API key로 Agent API, Search API, Embeddings API, 그리고 준비 중인 Sandbox API를 아우른다고 밝혔다. 스레드 설명에 따르면 Agent API는 multi-step workflow를 위한 orchestration 레이어이고, Search API는 citation을 포함한 실시간 웹 컨텍스트, Embeddings API는 retrieval, Sandbox는 agent용 deterministic code execution을 담당한다.

공식 문서에서 확인되는 내용

Perplexity 공식 문서는 하나의 overview 아래에서 Agent API, Search API, Embeddings API quickstart를 제공하고 있다. 문서는 Agent API를 third-party model과 web-search tool/preset을 결합한 계층으로, Search API를 filtering과 real-time data를 갖춘 ranked web result 계층으로, Embeddings API를 semantic retrieval 인프라로 설명한다. 최근 changelog에 Agent API와 Embeddings API 출시 항목이 따로 올라온 점도, Perplexity가 단일 endpoint보다 더 넓은 developer platform을 조립하고 있음을 뒷받침한다.

Perplexity는 X에서 Search API가 SimpleQA와 SEAL에서 state of the art이며, 실시간으로 갱신되는 200B+ URLs 인덱스에 접근한다고 주장했다.
같은 스레드는 pplx-embed-v1-4B가 MTEB retrieval, ConTEB, 3천만 문서 이상 내부 benchmark에서 선도적이라고 설명한다.
또한 Sandbox API는 우선 Agent API 내부 tool로 제공된 뒤, 이후 standalone service로 노출될 예정이라고 밝혔다.

왜 중요한가

실무적으로 중요한 지점은 agent complexity 통제다. 지금도 많은 팀이 agent를 만들 때 모델, search, retrieval, tool execution 공급자를 따로 조합한다. 이 방식은 운영 표면적을 넓히고 비용, 지연, tracing을 관리하기 어렵게 만든다. Perplexity는 vertical integration으로 이 조합 비용을 낮출 수 있다고 보는 셈이다.

경쟁 구도 측면의 의미도 있다. 단일 자체 모델을 앞세우기보다 model-agnostic orchestration을 강조한다는 것은, Perplexity가 자신을 또 하나의 inference endpoint가 아니라 인프라 레이어로 자리매김하려 한다는 뜻이다. 다만 X 스레드만으로는 두 가지가 아직 남는다. benchmark와 scale 주장이 실제 고객 workload에서도 유지되는지, 그리고 개발자들이 modular architecture보다 bundled agent stack을 더 선호하는지가 향후 검증 포인트다.

출처: Perplexity X 게시물, Perplexity 공식 문서 overview, Perplexity changelog

#search-api

Perplexity, 에이전트용 모델 불문 풀스택 API 플랫폼 제시