Perplexity, Agent API에 Sandbox 실행 환경 추가… standalone service로도 제공

March 11, 2026에 Perplexity는 X를 통해 Sandbox API를 Agent API 내부 tool로 제공하고, 동시에 standalone service로도 공개하겠다고 밝혔다. 회사는 이 환경을 자사가 내부적으로 사용하는 execution runtime과 동일한 것으로 설명했으며, orchestration runtime이 필요할 때 deterministic code execution을 위임할 수 있다고 말했다.

현재 공개된 Agent API quickstart는 Perplexity를 multi-provider LLM application interface로 소개한다. 문서에 따르면 개발자는 하나의 API를 통해 여러 provider의 모델에 접근하면서 reasoning, token budget, tool을 일관된 문법으로 설정할 수 있다. 별도의 Tools documentation에서는 각 request마다 tool을 명시적으로 활성화해야 하며, 현재 built-in tool은 web_search와 fetch_url, 그리고 외부 시스템과 연결하는 custom function이라는 점을 설명한다.

Sandbox update가 바꾸는 점

• deterministic code execution을 agent runtime의 first-class tool에 더 가깝게 가져온다.
• Perplexity 내부 execution environment를 standalone developer surface로 노출한다.
• retrieval과 code execution을 하나의 orchestration flow 안에서 결합하기 쉽게 만든다.

이 변화가 중요한 이유는 실제 agent workload가 retrieval만으로 끝나지 않기 때문이다. research-style agent는 웹 검색 이후 파일을 파싱하고, 데이터를 변환하고, 계산을 검증하고, 작은 프로그램을 실행해야 하는 경우가 많다. 지금까지 Perplexity의 공개 문서는 retrieval 중심 tool과 custom function call에 무게를 두고 있었다. March 11 X post는 회사가 code execution을 외부 부가 기능이 아니라 orchestration model의 중심에 더 가깝게 두려 한다는 신호로 읽힌다.

이 발표 시점 기준으로 공개 문서는 여전히 web_search, fetch_url, custom function 중심의 tool framework를 설명하고 있었기 때문에, 이번 X post는 deterministic execution이 그 모델 안에 어떻게 들어올지를 보여주는 초기 신호에 가깝다. 향후 Perplexity가 limit, security control, pricing을 명확히 제시한다면, Sandbox는 research agent와 deterministic action이 필요한 workflow 사이를 잇는 실용적 다리가 될 수 있다.

결국 이것은 단순한 tool toggle 이상의 의미를 가진다. agent platform 경쟁이 model access, retrieval, controlled execution을 얼마나 적은 구성요소로 하나의 developer surface에 묶어내느냐로 이동하고 있다는 점을 보여주기 때문이다.