# Capture something outside; have the computer prepare it

Connect phone capture to a working process on the person's computer, then return the usable result to their phone. Build it extremely well. They should be able to record something while out, ask for the preparation they want, and use the result without going home. Follow the [shared launch](../shared/launch.md).

Start with a real routine and the applications already serving it. A strong first path joins [voice capture](../native-phone/voice-capture.md), the [audio workshop](../ai-apps/audio-workshop.md), and a [persistent work queue](../background-services/batch-work-queue.md). Choose another medium when it better fits the person's purpose, preserving the same complete capture-to-result experience.

## Send material with an intention

Let the person record, photograph, or select material on the phone and choose what they want done. They might request a transcript with useful section headings, a short edit of selected interview passages, or a prepared image for a report.

Keep the original capture, their instruction, and the relevant project together. Provide a convenient way to use a saved processing routine and change it for this item. Show the destination and any meaningful processing cost before submitting the work.

Retain material on the phone while the connection is unavailable. Make the distinction between a saved capture, a transfer in progress, and a job accepted by the computer easy to understand. Recognize an already-received submission when the phone retries.

## Run the work where the capability lives

Use Tailscale or an appropriate existing private connection to reach the person's computer. Set up the receiving operation and processor as part of the existing application or service. Preserve the queue's ordinary controls and access from the desktop.

Where the work needs interpretation, give the existing coding agent the captured material, instruction, and proper application tools. Reuse its established access, selecting additional model capabilities deliberately where needed. A transcript, an audio edit, and a visual judgment may call for different capabilities.

Let processing continue after the phone disconnects. Keep the workload and its results recoverable through an interruption at the computer. Report progress from the actual job, including a meaningful explanation when an item needs attention.

## Return a result the person can use

Notify the person when the prepared result is ready and open the relevant item from that notification. Let them read the transcript, audition the audio, or inspect the image directly on the phone. Make it easy to keep a local copy or share the intended output.

Preserve the relationship between the result and its original capture. Let the person compare versions, correct the instruction, and ask for another pass while retaining useful earlier output. Their feedback should reach the same project and processing context.

Keep job control available from the phone where it helps: inspect waiting work, change an item that has not started, or stop further processing. Show what those actions actually affected, including work already completed.

## Complete the remote processing experience

Deliver the connection, transfer, workload, notification, and return path. Explain what must stay running and what remains available when either device is offline. Apply the shared launch's ownership guidance to originals, processing instructions, and outputs together.

Capture a sample away from the computer's local network, submit a useful preparation, put the phone away, and return to the result. Ask for a refinement from the phone and inspect the changed output. Judge the actual prepared material as well as the connection.

Teach the person how a phone can use capabilities running elsewhere. Capture, submission, processing, and receipt are separate events; a good connected system makes them understandable while removing the manual transfers between them.