Instinct: from a text or call to a confirmed task

Instinct offers a familiar way to ask for help: text or call a personal assistant, then let it work through the task. In its September 28 announcement, the company said it had raised $1 billion at a $10 billion valuation from Sequoia, Benchmark and Coatue. The release still described the product as early access and promoted phone calls, bookings and coordination between users’ assistants. Those are company claims, rather than results independently tested for this guide. Instinct’s announcement

The interesting change is what happens after the conversation. An answer can stay in a chat; a booking or message changes something elsewhere. For an engineer evaluating assistants, that makes a small personal task useful for understanding a larger reliability problem: how does the workflow connect the instruction, the permitted action and the result that actually exists?

The conversation starts work on another service

Instinct’s public description says it connects to applications and devices, can use a phone and computer, and draws on context such as email and messaging. Its examples include following up on dropped threads, arranging transport and booking a handyman. That describes a service intended to carry work beyond an immediate reply. It does not establish the success rate of any particular task.

For a booking, the useful work could include finding a provider, comparing availability, asking a question and returning the offered time. Each step reduces something the person would otherwise have to do. The final commitment is a different step because it can create a charge, disclose contact details or reserve a time the person can no longer use.

The terms authorize responsive actions through connected services, including commitments binding on the user. They also put responsibility for verifying actions on the user and acknowledge that action records may be inaccurate. Read that as the service relationship, rather than a promise that a confirmation prompt will appear at every consequential step.

Give a personal booking a result you can inspect

Consider a hypothetical personal task: an engineer wants a handyman appointment at home after an on-call shift ends. The person has one acceptable afternoon, wants a quote before committing, and has not authorized a deposit. None of this is an Instinct test or a reported customer experience.

“Find someone to fix the door” leaves several decisions open. A more useful assignment names the job, area, acceptable time and the information the provider may receive, then asks for available options and the full proposed charge before booking. That gives the assistant useful preparation to finish while leaving a clear decision for the person.

The distinction matters when the provider offers something slightly different. A morning slot does not satisfy an afternoon request. A refundable deposit still needs permission if the task excluded deposits. Knowing the person’s preferences can help the assistant notice these differences; it cannot make a changed offer identical to the one authorized.

When the person chooses an option, the permission should describe that actual booking: the provider, time, total charge and relevant cancellation conditions. This applies the bounded-action approach in our production-agent guide. An instruction can make the intended limit clear, but it does not demonstrate that the product or connected account enforces that limit.

Completion then needs evidence from the provider: a booking reference or confirmation with the right job, date and price. A calendar entry made by the assistant can be convenient, yet it cannot by itself show that the provider accepted the appointment. If the provider’s confirmation disagrees with the assistant’s report, the booking remains unresolved.

A missing reply can follow a completed action

Now suppose the booking attempt begins and the assistant stops responding before reporting a result. The appointment might exist, or the provider might never have accepted it. Asking the assistant to book again immediately can turn one unclear appointment into two.

The next useful action is to establish what the provider recorded. Check its booking page or confirmation, or ask it to locate the attempted appointment. If the result remains unclear, keep the original attempt unresolved and stop another booking until a person can reconcile it. A second confirmation request creates more activity without settling the first.

Phone-mediated work makes this especially revealing. A conversation with a provider may not produce a machine-readable operation identifier that another system can look up. In that situation, the person may have to resolve the uncertainty directly. The convenience of the conversational interface does not remove the cost of recovering an ambiguous external action.

This also changes which tasks are attractive to delegate. Finding options leaves room for correction before a commitment. Sending a message or accepting a booking can create effects that a later correction cannot erase. Choose the stopping point according to that consequence, rather than assume every task has a usable undo step.

What an incident-notification worker can learn from the booking

The same problem appears in an illustrative SRE workflow built by a team: an assistant drafts a maintenance notification, a reviewer approves its recipients and window, and a worker submits it to a messaging service. This is a system-design example, not a claim that Instinct supports an enterprise notification system.

The worker needs to retain the approved message and the state of its submission. If the response disappears after submission, “delivery unknown” must remain distinct from “not sent.” When the destination provides an operation reference or delivery record, use it to reconcile the attempt before sending again. When it cannot settle the result, give the unresolved notification to the person responsible for the maintenance communication.

Delivery is still only one result. If that message announces recovery, the service’s own recovery checks must support the statement. In this hypothetical queued-work service, new requests may complete while earlier jobs remain delayed. A delivered message establishes communication; it cannot establish that the backlog recovered. The incident-response guide explains how to carry those different outcomes into a handoff.

This gives the team a concrete design decision. Keep preparation, permission, submission, delivery evidence and service evidence distinguishable, so a lost response changes the next step to investigation rather than another send. The assistant’s fluent report can help explain the record, while the record remains capable of contradicting it.

The data route matters before connecting accounts

Instinct’s privacy policy, revised August 26, distinguishes information received through Google Workspace APIs from other inputs. It excludes that API information from model evaluation, fine-tuning, training and improvement. Other information can be used for training; opt-out is prospective, retains a safety-review exception, and does not undo earlier training or cover every service improvement.

That makes the input route consequential. Pasting a document into a message should not be assumed to acquire the protection stated for data received through Workspace APIs. For a task that only needs a time and a small description of a repair, supplying a whole inbox introduces information unrelated to the result.

Disconnecting also differs from deletion: the terms’ connected-services section says indexed inputs may remain in use until deletion is requested. Ending fresh access therefore leaves a separate cleanup decision about previously collected information.

For workplace use, there is an additional boundary. Although the terms’ preamble discusses entity use, section 6 grants personal use only. These pages do not establish permission for an employer’s operational accounts or records; resolve permitted use before connecting them. The personal example above avoids making an enterprise deployment recommendation from a consumer product description.

For a first personal task, a quote with the available appointment time offers a useful stopping point. It lets the assistant do concrete work and leaves the person a specific offer to review. When moving on to a booking, look for the provider’s accepted result, and keep an interrupted attempt open until that result is known. That is also the part worth carrying into an operational agent: finish the work by establishing what changed at the destination and what happened to the service that change was meant to help.