58 — Partial Success Management

Concept overview

Partial success management defines what an aggregate task means when only some branches complete. A portfolio report may remain useful with one unavailable data source, while a settlement calculation may require every mandatory input. The acceptance rule must be a business contract rather than an accidental consequence of whichever promises resolved first.

Each branch needs a stable identity, status, provenance, and freshness. Distinguish failed, timed out, skipped, and unknown outcomes; an empty result is not equivalent to a successful search with zero matches. Aggregation then uses mandatory dependencies, optional enrichment, quorum rules where appropriate, or explicit incomplete delivery.

Why it matters in production

Proof of concept

In a prototype, force one branch to fail and inspect whether the answer falsely claims complete coverage.

Production

Production defines branch contracts, independent retries, durable progress, and a response schema that exposes missing information.

Enterprise scale

Enterprise workflows need incremental updates, ownership of unresolved branches, bounded retention, and reporting that separates task completion from branch completion.

Architecture components

Task manifest

Lists requested branches, required inputs, and completion rules.

Branch executors

Run independent work and return typed status with evidence.

Progress store

Persists individual outcomes and supports selective retry.

Aggregation policy

Decides whether available evidence supports a complete, partial, or blocked result.

Result presentation

Shows coverage, missing sections, freshness, and any pending follow-up.

The architecture, mapped

flowchart TD
 M["Report manifest"] --> A["Required ledger data"]
 M --> B["Required position data"]
 M --> C["Optional market commentary"]
 A --> G["Coverage policy"]
 B --> G
 C --> G
 G --> F["Complete report"]
 G --> P["Qualified partial report"]
 G --> X["Blocked pending required evidence"]

Runtime flow

1. 1

   Create manifest

   Assign branch identifiers and classify mandatory versus optional inputs before execution.

2. 2

   Execute independently

   Run branches within their own deadlines and resource limits.

3. 3

   Persist outcomes

   Record success, error, timeout, or unknown with source and attempt information.

4. 4

   Evaluate coverage

   Apply the task acceptance rule to the available results rather than counting successful calls alone.

5. 5

   Publish qualified result

   Expose missing coverage and prevent unsupported conclusions from entering the narrative.

6. 6

   Repair selectively

   Retry only eligible failed branches and publish a new result revision when evidence changes.

Preparing a morning exposure briefing

Asset management · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A research agent gathers positions, ledger balances, regional market data, and explanatory commentary.

The problem

A commentary provider is unavailable while core position data is complete.

Agent requirement

Publish a useful briefing with an accurate statement of coverage and no invented missing analysis.

Architecture

A task manifest marks positions and balances mandatory and commentary optional.

Runtime

• Branch results are stored independently with timestamps.
• The aggregator publishes exposures and labels commentary unavailable, then schedules a targeted retry.

Failure scenario

If position data fails instead, the report remains blocked because the central exposure claim cannot be supported.

Operational impact

Monitor incomplete-report rate, time to repair missing branches, and operator comprehension of coverage; partial delivery must remain visibly partial.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Returning HTTP success as proof of complete work

Include a structured task-level completion status.

Retrying all successful branches

Retry failed branches by identity and retain valid outcomes.

Hiding omissions in prose

Expose coverage in the response contract and user interface.

When to choose this pattern

Choose it when

• Use for independent research or enrichment branches.
• Use when optional data can arrive after the primary result.
• Use for batch tasks with item-level outcomes.

Avoid it when

• Avoid partial completion for indivisible transactional invariants.
• Do not combine incomparable source timestamps silently.
• Avoid presenting incomplete evidence as a final recommendation.

Architecture checklist

• Identify mandatory branches before execution.
• Define every branch status explicitly.
• Persist per-branch provenance and freshness.
• Prevent unknown values from becoming zeros.
• Support selective idempotent retries.
• Version aggregate results when late evidence arrives.

Related concepts

• 2 — Directed Acyclic Graphs (DAGs)
• 6 — Asynchronous Agent Execution
• 41 — Idempotent Tool Execution
• 45 — Graceful Degradation
• 48 — Dead-Letter Queues (DLQ) for Agents
• 57 — Crash-Safe Memory

Primary references

• AWS Builders Library: Making retries safe with idempotent APIs
• AWS Builders Library: Timeouts, retries and backoff with jitter