“Local-first” agents need an escalation ledger

Perplexity describes Portable Computer as an on-device version of Perplexity Computer. Its orchestrator, planner, tool router, scheduler, task queue, and search index run locally, while content that must leave the device for cloud execution requires user authorization. Perplexity’s announcement

That makes the approval screen an architectural boundary, not a minor interface detail. “Local-first” describes how work is routed; it does not establish that every step in a task remains on the device.

For platform teams, the practical problem begins after the prompt disappears. A reviewer may remember approving cloud help without being able to connect that decision to the workflow step, disclosed data, remote destination, or returned output. An escalation ledger would preserve those connections without becoming a second store of sensitive content.

Define one escalation event

Tom’s Guide describes Portable Computer as a packaged stack containing a model, inference engine, tools, connectors, and sandbox. It reports that the system determines when a task may need cloud help and asks the user to approve the handoff. Tom’s Guide’s report

The ledger is an SGL design proposal, not a documented Portable Computer feature. Its unit is one proposed local-to-cloud transaction. The entry begins when the system requests authorization and closes when the request is denied, cancelled, fails, or returns a result.

At minimum, that entry should answer:

• Which workflow step requested the handoff, and why local execution was considered insufficient.
• Which data categories, attachments, tool outputs, conversation segments, or generated instructions were selected for transmission.
• Which service, endpoint, model, or connector was the destination.
• Who approved the request, when, and against which displayed payload summary.
• What type of remote result entered local state and could influence later planning or tool use.
• Whether the transaction was approved, denied, cancelled, failed, or completed.
• If the destination is separately priced, which operation and pricing identifier apply.

The supplied sources do not establish that Portable Computer’s cloud assistance creates an external charge or exposes billing data. Cost metadata therefore belongs only as a conditional design field for deployments where a separately priced service is known to be involved.

A generic notation such as “sent context to cloud” is too coarse. It hides both the kind of data selected and the destination that received it. The returned result needs equal attention because the boundary crossing does not end when data leaves the device.

Preserve evidence without copying the payload

A useful ledger does not need to duplicate every attachment, conversation segment, instruction, or returned output. That approach would create a concentrated record of sensitive material.

Instead, the entry should retain a minimized payload manifest: data categories, destination, byte count, timestamps, applicable redactions, and an integrity-protected digest or controlled reference when later verification is necessary. Returned content can be represented the same way. Raw content should remain in its system of record unless an explicit investigation or policy requires protected retention.

Access to ledger entries should be role-scoped and reviewable. Retention should be time-bounded by data class and operating need. Redaction rules should apply before persistence, and integrity controls should make unauthorized changes detectable. If a referenced payload expires or is deleted, the ledger should record that state rather than silently preserving another copy.

These controls change the buyer’s question from “Can we retain the exact data?” to “Can we verify what crossed the boundary without creating an unnecessary replica?”

Use the entry across separate reviews

An approval interface supports a decision in the moment. Security review, workflow analysis, and conditional cost review happen later and ask different questions.

A security reviewer needs to compare the displayed summary with the outbound payload manifest and inspect whether minimization and redaction rules ran. A platform engineer needs to place the handoff inside the workflow and determine how the remote result affected subsequent local work. Where a deployment uses a separately priced destination, a cost owner may need to associate that known operation with its pricing record.

One entry can support those views without collapsing them into a single concern. A denied request records that a cloud route was proposed while distinguishing the proposal from an executed transmission. A completed request connects authorization to both sides of the boundary: what was disclosed as leaving and what kind of result returned.

This proposal does not assume that Portable Computer currently exposes an audit interface with these states, fields, or protections. It derives an operating requirement from the documented combination of local execution, proposed cloud assistance, and user approval.

Keep deployment context attached

Perplexity describes the first release as Linux-only on NVIDIA DGX Spark and says Windows support is forthcoming. Perplexity’s announcement Tom’s Guide reports that the initial Linux release requires compatible NVIDIA hardware with at least 24GB of VRAM. Tom’s Guide’s report

These are deployment constraints, not evidence of performance, availability, or behavior across every workload. An observation from the initial supported environment should not silently become a claim about a different operating system, GPU profile, local model, or software release.

The ledger entry should therefore reference the host configuration rather than expand into a separate configuration scorecard. Operating system, GPU, VRAM, local model, and software version provide context for interpreting why a handoff was proposed.

Inspect what remains after approval

A buyer evaluating a hybrid agent platform should ask to see the connection between the authorization presented to a user and the evidence retained for later review. Can the organization identify the transmitted data categories and verify the payload under controlled access when necessary? Can it name the destination? Can it distinguish a proposed escalation from one that executed? Can it determine what kind of cloud output re-entered local state? Can it show that ledger access, redaction, retention, and integrity are governed?

An escalation ledger does not certify an entire platform as local-first. It gives operators a bounded record of each exception while limiting the new security exposure that record creates. That combination belongs in the broader build review whenever local execution and remote assistance share the same task.