Control your PC from a phone with an AI agent

Read guideView documentation

You are away from your desk and need to check a job, retrieve its report or restart a known task. A conversational agent is useful for these bounded operations. A reply saying “done” is insufficient: you need to know which operation happened and which file or service it affected.

Remote desktop or an agent?

Remote desktop fits open-ended interaction with a graphical interface. An agent fits repeatable tasks such as reading status, retrieving an allowed report or starting a predefined job. Your integration must implement those operations; Pacerelle does not install a universal PC remote control by itself.

Start with a read-only operation such as “daily export status.” Return its job ID, start time, state and report path. A process still existing does not prove progress; use an observable indicator such as a saved progress record or the latest output file.

Define the operation before requesting approval

For “restart the export,” specify the exact program, working directory, allowed arguments and expected output. Do not turn arbitrary message text into shell commands. Resolve paths before approval and enforce the allowed directory, including symbolic-link cases.

  • Action: run the installed export_daily task.
  • Resource: the named project and environment.
  • Parameters: the export date, without free-form commands or secrets.
  • Precondition: no equivalent job is already running.
  • Completion evidence: exit status, exported period, item count and report location.

This makes approval understandable on a small screen. “Allow the agent” is too broad to support a decision about a restart or file write.

Bind approval to execution

A confirmation button alone does not enforce permissions. The Pacerelle permission policy binds approval to the action, resource, parameters, user, conversation and session. Execute through run_authorized in Python or runAuthorized in JavaScript.

The once scope permits one attempt and is consumed before execution, even when it fails. The session scope permits the same operation within the authorized period; changed parameters are not covered. In-memory grants disappear on restart, so a new session requires fresh approval.

Report the actual state

Distinguish request received, permission granted, job started and result verified. Persist the job ID and progress before handing off long-running work. After a phone disconnection, recovery should inspect that state instead of launching the job again.

A timeout can mean the outcome is unknown. Query the target system before retrying. Where supported, use a request-bound idempotency key for external effects.

Test before leaving your desk

  • A read request returns the intended report and cannot access another directory.
  • Denial starts no job; expired or replayed approvals fail.
  • A repeated tap does not create a duplicate export.
  • Program errors produce a failure report instead of an assumed success.
  • After interruption, the agent finds the job or explicitly reports an unknown outcome.

Widgets present the decision; the production guide covers process continuity. A useful first remote control can be small: one reliable read and one well-defined action.

Build a controlled first action

Adapt the documented permission example to one specific resource.

Explore permissions

Recommended reading