Product Promise and Task Fit

An agentic product can fail before the first model call. The failure begins when the product promises the wrong kind of work: “handle support,” “do research,” “manage my inbox,” “fix my repository,” or “run operations” without saying which cases are eligible, which evidence counts as completion, which actions are only staged, and what happens when the system is wrong.

A fluent prototype makes this easy to miss. In a demo, the user gives a clean goal, the sources are available, the tool call succeeds, the output is persuasive, and nobody asks who owns the result after the meeting. In production, the same product meets stale data, conflicting permissions, missing context, interrupted sessions, domain exceptions, inaccessible controls, and users who reasonably believe that “the agent did it” means the work is actually done.

The product question is therefore not:

Can a model do this once?

It is:

Can this system, for these users, under these conditions, deliver an accepted outcome often enough and safely enough that delegation is a responsible product promise?

Thesis

An agentic product should be promised only when the task requires adaptive work on the user’s behalf, the accepted outcome can be stated, the system’s limits can be communicated, and failure consequences can be bounded through product, technical, and operational controls.

A product promise is not marketing copy. It is the user-facing version of an operating claim. It says what work the system will attempt, what evidence completion requires, what authority it may exercise, what remains the user’s responsibility, and when the system will refuse, narrow scope, or hand back control.

The promise does not need to expose every architecture detail. It does need to be true enough that a user can decide whether to delegate. “Draft a response using the selected documents” is a different promise from “reply to this customer.” “Prepare a pull request for review” is a different promise from “fix the bug.” “Find likely options and cite sources” is a different promise from “decide which vendor to buy.”

Start with the job, not the agent

Human-centered design begins by understanding users, tasks, environments, and the lifecycle of use, then evaluating the design against that context (ISO 9241-210:2019). For agentic products, that means the team should describe the work before choosing the interaction pattern:

who needs the outcome and who is affected by it;
what successful completion changes in the user’s world;
which parts of the task are repetitive, judgment-heavy, open-ended, exception-prone, or socially sensitive;
what evidence exists before, during, and after the task;
which systems of record, policies, people, and tools constrain the work;
what happens when the system is wrong, late, incomplete, inaccessible, or overconfident; and
which simpler product shape would solve the same need with less uncertainty.

Many useful AI features do not need an agent. A classifier, extractor, search interface, drafting tool, deterministic workflow, rules engine, template, or human service may be more honest and more valuable. Anthropic recommends starting with the simplest approach that works because agentic flexibility trades against cost, latency, and predictability (Anthropic, 2024). OpenAI describes agents as useful for workflows with complex decisions, difficult rules, and unstructured data (OpenAI, 2026). Those are fit criteria, not permission to make every feature agentic.

The job framing should include the user’s existing alternative. If the current alternative is “ask an expert,” the product must explain how expertise, accountability, and correction are preserved. If the current alternative is “fill a form,” an agent may add cost and unpredictability without adding value. If the current alternative is “coordinate several systems and revise the plan as facts appear,” an agentic experience may be justified because adaptation is the value.

Define the accepted outcome

The promise should name the result, not the interface:

Weak promise	Stronger promise
“An AI agent for expenses”	“Prepare an expense report from approved receipts, flag missing policy evidence, and submit only after user review.”
“Research anything”	“Produce a sourced brief on a bounded question, distinguish cited evidence from uncertainty, and list unresolved claims.”
“Handle customer support”	“Resolve eligible refund requests under a documented policy and escalate disputed or high-value cases.”
“Fix my code”	“Investigate a reported bug, prepare a patch, run the repository’s tests, and present the diff and failures for review.”
“Manage my inbox”	“Draft replies and propose archive or follow-up actions for selected threads; send only messages the user approves.”

Use the Production Engineering term accepted outcome: a result that meets named completion, quality, policy, and effect criteria. If the product cannot define acceptance, it cannot honestly claim completion. It can still offer exploration, brainstorming, drafting, or advisory help, but that is a different promise.

For each supported task, state:

supported inputs and starting conditions;
the result the system is trying to produce;
how the result is verified;
which errors are tolerable, recoverable, or unacceptable;
which data, accounts, tools, and policies are required;
what information or authority the user must provide;
what the system will not do;
when the system will stop, ask, or escalate; and
what evidence the user receives at the end.

Microsoft’s human-AI guidelines recommend making clear what the system can do, how well it can do it, and when it may be wrong (Amershi et al., 2019). For agents, that clarity must cover the whole delegated task, not only the next answer.

Treat task fit as a design decision

Task fit is the match among user need, task structure, evidence, consequence, and feasible control design. It is not a model benchmark score. A model may perform impressively on a general test while the product lacks access to current customer records, cannot bind approvals to actions, cannot recover unknown effects, or cannot explain uncertainty to the people affected.

Use the following dimensions as a product review:

Dimension	Fit question	Warning sign
Need	Does the user need work done, advice, exploration, or a better interface?	The product adds an agent because the technology is available, not because the job requires adaptation.
Task structure	Are the meaningful steps known, or must the path adapt from new observations?	A fixed workflow would cover the cases but the team prefers an “agent” label.
Evidence	Can the system observe enough current truth and verify the outcome?	Completion depends on the model saying it is done.
Consequence	What harm follows from wrong, late, partial, biased, or overconfident work?	The same UI is used for trivial drafts and high-stakes effects.
Reversibility	Can effects be staged, undone, compensated, or reviewed before commit?	The product offers “undo” where only a new corrective action is possible.
Authority	Who may decide, approve, spend, disclose, send, update, or close?	Users grant broad access without seeing specific effects.
User capability	Can the intended user understand the scope and evidence well enough to supervise?	Review relies on expertise the user may not have.
Operations	Can the team support latency, cost, monitoring, recovery, appeals, and incidents at this scope?	Demo success hides manual repair or support burden.

No single dimension decides fit. A read-only research task may tolerate more path discretion because its direct external effect is small. A fixed refund workflow may require strong control because the action authority is high even if the path is simple. A medical, legal, financial, employment, or benefits context may demand expert accountability and formal recourse even when the model produces plausible advice.

Classify the promise before designing the interface

The product shape should follow the task-fit review:

Product shape	Use when	Product promise
Information feature	The main value is retrieval, filtering, classification, or extraction.	“Find, organize, or label this information under stated limits.”
Drafting assistant	The user remains the primary author or decision-maker.	“Produce candidate text or options for you to edit and accept.”
Predefined workflow	Stages and exceptions are known enough to encode.	“Move eligible cases through this controlled process.”
Copilot with tools	The user directs the work while the system helps execute steps.	“Help you perform actions you choose and review.”
Agentic delegation	The system must choose and revise the path from feedback.	“Pursue this bounded goal and return evidence, approvals, or exceptions.”
Human service with AI support	Stakes, ambiguity, ethics, or accountability require people to own the outcome.	“Support a named human operator or expert who remains responsible.”

An agent is justified by the value of adaptation. If the task mostly fills fields, retrieves known records, or follows stable policy rules, a workflow may produce a better product. If the task requires discovering what matters, choosing tools, revising a plan, and producing an artifact from changing evidence, an agentic shape may fit.

Choosing a less autonomous shape is not a failure of ambition. It often creates a sharper product: lower latency, clearer responsibility, easier evaluation, more predictable accessibility, and fewer recovery paths.

Write the promise as a boundary

A good promise has five parts:

For whom:
Supported work:
Evidence of completion:
Authority and control:
Limits and handback:

Example:

For support managers reviewing low-value refund requests:
the system evaluates requests against the published refund policy,
collects customer and order evidence from the connected systems,
prepares a decision with policy reasons,
auto-approves only eligible refunds under the configured threshold,
and escalates disputed, missing-evidence, high-value, or policy-exception cases.

That statement gives product, engineering, evaluation, and support teams something to test. It also gives users a mental model. The promise names the domain, value threshold, evidence, action authority, and exceptions.

The boundary should be visible at three moments:

Before delegation: so users know whether the task is eligible.
During work: so status, approvals, and refusals make sense.
At completion or failure: so the user can interpret the result.

Google’s People + AI Guidebook emphasizes helping users form accurate mental models, give feedback, and recover from errors (Google PAIR). The product promise is the first mental model. If it is inflated, later UI details struggle to repair trust.

Bound unsupported work explicitly

Unsupported work should not be discovered only after a user invests effort. State exclusions when they affect safety, quality, cost, legality, or expectation:

domains, languages, jurisdictions, or account types not supported;
data sources not connected or not current;
actions the product will draft but not commit;
actions that require a separate approval or human service;
freshness windows for retrieved or cited information;
user groups for whom the product has not been evaluated;
accessibility or device limitations that affect use;
sensitive cases routed to support, expert review, or refusal; and
product behavior when policy, authority, or evidence is missing.

Unsupported work should lead to refusal, narrowing, handoff, or a safer product shape rather than improvisation. A research agent can say “I can produce a sourced summary, but I cannot determine legal compliance.” A coding agent can say “I can prepare a patch, but I cannot deploy it.” A scheduling agent can say “I can propose times, but I cannot book outside the accounts you connected.”

Avoid these promise patterns:

universal verbs: “handles,” “solves,” “manages,” or “automates” without scope;
person replacement: implying the system owns judgment that remains human or organizational;
hidden conditions: success depends on clean data, narrow cases, or manual repair not disclosed;
benchmark laundering: a general model score is used as proof of product readiness;
silent authority expansion: a draft assistant quietly becomes an actor that commits effects;
silent learning: user work is retained or reused without an explicit memory promise; and
success by fluency: final text is treated as completion without environmental evidence.

Match launch scope to evidence

The safest first release is often not a weaker product; it is a more honest promise. Narrow by:

user group with strong feedback and support;
task slice with clear accepted outcomes;
read-only or propose-only authority;
reversible or staged effects;
language, geography, or domain where evidence exists;
known data sources and freshness bounds;
short operating horizon before long-running automation;
explicit review checkpoints; and
operational capacity for recovery and support.

Widen only when evidence supports the wider claim. A launch that says “drafts a plan for review” can become “executes approved low-risk steps” later. A launch that says “does your work automatically” has little room to admit reality without disappointing users.

NIST AI RMF material emphasizes defining context, intended use, impacts, and risk management responsibilities across the lifecycle (NIST AI RMF Playbook). Product teams do not need to turn every launch into a formal risk filing, but they do need a named operating claim, affected people, expected benefits, foreseeable harms, evidence limits, and a decision owner.

Connect promise to evaluation and operations

The product promise becomes the claim that evaluation and operations must support. If the promise says “resolve eligible refunds,” evaluation needs eligible, ineligible, ambiguous, missing-evidence, adversarial, and policy-exception cases. If the promise says “prepare a pull request,” evaluation needs repository states, test expectations, review quality, and failure recovery. If the promise says “produce a sourced research brief,” evaluation needs source quality, citation accuracy, uncertainty handling, and unsupported-claim detection.

Do not evaluate only the easiest visible output. The promise may require:

task-level success evidence, not answer quality alone;
authority checks and approval binding;
accessibility of controls and status;
refusal and handback behavior;
latency and cost under realistic workload;
recovery after tool, model, network, or user interruption;
user ability to notice seeded errors; and
support processes for disputes, corrections, and escalation.

This chapter does not own evaluation methodology. It owns the product claim that the Evaluation Systems and Quality Gates chapter will measure. When the claim changes, the evaluation suite, launch notes, support scripts, and UI copy should change with it.

Product examples

Research brief assistant

Good fit: the path depends on discovered sources, contradictions, and scope refinements. The system can produce a bounded artifact, cite sources, mark uncertainty, and ask when evidence is insufficient.

Promise boundary: it summarizes and structures evidence; it does not certify truth, replace expert review, or make a decision for the organization.

Key evidence: source provenance, publication and access dates, unsupported claims, known conflicts, and unresolved questions.

Customer refund agent

Good fit only for bounded cases. The system can observe order data, policy rules, customer history, amount thresholds, and payment status. It can auto-commit low-value eligible refunds if authority and idempotency are enforced.

Promise boundary: disputed, high-value, suspicious, missing-evidence, or policy-exception cases are escalated. Approval is bound to a concrete action.

Key evidence: policy match, order status, amount, customer communication, committed refund identifier, and reconciliation status.

Personal scheduling assistant

Good fit when the user wants coordination across calendars, preferences, and changing availability. The task becomes riskier when messages are sent to other people or meetings are booked without review.

Promise boundary: the system may propose times, draft messages, and book only within approved calendars and availability windows.

Key evidence: invitees, time zones, conflicts checked, message content, approval state, and calendar write confirmation.

General “do anything” assistant

Poor fit as a product promise. It may be useful as an exploratory interface, but the supported task set is too broad for honest evaluation, clear authority, accessible control, and reliable recovery.

Better promise: divide it into named task families, each with its own accepted outcome, limits, and evidence.

Failure modes

Demo-as-promise

The team promises a live product based on a curated demonstration. The first uncurated cases reveal missing data, ambiguous goals, inaccessible controls, unsupported recovery, and invisible manual repair.

Capability without task fit

The model can perform a step, but the product lacks authority, evidence, state, or recovery for the whole outcome.

The universal assistant

The product tries to accept every task. Users cannot know which requests are supported, and evaluation cannot represent the claimed scope.

Hidden human repair

The system appears autonomous because people behind the scenes correct failures. The product promise hides cost, latency, accountability, and support obligations.

Unsupported refusal surprise

The system refuses or escalates only after the user has invested effort. Scope limits were not visible before delegation.

Product copy outruns operations

The public page promises automatic completion, while the runtime still lacks monitoring, recovery, handoff, or a staffed support path.

Fieldbook guidance

Write the product promise before designing the agent loop.
Define accepted outcomes and unsupported work in user language.
Compare agentic delegation against simpler product shapes.
Match autonomy to consequence, reversibility, evidence, user capability, and operational readiness.
Launch with the narrowest promise that can be supported honestly.
Treat evaluation and production evidence as proof for a bounded claim, not as permission for universal scope.
Update the promise, UI, evaluation suite, support process, and release gate together when scope expands.

Checklist

References and how they are used

Anthropic, “Building effective agents” - Anthropic engineering article supporting the “simplest solution that works” principle and the workflow-agent distinction.
Google People + AI Research, People + AI Guidebook - Google People + AI Research design resource used for mental models, feedback, control, explainability, and graceful failure; it is not a formal standard or independent validation of any product.
ISO 9241-210:2019, Ergonomics of human-system interaction - international human-centered design standard used for user, task, environment, and lifecycle framing; this chapter used only the ISO abstract page.
Microsoft Research, “Guidelines for Human-AI Interaction” - peer-reviewed human-AI interaction paper supporting expectation setting, capability limits, uncertainty, correction, and control.
NIST AI Risk Management Framework Playbook - NIST voluntary risk-management web resource used for context, intended-use, impact, and lifecycle risk framing; it is not a product-design certification.
OpenAI, “A practical guide to building AI agents” - OpenAI product-adjacent agent-building article used for current agent use-case criteria, handoff, and human intervention patterns.