Claude Duet and proactive AI agents: what changes for SMEs

Proactive AI agents make sense for SMEs when they help identify a defined piece of work and produce verifiable results. The choice between a packaged assistant and a custom workflow depends on variability, urgency, repeatability and permissions. Claude Duet brings this question to the table: which part of the work do you want to delegate, and who checks the consequences?

Anthropic presents Duet as a proactive agent for professionals and small businesses, requiring approval for messages, payments, signatures and deletions. Official announcement. As of 22 October 2026, the preview is limited to the United States, for Pro/Max subscribers by invitation. Documented availability. This is not a guide to activation in Italy; the following method helps design a business experiment using tools that are actually available and appropriate.

What changes when the assistant proposes the next step?

With a traditional request, a person decides when to open the tool and what to ask. Designing a proactive agent also means establishing which signals deserve attention. The question becomes "under what conditions should it prepare something for me?" This changes how work is organised before it changes how text is produced.

For a small business, this may be useful when information arrives in different places and the owner has to reconstruct the context each time. The project might gather missing points before a meeting or prepare a list of unresolved decisions. These are objectives to test, not benefits to attribute automatically to Duet or any other service.

The first distinction is between flagging, preparing and deciding. An alert can identify an incomplete request; a proposal can gather the questions to ask; sending requires a separate step in the process. If these levels blur, it becomes hard to tell which result you are assessing. The guide to Claude Duet covers the product; here, the choice concerns the type of business work.

How do you choose between a packaged assistant and a custom workflow?

The following matrix is a Giallo proposal to guide the assessment. It is not a product ranking and does not assign specific capabilities to a vendor. Read it row by row: if the indicators point in different directions, the problem probably contains two assignments that should be separated.

The right-hand column does not mean you should start developing immediately. First check whether improving a procedure, using deterministic automation or configuring an existing tool is enough. A language model adds value when part of the work requires interpretation; it is unnecessary for moving a field whose meaning is already unambiguous.

Do not add up the rows like quiz points. A single essential requirement can change the decision. If a process requires separation of roles and the technical proposal does not support it, four favourable answers do not make up for that gap. The guide to AI Agents for Companies helps turn the idea into an operational scope.

Why should urgency be assessed before convenience?

"It alerts me when needed" sounds like a simple requirement, but it hides a deadline, a recipient and a consequence. Ask what happens if the alert arrives late or never arrives. If the work can wait for the responsible person's review, you can experiment with internal preparation. If the omission causes tangible harm, a separate oversight process is needed.

Do not infer response times or continuity from a successful demonstration. A test in which a signal is recognised demonstrates that case; it does not establish a service level. The pilot should record delays and omissions; operational needs must remain covered by the agreed process while you gather this evidence.

One example of a design boundary is the difference between preparing talking points for a sales call and monitoring a critical deadline. The first result can be reread; the second requires someone to detect a missing result too. Before choosing an assistant, specify who checks for an absent alert and what alternative process they use.

When does varied work favour personal assistance?

An owner may move from a quotation to a meeting, then to a team request. These activities share the person's context, but not necessarily a single sequence. Forcing them into a detailed procedure risks creating more maintenance than value. In this case, consider assistance that prepares material the responsible person can readily assess.

Hypothetical scenario one: a small service company organises its week. This is an invented example, not a client or a test of Duet. The owner wants a brief for each meeting: objective, available sources and open questions. Meetings cover different subjects, but the person can immediately recognise whether the preparation is relevant.

The first experiment uses sanitised documents and produces internal briefs. It does not assume that the system can change appointments or contact anyone. The review compares each brief with the agenda: is an essential topic missing? Does a question have a source? Does an assumption look like a fact? The guide to Gmail and Google Calendar with Claude Duet explores this type of design in more detail.

When does repetition justify a defined process?

When work passes between several people, individual memory becomes a weak point in the process. You need to know which request arrived, which data is missing, who can complete it and when it moves to the next stage. An explicit procedure can make these steps checkable even when the model changes or a person is absent.

Hypothetical scenario two: a distributor collects quotation requests. This is also an invented example. Each request must contain the item, quantity and business contact details. The pilot aims to prepare an internal brief and flag missing fields, leaving the salesperson to check terms and availability.

The workflow can separate field extraction, completeness checks and sales review. An ambiguous request enters an identifiable queue rather than being completed with assumptions. Rules can handle the unambiguous parts; the model is assessed where it interprets free text. Choosing a custom workflow depends on these requirements, rather than a desire for a more impressive agent.

Before building, check whether the current business system already offers required fields and assignments. You may find that the main gap is orderly data collection. The project must justify what AI adds to the available procedure, including the work needed to maintain rules, integrations and sources.

How should permissions and responsibilities inform the choice?

List the people involved before the tools: who requests the work, who owns the source, who reviews the result and who decides the action. If these are different people, the proposal must respect those boundaries. Connecting one person's account to run a team-wide process can conceal responsibilities and dependencies that the pilot should reveal.

For each step, specify the minimum information required too. A request classifier does not necessarily need the customer's entire history; the reviewer may need an additional source. This separation reduces the amount of material each stage must handle and makes it possible to explain why access exists.

Do not treat instructions as evidence of technical isolation. If the project requires an access restriction, the solution must demonstrate how it enforces it. For a specific assessment, read about Claude Duet and privacy; to assign responsibilities, use a company AI policy. Process requirements come before choosing a connector.

How can you tell whether the result can actually be verified?

A useful output makes errors easy to find. An elegant summary without references may require rereading every source: the work shifts rather than becoming simpler. Request a format that shows confirmed information, uncertainties and missing material. Then measure how much reconstruction the reviewer needs to make a decision.

Include ordinary examples and difficult cases in the pilot: an incomplete message, a contradictory document, an outdated source and an out-of-scope request. You do not need large volumes to discover that an acceptance criterion is vague. If two responsible people judge the same result in opposite ways, clarify the rule before expanding the sample.

Keep a record of corrections that inform the decision, avoiding unnecessary copies of business information. Distinguish model errors from input errors and procedural defects. If the authoritative source is missing, changing models may solve nothing. The technical choice makes sense after identifying where the process breaks down.

Open the brief for choosing your first pilot

• Problem: which work do we want to make more controllable?
• Input: which approved sources are strictly necessary?
• Output: which internal result should the responsible person receive?
• Boundaries: which decisions and actions remain excluded?
• Verification: which errors and omissions must the sample reveal?
• Management: who reviews results and detects missing ones?
• Stopping: which problem would make us suspend or redesign the trial?
• Decision: which evidence justifies the next step?

Which figures should you collect before estimating ROI?

Start with the current work: describe a sample of assignments and the required result. Observe preparation, source searches, review and corrections. When comparing this with the trial, include the time spent checking the assistant. Counting only text generation would exclude a necessary part of the process.

Record quality and usefulness alongside time. A quick brief with a critical omission is not equivalent to one accepted by the responsible person. Avoid percentages built on impressions and state which examples support the assessment. If the sample is limited, the conclusion must remain limited to that work and those conditions.

The pilot's outcome might be "use the system to prepare drafts", "change the input" or "keep the current procedure". These are valid operational decisions when supported by evidence. Moving to a financial estimate also requires accounting for maintenance, oversight and exception handling, without attributing benefits before observing them.

Who maintains the process after the demonstration ends?

Before expanding the pilot, assign an owner to the sources and another to the rules. An updated price list, a new contact or a different procedure can change the expected result. If nobody records these changes, the configuration that worked on the initial sample becomes difficult to interpret. The cost of this management is part of the choice.

Define a simple path for reporting errors: the example concerned, the result obtained, the correction needed and the responsible person's decision. Do not turn every correction into a new permanent instruction. First ask whether it concerns an isolated case, an incorrect source or a general rule; otherwise, the process accumulates contradictory exceptions.

The ability to stop also matters in the assessment. The team must know how to continue working when a result is missing or needs review. A clear alternative procedure makes it easier to experiment within a limited scope, because business activity does not depend on the demonstration's success. Continuing depends on the ability to maintain the process as well as the quality of an individual output.

What can you design today?

You can choose a process, collect sanitised examples and write acceptance criteria without waiting for a new product. To choose between Claude experiences, see the comparison of Duet, Cowork and Code. For a business project, the key is still to demonstrate that sources, responsibilities and results fit together.

Giallo can help you design a pilot for a concrete activity, selecting available tools and checking the requirements of your case. Our AI Agent Design process starts with what must happen before and after the result. Tell us about the process you want to test: bring a sanitised example and the decision that currently requires the most reconstruction.