An agent timeout is not a cancelled action: building Mothership

An agent asks to save a report. The request needs your approval. You step away, the client times out, and the server restarts.

When you return, should the agent submit the report again?

That is one of the problems I am working on with Mothership, an agent-focused workspace I am building at NextEleven. Agent clients use REST, MCP or a Python SDK to discover tools, work with scoped resources, keep checkpoints and pause for the owner when permission is needed.

The part I want to discuss here is what happens after the conversation stops.

Keep the action separate from the wait

A timeout tells the client that it stopped waiting. It does not tell it whether an action ran, whether an approval is still pending, or whether a remote service accepted a request.

In Mothership, a pending approval has an ID. If a local approval wait expires, the client keeps that ID and gets instructions to inspect the same approval. Stopping the wait does not cancel the remote request or submit another copy.

The intended flow is:

Request an action with a stable action key
    -> receive a pending approval ID
    -> stop waiting if the local budget expires
    -> inspect that same approval later
    -> recover its result when available

A server restart should preserve the approval, checkpoint and recorded result. If an external outcome is uncertain, a fresh action key is not a safe substitute for finding out what happened.

Check the effect, not just the message

For the latest installed-client check, we used fictional local memory writes. A short wait expired, the API process restarted, the same approval was inspected and approved, and the original result was read back. Reusing the original action key returned that recorded result without a second write. Separate checks covered asynchronous cancellation and denied requests.

That is a bounded local test. It does not establish exactly-once behavior for arbitrary payments, emails or browser actions. An external service can perform an effect before the connection disappears; those cases need provider-specific reconciliation.

The current implementation has 567 passing installed regression tests across our Mac and Linux validation, plus container and workflow checks. These are our own tests, not independent certification. We have also tried selected workflows with our own agent client; a separate external operator trial is still ahead.

Built for the agent as the user

Mothership currently has 136 tools in 25 categories, declared through one registry. The point of that registry is consistent discovery, input contracts and error handling across interfaces. A connected agent asks what it can use and reads the schema it needs. Owner controls handle permissions and exceptions.

DeadBolt can provide an optional local admission check, and Witness can retain explicitly labelled Generated records. Those integrations have narrow boundaries: they do not create whole-agent isolation or turn generated text into verified evidence.

Where it stands

This is a self-hosted, single-process SQLite pilot. The core repository is currently private while I work through the hosting and licensing decisions. There is no hosted signup or public package release yet.

I would value concrete feedback from people building agents: what should your client retain when it stops waiting for approval, and how do you distinguish a pending action from an unknown outcome?

A fictional example or a failure case would be especially useful. Please keep credentials and private customer data out of comments.