Your roadmap may say add an agent, but the real decision is whether you are prepared to let software hold a task after the user leaves. A convincing response is easy to demonstrate. A dependable delegated workflow has to remember the user’s intent, work across tools, recognize which decisions belong to a person, recover from interruptions, and prove what it accomplished.

Anthropic’s direction across Claude Code and Duet makes that operating challenge unusually clear. The useful pattern for a product leader is not a particular chat interface. It is the combination of persistent execution, bounded authority, task-level quality gates, and a team that owns the complete path from intent to verified outcome.

The unit of value is moving from answers to completed work

A conversational product waits for a request, returns a response, and largely stops. An agentic product has a longer responsibility. It observes context, develops a plan, uses tools, checks the result, and decides whether to continue, pause, or ask for help. The product is no longer delivering an answer. It is accepting a bounded delegation.

Duet was introduced as a separate research-preview app that sends a morning brief, accepts text or voice instructions, and continues working on its own cloud computer after the user steps away. It carries over memory, skills, and connected apps from a Claude account. Anthropic also says it can work across more than 6,000 connectors and plugins. Those capabilities turn continuity, permissions, and background reliability into core product requirements rather than infrastructure details.

The division of labor is equally important. Duet can read, draft, and prepare work independently, while important decisions remain with the user and require confirmation before the agent acts on the user’s behalf. That distinction is the foundation of a useful agent: autonomy over preparation does not imply authority over commitment.

Claude Code exposes the same shift from a different direction. Meaghan Choi, Head of Design at Claude Code, describes autonomous AI colleagues, builder pods, quality gates, and an environment in which everyone ships. One side of the model changes what the product does for a customer. The other changes how the team builds and verifies that product.

This should change the first page of your product specification. Do not begin with a model, chat surface, or list of tools. Begin with a task contract:

• Trigger: What event or instruction starts the work?
• Outcome: What observable state means the job is complete?
• Context: Which accounts, records, conversations, and preferences may the agent use?
• Authority: What may it read, prepare, change, send, purchase, or delete?
• Evidence: What receipt, diff, test, or updated record proves that it succeeded?
• Interruption rule: Which ambiguity, risk, or failure must return the task to the user?

If you cannot write those six lines precisely, the workflow is not ready for background autonomy. Adding more tools will increase its reach without resolving what it is responsible for.

A dependable agent needs an operating stack, not just a model

Public product behavior does not reveal Anthropic’s internal architecture, but it does reveal the contract the system has to uphold. You can translate that contract into six operating layers for your own product.

• Work contract: Give the agent a defined objective, end state, time horizon, and reason to stop. A broad instruction such as manage my inbox invites activity without a defensible definition of success.
• Continuity: Preserve the task plan, completed steps, unresolved questions, relevant context, and current permissions across sessions. Memory is useful only when it is scoped, inspectable, and current.
• Capability: Give the agent the tools needed to finish the job, not every tool the organization can connect. Each additional connector introduces another permission surface, dependency, failure mode, and source of untrusted instructions.
• Authority: Express what the agent may do as policy. The policy should cover objects, accounts, recipients, data sensitivity, monetary exposure, time windows, and actions that always require confirmation.
• Verification: Require the agent to collect evidence that the intended state was reached. A successful API response is not necessarily a successful customer outcome.
• Resource control: Set limits for runtime, retries, tool calls, and consumption. Duet shares a subscriber’s plan limits but uses them differently from a conventional conversation, illustrating why background work needs visible budgets and stopping conditions.

These layers fail in recognizable ways. Without a work contract, the agent stays busy but does not finish. Without continuity, it repeats work or acts on stale assumptions. Without sufficient capability, it produces summaries instead of outcomes. Without an authority policy, it is either dangerous or constantly blocked. Without verification, it can sound certain while leaving the job incomplete. Without resource controls, a background task can consume an unpredictable amount of capacity before anyone notices.

The product manager’s job is to make those failure modes visible in the design. A polished conversational response can hide a broken workflow. A task trace cannot.

Put human approval at the commitment boundary

Approval should not be scattered across every tool call. That produces notification fatigue and teaches users to approve without reading. Put approval where reversible, private preparation becomes an external or difficult-to-reverse commitment.

A practical execution loop looks like this:

1. Observe: Read only the context permitted for this task.
2. Propose: Form a plan and identify assumptions, dependencies, and risky actions.
3. Prepare: Draft messages, assemble changes, calculate options, or stage updates without committing them.
4. Confirm: Ask the user to approve the decision, target, and consequences at the commitment boundary.
5. Execute: Perform the approved action with the narrowest available permission.
6. Report: Show what changed, provide evidence, and identify anything that remains unresolved.

Operating stage	Typical agent behavior	Required control
Observe	Read a permitted thread, record, calendar, or project state	Least-privilege access, data boundaries, and an access log
Prepare	Draft a message, create a proposed plan, or stage a record change	A private preview that does not create an external side effect
Commit	Send, publish, change access, spend money, delete data, or update a system of record	Explicit approval or a narrow standing authorization with clear constraints
Report and recover	Verify the result, retry safely, reverse a change, or escalate a failure	Receipts, idempotency protection, rollback where possible, and a human handoff

The confirmation screen should describe the proposed action in business language, not expose a raw tool call. Show the verb, destination, recipient or record, payload or before-and-after diff, expected side effects, and reversal path. If an approval expires or the underlying context changes, ask again. Consent to one state of the world should not silently authorize action in another.

Not every commitment needs a fresh prompt. A user can grant standing authority for a narrow, repeatable workflow, such as updating one type of internal record under defined conditions. But the authorization should name the objects, allowed fields, recipients, timing, financial limit where relevant, and exceptions that force escalation. The user also needs an obvious way to inspect and revoke it.

Duet lets users disconnect apps it can access. Your implementation must take that principle one step further operationally: revocation should affect work already in progress, not only future sessions. Test what happens when access disappears halfway through a task. The safe result is a clean pause with an accurate state report, not repeated retries or a partial commitment hidden behind a generic error.

Quality gates must evaluate the whole task

Model quality is necessary, but it is not the unit that matters most for a long-running agent. Background work can fail between model calls: a tool can time out, a record can change, a permission can be revoked, a retry can duplicate an action, or a message can contain an instruction that conflicts with the user’s goal.

Anthropic has been explicit that the early Duet preview may misread a thread or misjudge what is urgent. That is not a cosmetic limitation. In a proactive product, prioritization determines which work enters the user’s attention and which work continues in the background. A false sense of urgency can be as damaging to trust as an incorrect answer.

Measure the delegated job from trigger to verified result:

• Validated completion: Did the intended state actually change, and did independent evidence confirm it?
• Correction burden: How often did the user have to repair the output, restate the goal, or undo an action?
• Approval burden: How many prompts protected a meaningful decision, and how many were routine noise?
• Policy adherence: Did the agent remain inside its data, tool, recipient, and action boundaries? Treat an unauthorized commitment as a release-blocking failure, even if the final output looks correct.
• Context integrity: Did the agent use the right identity, thread, account, time frame, and latest state?
• Recovery integrity: After interruption or partial failure, did it resume without losing work or duplicating side effects?
• Resource efficiency: What did a verified outcome consume in model usage, tool calls, elapsed time, and human attention?

Your evaluation set should include more than successful examples. Add ambiguous requests, conflicting instructions, stale records, revoked permissions, unavailable tools, partial writes, duplicate retries, and adversarial content. Anthropic says Duet’s defenses against hidden instructions and prompt injection build on its browser-use work. That is a defense claim, not a reason to treat external content as trusted.

Prompt injection needs layered controls. Separate untrusted content from system instructions, keep permissions narrow, validate tool arguments, require confirmation for consequential actions, and preserve an audit trail. A model refusing a malicious instruction is useful. A system that prevents the model from having unnecessary authority is safer.

Release autonomy in stages. Begin in shadow mode, where the agent observes and proposes without changing anything. Move to private drafts, then to one bounded action with explicit confirmation, and only then to background execution under a standing policy. Each stage should have a corresponding quality gate: agreement with a human decision in shadow mode, output correctness in draft mode, policy compliance and receipts in action mode, and reliable pause, resume, and recovery behavior in background mode.

Do not promote the agent because its average output looks good. Promote it when the team understands its failure distribution, can detect unacceptable behavior, and can stop or recover a task without guessing what happened.

Builder pods should own task traces, not isolated features

An agent crosses product, design, engineering, domain policy, data access, and operations in a single run. A conventional handoff chain fragments responsibility at exactly the points where failures emerge. A builder pod should own one delegated workflow from trigger through evidence of completion.

Assign decision rights rather than insisting on a particular set of job titles:

• Outcome owner: Defines the customer job, completion state, tradeoffs, and expansion criteria.
• Interaction and consent owner: Designs how intent, plans, uncertainty, approvals, progress, and failures are communicated.
• Runtime and tool owner: Owns execution state, connectors, retries, idempotency, observability, and recovery.
• Evaluation and policy owner: Maintains the failure taxonomy, evaluation cases, permission rules, and release gates.
• Domain reviewer: Determines whether the result is correct and appropriate in the business context, not merely valid at the API layer.

Those responsibilities do not require five separate people. They do require named ownership. If every decision belongs to the pod collectively, consequential failures will eventually belong to nobody.

The pod’s central artifact should be a task trace. It records the initiating intent, context selected, plan, tool calls, policy decisions, approval state, intermediate results, final evidence, and user corrections. Review traces by failure class rather than watching polished demonstrations. Each newly discovered failure should become an evaluation case before the team changes the prompt, tool, policy, or workflow.

This is where the idea that everyone ships needs a boundary. Prompts, connector definitions, approval copy, evaluation cases, and permission policies are all production artifacts because each can change agent behavior. More people can contribute to them, but contribution rights should not equal release rights. A change that expands authority or weakens a quality gate deserves stricter review than a change to presentation.

The pod can use four gates to make that distinction operational:

1. Task-definition gate: The trigger, outcome, evidence, and interruption rules are explicit.
2. Capability gate: The agent has enough context and tool access to complete the task without excessive permissions.
3. Autonomy gate: Risky actions have clear commitment boundaries, approval behavior, and revocation handling.
4. Expansion gate: Trace data and evaluations justify adding another action, connector, user segment, or background responsibility.

Key takeaways

• Define the completed job before choosing the model or interface.
• Treat persistent context, tool access, authority, verification, and resource limits as one operating system.
• Let the agent prepare independently, but put human control at the point where preparation becomes commitment.
• Measure verified outcomes, corrections, policy adherence, recovery, and resource use rather than response quality alone.
• Give a builder pod ownership of the entire task trace and convert every important failure into a lasting quality gate.

Start with one workflow that is already recurring, measurable, and expensive in coordination. Write its task contract and commitment boundary on one page. If you cannot specify what proves success, how authority is revoked, or what happens after a partial failure, keep the agent in shadow or draft mode.

Once the pod can inspect every run, stop it safely, explain its state, and recover without duplicate effects, the agent has earned more autonomy. Add that autonomy one bounded action at a time. That progression, more than any individual model capability, is what turns an AI feature into a dependable operating model.

References

• The Creators AI – Claude Duet, China’s Flash Duel, OpenAI’s $1.25T Round
• Product School – How Anthropic’s Claude Code AI-Native Team Actually Ships

---