Risk
Authority and irreversible side effects come first
Identify active credentials, sessions, pending payments, sent messages, permission changes, production releases, and any effect that cannot be safely repeated.
How to triage partial AI agent tasks in a task-state dashboard.
Separate what succeeded, what failed, what remains risky, and what the next bounded action should be.
Follow the triage sequenceFreeze current stateClose active authorityInventory side effectsVerify each outcomeChoose rollback or remediationReceipt the truthFreeze current state
What partial means
A partial task is not a vague warning. It is a precise mismatch among required outcomes.
Start with evidence
A task is partial when at least one required outcome succeeded and at least one required outcome failed, remained unknown, or could not be verified. The category applies to mixed file uploads, provider release success with broken custom routing, messages delivered to only some recipients, incomplete account updates, or a successful action followed by failed cleanup.
Partial does not describe confidence or quality. It describes the relationship between expected outcomes and evidence. The dashboard should identify each required check, its result, side effects already committed, remaining authority, rollback options, and bounded next actions.
Triage priorityClose or contain sensitive authority before investigating convenience failures. A broken custom domain can wait; an active privileged browser session cannot.
The goal is not to make the card green quickly. It is to place the system in a safe known state, tell the user the truth, and choose remediation without replaying successful work or broadening authority.
Triage architecture
Separate four dimensions before choosing an action.
Execution
Record which actions actually ran, which were blocked, and which provider responses remain ambiguous.
Verification
Distinguish failed checks from checks that never ran, timed out, or lack enough evidence.
Remediation
Choose rollback, retry only failed items, repair infrastructure, request new approval, or accept the known limitation.
Triage sequence
Seven steps from mixed outcome to safe resolution.
STEP A
Freeze the canonical task state
Stop automatic retries and capture current task version, agent, runtime, grant, executed actions, provider responses, required checks, and known side effects.
STEP B
Close or contain active authority
Revoke unused grants, end browser sessions, stop workers, and isolate credentials. If access cannot close, elevate the task to attention-required regardless of other success.
if authority.sensitive and authority.open:
state = "attention"
next_action = "revoke"
block_auto_retry = trueSTEP C
Inventory committed side effects
List published releases, sent messages, uploaded items, charges, permission changes, and external IDs. Mark which effects are reversible, compensatable, or irreversible.
STEP D
Classify every required check
Use passed, failed, unknown, skipped, or not-applicable. Do not treat timeout as failure or absence of evidence as success.
STEP E
Choose rollback or bounded remediation
Rollback when the successful side effect is unsafe without the failed outcome. Otherwise preserve valid work and create a new task only for the failed portion.
STEP F
Send a truthful partial receipt
Lead with what succeeded and failed, state closure, identify the next action, and link to secure evidence. Avoid generic completion language.
STEP G
Close, accept, or escalate
Move to complete only after required remediation and checks pass. Preserve partial with accepted limitation, rolled-back when restoration verifies, or attention when risk remains.
Decision table
Choose the smallest safe next action.
| Observed condition | Action | Reason |
|---|---|---|
| Sensitive authority remains open | Revoke first | Contain privilege before debugging or retrying. |
| Successful side effect is unsafe alone | Rollback | Restore the prior known-good state and verify it. |
| Successful items are independently valid | Preserve | Avoid duplicate work and retry only failed items. |
| Verification timed out | Recheck | Do not mutate state until the user-visible outcome is known. |
| Remediation needs broader authority | Fresh approval | Do not reuse the original grant for a different capability. |
| User accepts a known limitation | Record acceptance | Preserve the failed check and accepted residual state. |
Partial receipt
Tell the user exactly where the task stands.
Website published; custom domain failed
The hosting route is healthy. DNS still points elsewhere. Temporary deployment access is closed.
SucceededApproved artifact deployed to Render · release deploy-185
Failedhttps://example.com returns 404; provider route returns 200
Side effectsNew release active on hosting service; prior release available
AuthorityCLOSED deployment grant revoked
Next actionCreate a separate DNS remediation task with fresh approval
Verification checklist
Before resolving a partial task
All grants accounted for
Every issued credential, session, and worker has a known closure state.
Side effects enumerated
External IDs and irreversible actions are captured before retry.
Required checks explicit
Passed, failed, unknown, and skipped are not collapsed together.
Retry scope bounded
Successful items cannot be duplicated by the remediation task.
Rollback verified
Restoration is checked independently before declaring rolled back.
User receipt delivered
The user sees mixed outcome, closure, and next action clearly.
Partial is not an embarrassing version of success. It is the honest state that makes safe remediation possible.
Common triage failures
Avoid turning one mixed outcome into a larger incident.
Blind full-task retry
Repeats successful uploads, messages, charges, or releases and may consume broader authority than needed.
Retry failed units only.Debug before revoke
Leaves sensitive sessions active while operators investigate a lower-priority functional failure.
Contain authority first.Green status after provider success
Hides failed user-visible routes, missing recipients, or broken downstream behavior.
Verification defines the outcome.Use this with Super
Super can make partial outcomes understandable and actionable by text.
A conversational triage loop
The text-message AI assistant can deliver the partial receipt, identify the safest next action, and wait for fresh approval when remediation changes scope.
For a computer-use cache, triage can preserve useful safe state while explicitly revoking sensitive sessions and preventing blind task replay.
When an AI agent builds a website, Super can distinguish a healthy Render deployment from a broken custom domain, close deployment authority, and open a separate DNS task instead of claiming full success.
FAQ
Partial-task triage questions
When should a partial task become failed?
Use failed when none of the required user outcomes remain valid or the successful side effects must be rolled back. Keep partial when meaningful approved outcomes remain while others failed or remain unresolved.
Can a user accept a partial outcome?
Yes. Record explicit acceptance, the known failed checks, residual risk, and closure state. Do not rewrite the receipt as fully successful.
Should automatic retries ever be allowed?
Only for idempotent, bounded units under existing authority and policy. Disable automatic retries when side effects are unknown, irreversible, duplicated, or require broader scope.
What if rollback also fails?
Escalate to attention or incident state, contain authority, preserve evidence, inform the user, and avoid additional autonomous mutation until a reviewed plan exists.
What is the first dashboard field to inspect?
Active sensitive authority. A functional failure can often wait; an open privileged grant, session, or worker changes the immediate risk posture.
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 dashboard access.