Claude Duet: AI now wants to follow your work, even when you close the chat

There is a part of work that almost never appears on a to-do list: remembering the list itself. Checking whether that reply arrived, finding out whether someone else now owns an outstanding task, reopening the spreadsheet you still need to finish. You stay busy all day and eventually realize that a good chunk of it went into finding the point where you left off.

Anyone working on several fronts knows the feeling. Your browser becomes a collection of unfinished business. Every tab promises, “you'll come back to this later.” Some have been around long enough to start paying rent.

That is why Claude Duet caught my attention. I see an interesting discussion about continuity: how can a tool follow work over time and bring back what actually requires a person's decision?

Anthropic announced Claude Duet on October 21, 2026, as an experimental preview with a waitlist, initially for Pro and Max subscribers in the United States. That announcement therefore does not mean general availability in Brazil. [1]

My analysis is based on public documentation. I am not reporting a personal test of Duet. I want to examine the proposal from the perspective of someone who builds integrations and needs automation to fit everyday work.

What changes when the conversation carries on

Duet uses a cloud computer and Claude account resources, including memory and connected apps, to continue tasks and notify the user when their input is needed. [2]

What interests me is the interval between receiving a request and closing it. Imagine someone preparing a business proposal. They have some of the information, are waiting for confirmation, and need a document. A well-written summary helps, but the work remains open after that summary is ready.

I would assess this kind of assistant by its ability to follow those dependencies. Did it identify what was missing? Did it make clear who needs to act? Did it distinguish the received document from the approved version? Could it pick up the subject again without making the person tell the whole story?

That would be a useful advance: reducing the effort of reconstructing context every time you return to something. It is also a demanding expectation. An assistant that keeps a tidy list but loses the reason behind each outstanding item ends up handing the organizing work back to the user.

An integration developer's perspective

My work with Oombe involves marketplace automation and requirements concerning Mercado Livre, Shopee, listing publication and transfer, catalogs, compatibility information, and payments. That experience makes me pay close attention to what happens between a request and a verified result.

Think about a catalog change. There is the initial request, identification of the items, the applicable rule, processing, and verification. Depending on the case, an exception may still need a person's attention. Each stage carries information that must reach the next one.

When I look at agents that follow ongoing work, I see an interesting possibility for helping organize those outstanding items. The question I would ask is: “can you give me a verifiable view of what needs attention?”

Notice the requirement in the word verifiable. I would want to know where the information came from, which point in time it represents, and what still needs confirmation. Persuasive writing without those elements would give me another investigation to perform.

This does not mean a native Duet integration with Oombe or Mercado Livre exists. The examples below are hypothetical workflows, conditional on authorized access, compatible tools, and testing. They explain what I would look for in a pilot.

Three situations where I would look for value

Bringing an operation's outstanding items together

I would start with something bounded: an authorized export of records, prepared for analysis, containing the data required for the task. The request would be to organize outstanding items by reason, indicate missing information, and produce a verification list.

Imagine records containing notes about incomplete entries, inconsistent information, and pending validation. A good analysis would preserve each item's identifier and point to the evidence used to group it. When information was insufficient, the expected result would be to flag that uncertainty.

I could then assess whether the organization helped me choose where to start. Identifying several records related to the same possible cause would be particularly useful, provided the hypothesis remained labeled as a hypothesis. The benefit would be easier investigation, without turning similar wording into a confirmed diagnosis.

Preparing a reply that someone can review

Another possible experiment would provide a request and an authorized set of information to prepare a reply. I would ask the draft to separate confirmed facts from points requiring verification and highlight any commitment involving a deadline.

That detail matters. “We are checking” and “it will be fixed tomorrow” create very different expectations. During review, I would need to identify quickly which statement has support and which requires my decision.

I would also assess whether the text answers the person's question. A draft can have impeccable grammar and still avoid the issue. In that case, polishing it has only made the review trickier. The pilot's goal would be a useful reply, with natural language and verifiable facts, before any authorized sending.

Returning to a subject without starting over

A third hypothesis would follow a small request through changing states: document requested, material received, review in progress, question sent back. I would define those states beforehand and ask for a summary of relevant changes.

The summary should say what changed since the previous review. Repeating everything every day can become tiring, particularly when the user must work out which line contains the news.

I would also ask for older outstanding items to remain visible until there is a reason to close them. A conversation going quiet does not automatically resolve the matter. Sometimes it just means everyone is waiting for someone else to reply.

Connecting apps is an engineering decision

Before any pilot, I would draw a small map: what information enters, through which route, who can see it, and what result should come out. That conversation is usually more useful than starting by asking how many apps the tool can connect.

For me, an integration must answer concrete questions. Does access allow reading, or changes too? Does the file contain enough information? Is there a stable identifier? How will we recognize that the analysis used an old version? Who checks the result?

If the pilot depends on exports, I would define their update frequency and format. If it depends on a connector, I would check which operations are actually available. If it involves navigating an interface, I would verify that route's conditions and limitations before assuming it fits the process.

The same care applies to automating a decision. I would start by keeping objective rules somewhere they can be checked: grouping criteria, priorities, and closing conditions. AI's contribution would be evaluated within that design.

This is translation between a need and a working process. Someone who knows the operation plays a central role in that conversation because they understand what each field means and which situations look alike on screen but need different treatment.

Useful memory needs up-to-date context

I would like an assistant to remember presentation preferences and the progress of requests. At the same time, I would treat changing rules as information requiring a date and review. Old guidance can still sound perfectly reasonable after it has stopped fitting the process.

In a pilot, I would therefore record where rules came from and when they should be checked again. I would also separate personal preferences, instructions for one task, and standing operating criteria. That distinction helps determine what should carry into the next job.

The documentation contains a concrete detail: disconnecting an app stops new access but does not automatically erase information already stored in memory; users can reset it. [3]

I would include that check when closing any experiment. Testing a tool also means understanding how to remove access and clear context that is no longer relevant.

Approval should help someone make a decision

Anthropic describes approvals for significant actions, a check outside the model, and safeguards that remain subject to errors. [3]

In my pilot design, useful approval would show the exact proposed action, its destination, and the information used. I would need to understand the consequence before confirming, without reconstructing the entire job.

If a message is ready to send, I want to review its recipient and text. If the proposal is to update a record, I want to compare its current state with the suggested change. If information is missing, I would prefer the specific question that lets the work proceed.

I would also define which decisions need to reach me. When everything demands attention, it becomes difficult to recognize what really matters. The routine should protect the reviewer's time and preserve a real opportunity to say, “wait, this needs to change.”

How I would organize a first pilot

I would choose one process, with a clear beginning, ending, and owner. Bringing together outstanding items from an export would be a good initial candidate. “Organize the whole company” would make the result impossible to assess and give the tool too much room to interpret the objective.

Before starting, I would run through the usual method once and note the work required: finding files, checking fields, grouping items, reviewing conclusions, and preparing the next action. That would establish a concrete reference.

Then I would prepare the test data and define the expected result. For example: a list of outstanding items with an identifier, reason, evidence, suggested next action, and uncertainty flag. If a case requires interpretation, I would explicitly ask the tool to present alternatives instead of silently choosing.

The first review would ask two questions: can I trace every conclusion back to the supplied material? Is the result ready for the agreed use? A report can be correct and still require so much formatting work that nearly the entire task remains with the person.

In the next round, I would add a small update to the same process. That would test continuity: did the assistant notice the change, preserve what remained outstanding, and avoid repeating work that was already resolved?

Finally, I would document the exceptions found and decide whether to expand the experiment. Expansion should follow what has been demonstrated. If the tool organized files well, the next step might be another organizing task. Changing prices or committing to deadlines requires its own assessment.

The clock should count review time too

I would measure the total time the person spends reaching a usable result. That includes preparing material, giving instructions, checking, correcting, and following up. The tool's processing time would be recorded separately.

I would also observe the quality of interruptions. Which alerts helped someone act? Which were unnecessary? Did an important outstanding issue surface only when the person investigated manually again? The experience needs to reduce the burden of following up as well as produce documents.

The product has concrete limits: background work consumes the plan's shared allowance, checks happen at intervals, and the tool may misinterpret urgency. [4]

I would account for those conditions in planning. A process requiring an immediate response needs a mechanism suited to that deadline. A periodic review of outstanding items may accommodate a different cadence. That choice depends on the work and must be clear before anyone begins to rely on the follow-up.

Operational knowledge takes on another role

What excites me most about this discussion is turning experience into usable guidance. Someone who knows the routine can explain why a particular item deserves priority, what evidence confirms a conclusion, and when an exception needs escalation.

That knowledge helps design the pilot, assess results, and improve automation. For developers and integrators, I see room to build those transitions with clear criteria, well-defined data, and results that people can verify.

I will follow Claude Duet from that perspective: how much useful organization and continuity can it take on within the conditions it offers?

For me, a good result would be ending the day with fewer subjects abandoned between tabs, messages, and files, knowing what has been done and what still needs me. That would already be a welcome help. And perhaps I could close some of those tabs that are almost ready to sign a lease.

Sources

[1] Anthropic. Introducing Claude Duet. Published October 21, 2026.

[2] Anthropic. Claude Duet: official product page.

[3] Anthropic. Claude Duet Safety, Privacy, and Security. Published October 23, 2026.

[4] Claude Help Center. Get started with Claude Duet.

Documentation consulted October 25, 2026. Features and conditions of the experimental preview may change.