Perplexity this week released Portable Computer, a local-first variant of its Computer agent that runs on an Nvidia DGX Spark workstation, with the hardware alone priced from $4,700. But the architectural decision underneath the product launch may matter more than the cost: while most platforms building agents pursue reliability by adding intelligence—typically through a larger orchestrator model, a planner model, or a critic model reviewing the work—Perplexity divided the two tasks instead of layering them. Probabilistic reasoning suggests the next step, and deterministic software determines whether to carry it out. The loop controller is code, not a model, and the company uses the term "orchestrator" to describe the runtime controller rather than the planning model.

Perplexity held the base model and hardware constant, running Qwen3.8-27B on the same DGX Spark across three different agent stacks. On the company's internal Local Knowledge Work Bench, a held-out collection of 53 tasks, Computer achieved 82.6% accuracy. Pi reached 77.6%, and Hermes hit 74%. On ParseBench-100, a subset addressing charts, layouts, tables, and formatting, the performance spread widened substantially: Computer logged 65.1%, while Hermes recorded 34.6% and Pi managed 13.9%. Since the underlying weights stayed the same, the difference measures the system surrounding the model rather than a superior model. Post-training still mattered—Perplexity fine-tuned Qwen into PPLX 27B and reported 85.4%, exceeding its own base-model figure.

The company says the harness consumed most of the engineering effort, according to Nate Kupp, Perplexity's vice president of Computer Enterprise and Infrastructure. That harness covers prompts, tool schemas, context management, verification hooks, and document processing, with orchestration code forming one piece of the architecture. The sandbox serves as the security perimeter, not the determinism itself—Perplexity says it limits processes, filesystem paths, and network access, and if the sandbox can't be used, the harness shuts down before executing any tool call. The report states the critical difference isn't between model orchestration and code orchestration, but whether permission is enforced by something other than asking a model in plain English to comply.

Deterministic code is useful because it makes policy straightforward to review and helps the system fail safely, but deterministic code can still introduce a vulnerability or reliably execute an allowed error. The sandbox forms the boundary where the platform's engineering becomes most visible—and for companies evaluating local agents, that's the component to examine closely. The same discipline governs how context gets allocated: Qwen3.8-27B advertises a 260,000-token context window but starts to falter past 100,000 tokens, so the harness keeps the core prompt and toolset compact and loads skills as needed. Deterministic execution can't save reasoning that surpasses the local model's capacity—on Terminal Bench 2.1, Perplexity logged 59.6% running locally, but letting the local agent consult Claude Opus 5 lifted that to 73.0%, compared with 82.4% when Opus 5 operated alone. All of this remains vendor-reported data on a benchmark the company hasn't yet released as open source. For enterprises weighing local agents, the layer that grants and denies authority deserves the closest scrutiny, because that's where the platform's engineering shows up most clearly. The architectural split between probabilistic suggestion and deterministic enforcement may redefine how control and accountability get distributed in production agent systems, and whether trust hinges on transparency or merely on better prompts.