State
One accountable object replaces scattered updates
The task gathers approval, agent identity, authority, execution, verification, failure, rollback, and closure into one current state with complete history underneath.
The personal AI agent market is moving from notifications to task state.
Notifications tell users something happened. Task state tells them what still needs attention, what can be trusted, and what authority remains open.
Read the market signalsNOTIFICATION · Deployment finished
TASK STATE · Partial, DNS unresolved, access closed
Waiting for approvalRunning under policyPartial with next actionFailed without changeAttention access still openComplete and verifiedWaiting for approval
Market thesis
Autonomous work needs state users can act on, not a stream they must interpret.
The interface shift
Notifications are a natural first layer for agent products. They announce that a task started, a tool ran, a message was sent, or a workflow finished. But as agents become more autonomous and consequential, individual events do not answer the user's real question: what is the state of my task now?
A task can be published to a hosting provider while its custom domain remains broken. A browser action can fail while the temporary session stays active. A payment can be prepared but still require confirmation. A file upload can succeed for two items and fail for the third. These are not merely events. They are accountable states with different next actions.
Editorial inference from security guidancePersonal-agent products will increasingly compete on how clearly they expose waiting, running, partial, failed, unverified, access-open, rolled-back, and complete states.
NIST zero trust guidance emphasizes dynamic policy, least privilege, just-in-time authority, and continuous evaluation. OWASP emphasizes expiration, revocation, and audit. Task state brings those infrastructure properties to the product surface by telling users not only that work occurred, but whether authority and outcome have reached an acceptable ending.
Why notifications stop scaling
More events can create less understanding.
Partial success stays visible
The product can show that the provider route works while the custom domain does not, instead of choosing one misleading color.
Authority becomes state
An unfinished revocation is not buried as an event; the task remains attention-required until sensitive access closes.
Follow-up becomes explicit
Fix DNS, retry, rollback, revoke, review, or approve are derived from the current accountable state.
Emerging state taxonomy
A vocabulary users can learn.
Waiting
The agent needs approval, authentication, missing information, or a policy decision before consequential work can proceed.
Running
The approved task is executing under a visible authority lifetime, with cancellation and escalation policy defined.
Partial
Some required outcomes passed and others failed. The user sees both, plus the next bounded remediation action.
Failed
The requested outcome did not occur. The product states whether any side effect remains and whether authority is closed.
Unverified
Execution reported success, but required user-visible checks timed out, were unavailable, or returned ambiguous evidence.
Attention
Sensitive authority, unresolved risk, or a consequential decision remains open regardless of the execution result.
Rolled back
The requested change failed or was rejected, and the prior state was restored and independently checked.
Complete
All required outcomes passed, failures are resolved or accepted, and temporary authority is closed.
The market moves forward when users stop asking "what did all these updates mean?" and start seeing the answer.
Four market signals
What is pushing task state into the interface
ASYNCHRONY
Tasks outlive sessions
Users need to return later and understand the current task without replaying every event that occurred while they were away.
AUTONOMY
Agents choose intermediate steps
Event volume grows as agents navigate tools, but the product must preserve the stable intent and accountable outcome.
AUTHORITY
Access has a lifecycle
Temporary credentials, sessions, and delegated scopes create meaningful open and closed states that users need to see.
VERIFICATION
Tool success is insufficient
Independent checks can disagree with execution, requiring partial and unverified states instead of optimistic completion.
Product implication
The task object becomes the bridge across systems.
| Source system | Events it contributes | State contribution |
|---|---|---|
| Conversation | User request, clarification, approval, cancellation, and reply actions | Waiting, approved, cancelled, or follow-up requested |
| Identity and vault | Agent identity, token issue, scope, expiry, revocation, and session closure | Authority pending, active, expired, revoked, or attention required |
| Browser and tools | Execution milestones, policy blocks, provider responses, errors, and rollback | Running, failed, or execution complete pending verification |
| Verification | Public checks, artifact matching, link tests, delivery confirmation, and rollback validation | Complete, partial, unverified, failed, or rolled back |
| Messaging | Receipt composition, provider acceptance, delivery, fallback, and user replies | User informed, delivery pending, or follow-up opened |
Buyer checklist
How to recognize a task-state product
Stable task identity
Events from conversation, agent, authority, execution, checks, and delivery correlate reliably.
Evidence-derived states
The model cannot declare completion without required checks and closure.
Partial and unverified support
The product represents mixed or unknown outcomes without forcing a binary result.
Access-open visibility
Active sensitive authority remains prominent until revoked or explicitly accepted.
Immutable history
Corrections, retries, and remediation append linked tasks rather than rewriting the past.
Actionable next steps
Available actions follow the current state and undergo fresh policy evaluation.
Notifications say the agent was busy. Task state says whether the user's intent reached a safe, verified ending.
Applied to Super
Super can turn the message thread into a task-state interface.
Conversation with accountable state
The text-message AI assistant can preserve the familiar conversation while structured task state determines which updates matter. Approval needed, partial failure, access open, rollback, and verified completion can become recognizable message states.
For a computer-use cache, task state can distinguish retained safe browser setup from temporary sensitive sessions. Users can see whether authority is closed without interpreting cache events.
When an AI agent builds a website, Super can model preview approval, publishing, Render route verification, custom-domain failure, rollback, and deployment-access closure as explicit states instead of a noisy sequence of updates.
FAQ
Questions about the task-state shift
Does task state replace notifications?
No. Notifications deliver important state changes. The difference is that each notification points to a canonical task whose current state and history remain available after the alert disappears.
Should every agent task have all eight states?
No. Task types can use a relevant subset, but they should preserve distinctions between waiting, running, mixed outcomes, unresolved authority, and verified completion where those distinctions matter.
Can the language model derive state?
It can help interpret unstructured events, but consequential states should be confirmed by explicit rules and source evidence. The model should not invent verification, revocation, or completion.
How does state reduce notification fatigue?
Products can notify only on meaningful transitions and aggregate routine progress. Users can open the task for detail without receiving every intermediate event.
What is the most important state to add first?
Partial is often the highest-value addition because it prevents products from hiding mixed outcomes behind success. Attention for still-active sensitive authority is equally important in privileged workflows.
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 task and receipt access.