Perplexity's Agent API, Explained

Part of a series on running AI workflows across model providers — this one covers what's replacing Sonar after September 27, 2026.

The previous article covered the fact that Perplexity's Sonar API is being retired on September 27, 2026. This one covers what's actually replacing it — because the Agent API isn't a rename, it's a meaningfully different product, and understanding it matters even if DNotifier is handling the integration details for you.

The core idea: a managed runtime, not just an endpoint

Perplexity's own framing is useful here: the Agent API is designed to replace "a model router, a search layer, an embeddings provider, a sandbox service, and a monitoring stack with a single integration point." That's a much bigger claim than "we added search to chat completions." It's positioning itself as infrastructure for building agents generally, not just as an upgraded way to ask a question and get a sourced answer.

The mental model Perplexity describes: the language model acts as a processor that receives an objective, breaks it into a plan, selects the right tool for each step, executes, and iterates until the objective is met. That's the same agentic loop pattern that shows up across this entire series in different forms — DNotifier's own defineAgent()/Workflow model is built around a version of the same idea.

One integration point standing in for what used to be several separate services.

What it can actually do

Three built-in tools are worth knowing about specifically:

On top of the tools, there's a max_steps parameter controlling how many rounds of tool use and reasoning an agent gets before it has to produce a final answer — genuinely useful for tasks that need to search, read, search again based on what it found, and only then answer, rather than answering off a single search pass.

There's also multi-model access built in: rather than being limited to Perplexity's own models, the Agent API is described as model-agnostic, giving access to models from multiple frontier providers through one unified specification, with automatic fallback chains if a given model is unavailable.

Multiple steps happening under one request — search, then read, then reason, then answer.

The technical shape of a request

The Agent API runs on a new endpoint (/v1/agent, with an alias at /v1/responses for compatibility), and requests are structured around a model or preset selection, an input, optional tool declarations, and optional instructions — a noticeably different shape than the OpenAI-compatible chat-completions format Sonar used. This is part of why the migration isn't a drop-in swap: existing code built around the old chat-completions structure needs actual changes, not just a model-name update.

Should you adopt it directly, or let DNotifier handle it?

For most teams using Perplexity through DNotifier, the honest answer is: let DNotifier's provider abstraction absorb this change. The entire point of routing model calls through sendAI() and defineAgent() rather than calling provider SDKs directly is that provider-side changes like this one get handled in one place — the provider configuration — instead of in every application that calls Perplexity.

Where it's worth reaching for the Agent API's specific capabilities directly is when you need something DNotifier's abstraction doesn't expose as a first-class feature yet — the finance_search tool for a finance-specific product, or fine-grained max_steps control for a genuinely open-ended research task. For the common case of "get a current, sourced answer to a question," the abstraction is doing exactly what it's supposed to do.

A use case worth noting

A due-diligence tool built for an investment research team needed to search for a company, read several of its recent filings in full rather than just snippets, cross-reference figures across them, and produce a structured summary — a task that genuinely benefits from the Agent API's fetch_url tool and multi-step reasoning rather than a single search-and-answer call. That's a case where reaching past the standard abstraction to the Agent API's specific capabilities was the right call, distinct from the majority of use cases in this series that don't need that level of control.

Frequently asked questions

Do I need to rewrite my DNotifier Perplexity integration to use the Agent API?

Not necessarily — DNotifier's provider layer is designed to absorb exactly this kind of underlying change. Check your AI Studio provider settings for current status rather than assuming you need to hand-roll a migration yourself.

Is the Agent API more expensive than the old Sonar API?

The pricing model is structured differently — presets replace flat per-request tiers, and tool use (like fetch_url calls) can add its own cost. Perplexity Pricing, Explained covers pricing specifics.

Can the Agent API call models from providers other than Perplexity?

Yes — it's described as model-agnostic, providing unified access across multiple frontier model providers with automatic fallback, which is a genuinely new capability the old Sonar API didn't have.

What's the "xhigh" preset for?

It sits above the Deep Research equivalent (high), intended for open-ended agentic work — dozens of searches, reading across hundreds of documents, and iterative refinement, beyond what a single deep-research pass was designed to handle.

The Bottom Line

Next in this series: with Sonar's four tiers on their way to becoming Agent API presets, here's how to actually decide which one a given task needs.

Read part five: Choosing the Right Perplexity Model. Explore dnotifier.com.