Why AI Demos Succeed But Production Fails: The Business Capability Contract Gap

The article opens with a hypothetical after-sales scenario: an equipment manufacturer receives a repair ticket, and a service specialist must triage it to the right repair team. An AI assistant is expected to read materials, consult manuals, and propose a triage suggestion with reasoning and a missing-materials list. In the demo, the assistant processes a customer sentence — "device runs a while then overheats and restarts" — reviews photos and records, and suggests "suspected cooling module anomaly, route to cooling repair team." The output looks ready to save the specialist time.

When actually transferring the ticket, the specialist discovers a conflict: the model number on the photo does not match the asset ledger, and the two models use different repair manuals. The ticket must be paused for verification. Even without conflicts, the team must decide which tickets can be auto-triaged and which require human review. This missing set of agreements — when the result can be used, who confirms it, how to transfer, when to stop — is called the Business Capability Contract . It is a shared delivery agreement among parties, not a separate legal contract.

Delivering an AI capability requires stating clearly when it can be used, who is responsible for the result, and what happens when something goes wrong.

The article references InfoQ's "Why Can't a Strong Model Enter Production?" which defines a production-grade operator contract covering I/O, invocation protocol, and quality norms. This piece extends that vendor engineering practice to concrete business objects, responsibilities, execution boundaries, and end-to-end acceptance conditions — a systems-engineering approach: define business goals and boundaries first, then allocate responsibilities among models, people, and systems, and finally verify the whole flow meets the goal.

What the Business Must Verify After Model Output

An AI operator encapsulates a specific data or model processing capability for other programs to call. Examples include:

Recognizing device nameplates from repair photos

Extracting fault phenomena from customer-service dialogues

Judging whether ticket text contains safety-risk keywords

Classifying a repair record into a fault category

Generating structured summaries from multiple documents

A reusable operator needs agreed I/O, version, quality metrics, failure semantics, and caller handling guidance. However, an operator meeting its own contract does not guarantee it satisfies all conditions of a specific business process. The caller must still verify:

Whether the result corresponds to the current business object

Whether confidence reaches the threshold to enter the next stage

Which missing evidence forces a stop

Whether warranty, inventory, regional, or permission constraints are satisfied

Who can upgrade a "suggestion" to a "formal processing conclusion"

What changes the conclusion triggers in ticket, customer commitment, or spare-part status

For instance, a 故障图片识别 (fault image recognition) operator returns "cooling module anomaly, confidence 0.86." This output can serve as a diagnostic candidate but cannot equal "confirm replacement of cooling module." The latter conclusion affects spare-part requests, cost attribution, customer promises, and subsequent warranty — it must bind to a specific device, on-site inspection, business rules, and a responsible person.

If these agreements are deferred until after launch, business staff must repeatedly explain rules verbally, and developers add ad-hoc judgments for different callers. The same result may be interpreted differently in different systems.

Six Questions to Clarify Before Going Live

Returning to the after-sales ticket assistant, delivering triage suggestions as a business-usable capability requires answering six questions explicitly:

Service what object — Business object, scope, and identity determination. Example: An accepted equipment repair ticket with its associated device and customer contract.

At what time point is it available — Preconditions, input completeness, version conditions. Example: Ticket accepted, in pending-triage state, device bound; re-processing requires verifying current state and version.

What is the nature of the output — Fact view, candidate judgment, processing suggestion, or action candidate for policy/authorization layer. Example: Fault category candidates, missing-materials list, triage suggestion — not a direct ticket rewrite.

Where does the evidence come from — Data sources, rules, evidence, semantic versions. Example: Device model, repair history, warranty rules, current photos, ticket text.

Who is responsible for the result — Auto-pass thresholds, review roles, escalation paths. Example: Low-risk tasks meeting criteria auto-triaged; review-needed tickets confirmed by service specialist; safety risks routed to field engineers.

How does the result close the loop — Allowed state transitions, receipts, audit requirements. Example: After verification and authorization, a controlled service submits a triage request; the ticket system updates state and returns a receipt; records version, evidence, and necessary approvers.

Parameters and return values only describe how to invoke. These six questions also explain at which process step the call occurs, who receives the result, and who handles subsequent problems.

Write a Contract Card First, Not a Big Document

Teams can start by writing a contract card for the AI capability about to go live, recording only the agreements the caller must know. Existing business rules and interface documents are referenced directly, not copied wholesale.

Three easily confused terms are distinguished:

Operator Contract (算子契约) — Governs I/O, invocation protocol, failure semantics, and processing quality.

Business Capability Contract (业务能力契约) — Additionally governs which business object is served, when it is available, what the output nature is, who is responsible, and how the whole task is accepted.

Action Contract (动作契约) — Required when changing business state; defines preconditions, authorization, expected effects, idempotency, failure handling, and receipts. Idempotency prevents duplicate changes from repeated submissions; receipts verify how far an action executed. This is expanded in "Action in Ontology Is Not an API: How to Design Enterprise Agent Action Contracts."

For example, nameplate recognition follows the operator contract; after-sales triage follows the business capability contract; moving a ticket into a specific queue follows the action contract. All three should reference consistent business definitions and rule versions to avoid duplicate maintenance. A business capability may be implemented by one or more Skills, but Skill implementation agreements cannot replace business responsibility and execution authorization.

Minimum Contract Card Example: After-Sales Ticket Intelligent Triage

Capability Name : After-Sales Ticket Intelligent Triage

Business Goal : Shorten first-triage time, prioritize exposure of safety and high-risk tickets

Applicable Object : Accepted, pending-triage equipment repair tickets

Input Preconditions : Ticket bound to device; device model, fault description, and at least one on-site material available

Output Structure : Fault category candidates, risk level, missing materials, evidence references, suggested destination

Output Nature : Candidate judgments and processing suggestions, not formal fault conclusions

Business Rules : Tickets involving personal safety, batch faults, or warranty disputes enter agreed escalation paths; must not be auto-triaged as ordinary low-risk tasks

Auto-Pass Threshold : Limited to verified low-risk categories; passes published quality checks, evidence completeness, deterministic rules, current state, and authorization verification

Human Responsibility : Service specialist confirms triage needing review; safety and complex faults handed to designated professional roles

Action Boundary : Model generates candidate suggestions; controlled service submits triage or escalation request after verification and necessary human confirmation; formal state updated by ticket system

Acceptance Conditions : Separately define completion endpoints, time limits, required receipts, and subsequent quality verification windows for auto-triage, human-confirmed triage, and risk escalation

Quality & Fallback : Monitor mis-triage rate, human-handoff rate, missing-evidence rate; fall back to manual triage on anomaly

Version & Evidence : Record model/operator/rule versions, source-material snapshots, and confirmation records

Following this card, the model first provides suggestions and evidence; the business service then decides whether to auto-advance or escalate to human based on rules; the ticket system performs final verification and state update. "Controlled" does not mean every step requires human approval; the scope, authorization, and responsibility for auto-processing are also defined upfront.

If later extended to multi-agent collaboration, the same agreements are needed. For example, a triage agent calls an inventory-query agent, then passes results to a repair-scheduling agent. Each handoff must clarify object, I/O, evidence timeliness, responsible party, and failure fallback. An inventory query result does not equal inventory reservation; a triage suggestion does not equal scheduling authorization; downstream must still verify its own action permissions. Each capability has its own contract, and the overall flow needs an owner and end-to-end acceptance criteria — multiple local successes cannot be directly treated as whole delivery.

Role of Business Ontology

Capability contracts do not require building a massive ontology or graph database first. But once capabilities work across systems, semantic questions appear quickly: What defines a "high-risk ticket"? Is "duplicate fault" same device, same part, or same symptom? What facts and states do "accepted," "pending dispatch," "closed" correspond to?

These questions cannot be stably decided by the model alone, nor should they be scattered across operators and workflows. A business ontology or semantic model unifies these definitions: how devices and tickets relate, what states represent, what rules judge risk. Capability contracts then reference these definitions to specify how far this triage must go.

The relationship can be understood as: business semantic models and capability contracts provide definitions; operators, workflows, and controlled services implement checks; source business systems independently verify and return final receipts.

With shared definitions, different teams avoid interpreting "high risk" and "completed" differently. Concrete checks and handling are still executed by operators, workflows, and business systems.

Acceptance: Don't Just Look at Model Scores

Model evaluation is necessary — recognition accuracy, extraction completeness, latency, and per-call cost should be continuously observed. But business acceptance must also check beyond these metrics:

Technical Processing : Are there explicit results and fallback paths for input anomalies, missing materials, model timeouts, or version switches?

Semantic Consistency : Do output objects, classifications, states, and rule calibers align with current business definitions?

Business Usability : Can personnel understand and confirm results? Are high-risk scenarios correctly intercepted or escalated?

Operational Closure : Can results, evidence, confirmations, and subsequent actions be traced back to the same ticket?

If teams only watch model metrics, they easily optimize a "better-at-answering" capability without knowing whether it reduces human judgment burden or blocks wrong routing at the business entry.

Conversely, a high human-handoff rate does not immediately indicate capability failure. First check whether it accurately routed truly complex and high-risk tickets to the right people, and whether it reduced low-value retrieval and duplicate entry. Business value is not determined by automation ratio alone.

Scenarios That Can Be Simpler

If the scenario is offline batch organization of historical images, generating candidate labels for internal R&D, and results do not directly affect customers, process states, funds, permissions, or safety, clear operator I/O, data versions, and sampling evaluation are usually sufficient. Wrapping every processing step as a full business capability only adds unnecessary governance cost.

But when a capability begins to:

Cross-system read or combine business facts

Influence ticket routing, customer commitments, resource allocation, or risk handling

Require humans to confirm or be accountable based on results

Need long-term reuse amid continuous changes in rules, data, and models

then at minimum the capability boundaries, output nature, responsibilities, and fallback mechanisms should be written as verifiable contracts.

Summary

Returning to that model-conflict ticket. The service specialist needs to know: can this suggestion be used now, what evidence is missing, and who to contact next. No matter how complete the model's answer, these things cannot be left to on-the-spot guessing.

The next article "Agent Workflow Runs, Why Still Need Human Firefighting After Launch?" will examine how to embed these agreements into the runtime process so that when anomalies occur, someone is accountable, there are ways to investigate, and clear stop conditions exist.

References

InfoQ, "Why Can't a Strong Model Enter Production?" This piece presents vendor engineering practice defining production-grade operator I/O, invocation protocol, and quality agreements; the current article builds on that to elaborate division of labor among business capability contracts and action contracts, without generalizing the case-study effects as universal conclusions.

https://www.infoq.cn/article/j2kBZR1JiZxATpU7gjtS