Execution and recovery

A run belongs to the account, not to the screen displaying it. This makes a personal agent useful when a phone sleeps, a browser reloads or a worker restarts.

From message to result#

1. The client saves its command with a stable clientMessageId and posts it to the Impo API.
2. The API validates the request and owner. Command acceptance and queue admission commit together.
3. A worker claims the work under a lease and sends the accepted input to the owned Rebyte Session.
4. Rebyte produces text and tool calls. The worker dispatches tools through Impo's registry and persists results before acknowledging them upstream.
5. Clients subscribe to projected events. On reconnect they recover saved history and active submission state.

The stream uses the shared application protocol. A transport close is not proof of completion. Clients reconcile truncated streams rather than guessing the outcome.

Main Chat and Tasks#

Main Chat uses one Saved Agent per user and a current Session. Session rotation bounds active context while keeping the entire conversation readable through historical bindings. Current defaults rotate before unsent input after six idle hours, eight turns or the configured context estimate threshold.

Tasks use independent Sessions. They do not receive foreground native-device tools or recursive task-creation tools. Their catalog is deliberately narrower than Main Chat's. Adding a tool to the server registry does not automatically expose it to every execution context.

Tool side effects#

Each tool definition declares a timeout and retry policy. A read can generally be repeated. A transactional operation needs a durable idempotency receipt. An operation that moves hardware or plays audio may have an uncertain outcome and must not be repeated blindly.

Agent text is not a receipt. The UI should report completion from accepted execution state, and a tool should distinguish an accepted request from its eventual physical outcome.

Worker and provider recovery#

Leases fence expired workers so they cannot overwrite a replacement's result. Agent and Session creation intent is persisted before remote creation. When a remote response is lost, reconciliation checks what already exists before trying again.

An ambiguous outcome stays pending reconciliation. Creating another remote resource merely because the connection failed can duplicate work.

Cancellation and scheduling#

Closing a view only removes its subscription. An explicit cancellation command asks the execution layer to stop; the final state follows reconciliation with the remote turn.

Temporal owns scheduled triggers and durable background coordination. Scheduled-task revisions fence old timers, and overlapping occurrences are skipped. Keep timers separate from the ordinary task execution they admit.

Follow the implementation#

• Client protocol: commands, events and recovery.
• Runtime repository: durable admission and state.
• Rebyte repository: provider bindings and execution.
• Scheduled tasks: revisions, overlap and occurrence admission.