Instinct: from a text or call to a confirmed task

Instinct’s promise is that you can hand over a piece of life administration in the same way you would ask another person for help: send a message or make a call, and let the assistant follow up through other services. Its announced examples include arranging transport, finding a handyman and coordinating with another person’s assistant. The appeal is the work between the request and the result: searching, asking, comparing and following through.

In its September 28 announcement, Instinct described early access, phone calls, bookings and coordination between users’ assistants. These are company claims, not results independently tested for this guide. Instinct’s announcement

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.

A booking makes the promise concrete. Finding providers produces options. Comparing times finds a fit. Contacting a provider turns the shortlist into an offer, and accepting it can reserve a slot, share contact details or create a charge. The conversation feels like one request, but those steps cross different lines. Useful delegation does the preparatory work without losing sight of the commitment.

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 provider’s reply is where the original request gets tested. A morning appointment is not the afternoon requested. A refundable deposit is still a deposit if none was authorized. Preferences help the assistant notice those differences; they do not turn a changed offer into the same offer. The person should get a specific choice back, not discover the compromise after booking.

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.

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. Repeating the booking request does not establish whether the original appointment exists. It may instead give the provider two requests to fulfill.

A dropped phone call is an easy way to see the recovery problem. The provider may already have put the appointment in its calendar while the assistant has no confirmation to report. Someone has to ask what was recorded before booking again. Count that reconstruction as part of delegation’s cost: an easy opening conversation can leave a difficult closing question.

That is why finding options and accepting an offer deserve different stopping points. A wrong shortlist can usually be corrected before anyone commits. A sent message has already reached its recipient, and a booking may already occupy the only available slot. Start with the part of the task whose result is easy to inspect, then extend the assignment only when the destination can tell you what actually happened.

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 can summarize those records, but a delivery status of unknown must remain unknown even if the summary sounds confident.

For the first task, a quote with an available time is a useful finish line. The assistant has done real searching and coordination, and the person has an offer they can judge. If the task proceeds to a booking, finish by finding what the provider accepted. An interrupted attempt stays open until that answer is known. That is the transferable lesson for an operational agent too: the closing message should follow the result at the destination.