Computer Use Workflows: Real Automation Recipes

Writing a Computer-Use Prompt That Works

Computer use fails predictably when a prompt is vague. The model starts a task, runs into an ambiguous state — a form with more fields than expected, a login screen you didn't anticipate, a confirmation dialog requiring a decision — and either guesses wrong or pauses and asks. Both outcomes cost you time.

Three elements separate a working computer-use prompt from one that fails partway through:

Start state. Describe what is currently on screen or open. Not just "go to Salesforce" — specify whether you are already logged in, which view is active, and what data is already in context. The model's first action is drawn from this description; if the start state is wrong, the sequence derails from step one.

Success criteria. State explicitly what done looks like. "Update the deal stage" is a goal. "Update the deal stage to Closed Won and save the record — success is when the Stage field shows Closed Won and the page has returned to the record view" is a success criterion. The model needs a way to verify completion from what it can see; without that, it may stop early or continue past the finish line.

Scope limits. Tell the model what not to touch. Computer use operates with keyboard and mouse access to everything on screen. If you're updating one record and three others match the same search, the model needs to know to stop after the first. If you want it to stay within a specific domain, say so explicitly.

A comparison of a weak prompt versus a strong prompt across these three elements:

The strong prompts are longer, but the length is doing work. Each sentence eliminates a decision the model would otherwise have to guess at.

Workflow 1: Multi-Page Form Filling

Multi-page form filling is the task category where computer use delivers the most consistent value. Forms are deterministic: each field has an expected value, required fields are usually labeled, and submission produces a clear confirmation state the model can read.

Scenario. You have a vendor onboarding portal with seven pages of fields. The data is in a spreadsheet. Filling it manually takes 45 minutes of purely mechanical work.

Prompt template.

What to watch for. File upload fields require a local file the model can access — these are the most common failure point on multi-page forms. Conditional fields that appear or disappear based on earlier choices can cause the model to miss required inputs. Date pickers with non-standard formats (MM/DD/YYYY vs YYYY-MM-DD) are a common source of validation errors that look like successful saves.

Recovery instruction to add for file uploads. "If you encounter a page that requires a file upload, skip that section, note it in your report, and continue to the next section."

Workflow 2: CRM Record Updates

CRM updates illustrate what computer use can do without any integration setup. A CRM like Salesforce or HubSpot works with every field the browser can see — including custom fields that no official API exposes. Astra can update records the API cannot reach.

Scenario. Twenty accounts closed last week. You need to set a renewal date, update the deal stage, and log a note on each record. Doing it manually takes 90 minutes. With computer use, it runs unattended in roughly 40 minutes while you focus on other work.

Prompt template.

Scoping to avoid touching wrong records. The most critical scope constraint for CRM work is "one record at a time, return to home screen after each save." Without this instruction, the model may navigate to a related record while exploring and attempt updates there. Returning to a known starting state before each new account keeps the sequence predictable and auditable.

If your CRM search returns multiple matching records, add: "If a search returns more than one result, stop and add that account to your report as ambiguous — do not select any result."

Workflow 3: Calendar Management

Calendar management is well-suited to computer use because the success criteria are concrete and the visual state is always readable: either the event exists with the right attendees and time, or it does not.

Scenario. You need to schedule a recurring weekly sync with five people across three time zones, check for conflicts on your own calendar, and send invites. The manual version involves timezone math and five separate invite compositions.

Prompt template.

Conflict resolution. Astra can read calendar availability from what it sees on screen — it cannot read attendees' full calendars unless those calendars are shared and visible to your account. The prompt above asks it to check your own calendar and note visible conflicts for attendees without blocking on them. This is the right design: let the model handle the mechanical scheduling, and let attendees decline or propose alternates through the normal invite workflow.

Handling calendar auth walls. Calendar tools require you to be already authenticated before computer use starts. The model cannot log in on your behalf — it has no access to your stored credentials. Before invoking computer use for any calendar task, open the app and verify you are signed in. If the task involves a shared calendar that requires a separate permission grant, complete that grant manually first.

Workflows 4 & 5: Web Research and Frontend QA

These two workflows use the browser as the primary interface, where Astra's visual grounding performs most reliably. Both produce structured output — a research summary or a defect list — rather than mutating a system. The model reads and reports rather than writing and saving, which lowers the risk of an unexpected side effect.

Web research prompt pattern.

The "sites in order" structure prevents the model from following links in unpredictable ways. The "do not create accounts" instruction prevents it from stalling at sign-up walls. Specifying where to save the output — a Google Doc, a local file — means the research is captured even if the session ends unexpectedly.

Frontend QA prompt pattern.

QA prompts work best when the checklist is explicit. "Check for defects" is too broad. A specific list of what to check — images, overflow, CTA labels, title matching — gives the model a consistent review process and produces comparable reports across sessions. The "do not click submit or delete" instruction is critical for staging environments where a click could mutate data.

Handling Partial Failures

A partial failure is what happens when Astra completes some steps of a multi-step task and then stops before finishing. The task ran, made changes, and left things in an intermediate state — not where they started, not where you wanted them to end up.

Partial failures are normal at a 72.6% task completion rate. Expecting them and designing for recovery is more useful than trying to eliminate them.

What a partial failure looks like. Astra pauses and shows a message describing where it stopped: "I updated 14 of 20 accounts. I could not find account 'Brightline Solutions' in the CRM search — the search returned no results. Here are the 6 accounts I did not update." That message is your checkpoint. It names the last completed state and the reason it stopped.

The checkpoint-resume pattern. Design prompts so that each sub-task ends in a verifiable state — a saved record, a confirmation page, a note added — before the next one begins. When the task stops partway, you know exactly which items were completed and which were not. Resume by giving Astra the remaining list explicitly:

When to resume vs restart. Resume when the completed items are in the correct state and you only need to finish the remaining ones. Restart when partial progress introduced errors — for example, a form was submitted with incorrect data, or records were updated with wrong values. Before resuming, scan Astra's activity log to confirm the completed items are actually correct. The activity log lists each action taken; compare the last few entries against your expected outcome before continuing.

Telling Astra where it left off. When resuming, state the completed count, the last successful item, and the starting point explicitly. The model does not remember the previous session — each new computer-use task starts fresh. The checkpoint lives in your message, not in its memory.

Recovery instruction to add to every multi-item prompt. Add this line to any prompt that processes multiple records: "After each item, write a one-line status in your activity log: item name — done / skipped / error. At the end, summarize how many were completed, how many were skipped, and the reason for each skip or error." This gives you a structured checkpoint you can use to resume from any stopping point.