Both
Success and failure can coexist
The state records valid completed outcomes, explicit failed checks, unknown verification, side effects, and closure without forcing a misleading single-color summary.
Partial is becoming a core product state for personal AI agents.
The market needs a state between success and failure that preserves what worked, exposes what did not, and narrows the next action.
Read the market signalsPARTIAL · HOSTING LIVE · DOMAIN FAILED · ACCESS CLOSED
Preserve valid workExpose failed checksContain open authorityAvoid duplicate side effectsNarrow remediationReceipt the truthPreserve valid work
Market thesis
Binary success is too crude for autonomous work across multiple systems.
The missing middle
Traditional software often presents a clean final answer: a request succeeded or failed. Personal agents operate differently. One task may cross a browser, identity provider, credential vault, hosting service, custom domain, messaging channel, and independent verifier. Outcomes can disagree.
A site may publish successfully while DNS still points elsewhere. Two files may upload while the third is rejected. A message may reach one recipient but not another. An account change may complete while the temporary browser session remains active. Calling these tasks complete hides unresolved work. Calling them failed discards meaningful success and encourages unsafe full retries.
Editorial inference from control guidancePartial will become a standard personal-agent state because it gives products a truthful way to preserve valid work, expose failed outcomes, contain authority, and propose bounded remediation.
NIST zero trust guidance emphasizes dynamic policy, least privilege, continuous evaluation, and just-in-time access. OWASP emphasizes expiration, revocation, and audit. Partial state translates those controls into a product decision: do not broaden or repeat execution until the exact mixed outcome and remaining authority are known.
Why the state matters
Partial protects users from both false confidence and unnecessary replay.
Valid work survives
The product can preserve accepted uploads or a healthy provider release instead of rolling back everything automatically.
Retries become smaller
Remediation targets failed units and avoids duplicate messages, charges, files, or releases.
Risk stays separate
Open authority can elevate the task to attention even when most functional outcomes passed.
Partial-state anatomy
A structured account of the mismatch.
Expected
The approved set of user-visible outcomes, constraints, side effects, and closure conditions that define a complete task.
Passed
Required outcomes with attributable evidence, such as a provider release ID or verified file digest.
Failed
Required outcomes that produced explicit negative evidence, including status, error, destination, and retry safety.
Unknown
Checks that timed out, never ran, or lack enough evidence. Unknown must not collapse into success or failure.
Side effects
Committed changes, external identifiers, reversibility, compensation options, and duplication risk.
Authority
Every temporary credential, session, agent runtime, and whether it is active, expired, revoked, or unaccounted for.
Next action
The smallest safe remediation, rollback, recheck, fresh approval, acceptance, or escalation supported by current evidence.
Partial is not a weaker success message. It is the control state that makes safe remediation possible.
Four market signals
What is making partial unavoidable
MULTI-SYSTEM
Outcomes disagree
Provider APIs, public routes, downstream delivery, and custom domains can produce different truths for one user task.
SIDE EFFECTS
Replay is dangerous
Messages, charges, uploads, permissions, and releases may not be safely repeated after one unit fails.
VERIFICATION
Execution is not outcome
Independent checks expose cases where the agent's tool succeeded but the user-visible result did not.
AUTHORITY
Functional and security state differ
A task can be functionally successful while sensitive access remains open, requiring attention rather than completion.
Product implications
Partial changes what the interface must support.
| Product surface | Required behavior | Why it matters |
|---|---|---|
| Task dashboard | Dedicated partial queue with failed checks, authority state, and next action. | Mixed outcomes remain visible after newer activity arrives. |
| Conversation | Message names both success and failure plus closure and remediation. | Users are not misled by a generic completion phrase. |
| Policy engine | Blocks blind full retry when side effects or authority are unsafe. | Prevents duplicate or broadened execution. |
| Receipt service | Stores passed, failed, unknown, skipped, and accepted outcomes separately. | Evidence remains precise enough for support and automation. |
| Remediation flow | Creates a fresh bounded task under current approval and policy. | The original grant cannot silently expand to new work. |
Buyer checklist
How to recognize real partial-state support
Required checks are configurable
Complete state depends on task-specific expected outcomes.
Unknown differs from failed
Timeouts and missing evidence preserve uncertainty honestly.
Side effects are itemized
External changes and duplicate risk are visible before retry.
Authority is independent
Open sensitive access can escalate the task beyond partial.
Remediation is bounded
Next actions target failed outcomes under fresh policy.
Receipts stay truthful
Accepted limitations remain recorded instead of becoming green success.
The products users trust will not be the ones that report the most success. They will be the ones that explain mixed outcomes without flinching.
Applied to Super
Super can turn partial outcomes into precise next decisions.
A conversational remediation loop
The text-message AI assistant can report what succeeded, what failed, whether access is closed, and which bounded action is available, then wait for a fresh decision.
For a computer-use cache, partial state can preserve safe reusable context while ending sensitive sessions and preventing full-task replay.
When an AI agent builds a website, Super can state that Render is healthy while the custom domain fails, close deployment authority, and request separate approval for DNS remediation instead of calling the release complete.
FAQ
Questions about the partial state
Is partial just another word for warning?
No. Partial is a structured task state with at least one required outcome passed and at least one failed or unknown. A warning can exist on tasks in many states.
When should partial become attention?
Escalate when sensitive authority remains open, rollback fails, side effects are unsafe, or user intervention is urgently required. Functional outcome and risk state should remain distinct.
Can partial tasks close without remediation?
Yes, if the user explicitly accepts the known limitation and authority is safely closed. Preserve the failed or unknown check and acceptance in the receipt.
Why not automatically roll back every partial task?
Successful outcomes may be independently valuable, rollback may create more risk, and some side effects are irreversible. Policy should evaluate safety and user intent before restoration.
What is the most useful first implementation?
Add partial to one multi-system workflow, define required checks, expose failed and unknown outcomes, track authority separately, and prevent blind full-task retries.
Primary references
- NIST, Implementing a Zero Trust Architecture. Just-in-time access, least privilege, continuous evaluation, and policy decisions.
- NIST SP 800-207, Zero Trust Architecture. Dynamic policy and resource-level authorization.
- OWASP Secrets Management Cheat Sheet. Secret audit, expiration, revocation, and secure token handling.
- NIST SP 800-63B, Authentication and Authenticator Management. Authentication lifecycle relevant to secure remediation access.