A useful agent often needs to come back to work it started earlier. It may have downloaded a file, installed a tool or opened a browser session that matters to the next task. Rebuilding that environment for every request creates setup work for the team and makes continuity harder to manage.
Maritime provides managed environments for agents, with persistence as a central part of the product. Its public launch describes giving an agent its own working environment and managing the infrastructure around it, so a product team can concentrate on the agent’s task. [1]
From agent research to the environment around the agent
Maritime joined YC’s Fall 2026 batch. Founders Maria Gorskikh and Aryaman Shrivastava previously worked on agent-related research at MIT’s Project NANDA, according to the company’s public YC profile. [2]
The infrastructure problem becomes clearer when an agent moves from a demonstration to repeated use. The team needs to know which environment belongs to which user, what survives between tasks and how to inspect a failing instance. Those questions sit alongside the quality of the model itself.
Run an agent with a persistent workspace
Maritime’s current documentation describes an agent as a long-lived program in an isolated environment, with a persistent volume, encrypted configuration and a framework or container supplied by the team. Files on the persistent volume survive restarts and redeploys; files outside it can be disposable. [3]
Idle agents can sleep and wake for new work. The documentation notes that timers inside a sleeping process do not run, so scheduled work belongs in platform triggers. Hosting and model access are also separate: teams can use their own provider credentials or the supported model proxy, with model usage accounted for separately from hosting. [3]
For an internal research or operations agent, this can preserve the files and tools needed for a recurring task. The team still needs to decide what should be retained, how it is organized and when it should be removed. Persistence provides continuity; it does not decide a data-retention policy.
Give an existing agent a persistent desktop
Maritime also documents a Computers offering: a Linux desktop with a browser and office tools that an existing agent can operate through MCP. The model can run elsewhere while Maritime supplies the computer, preserving files and browser state between sessions. [4]
The guide describes a desktop associated with an end user and a way to pin the integration to that user’s identity. It also includes a takeover mechanism through which a person can complete a step, with agent actions blocked while the person is in control. The current documented offering is Linux; an older launch’s broader operating-system language should not be read as current availability for every platform. [4]
An illustrative workflow is an assistant that returns to the same working documents and browser context on later requests. The product team can keep its own model and task logic while using the managed desktop as a tool. Access to that environment still needs to follow the application’s user identity and permissions.
Inspect the individual worker, then manage the fleet
The public launch emphasizes the ability to inspect an individual agent’s environment while managing multiple agents. It describes both agents running inside the managed environment and externally hosted agents controlling a computer. Those are different deployment choices with a shared need for visible working state. [1]
For a product team serving several customers, the relevant question is whether a task can be traced to the correct environment and resumed without losing the necessary context. A support engineer should be able to distinguish an application error from a sleeping instance, a missing file or a provider problem.
A recurring reporting agent is another useful scenario. It can keep the files and dependencies needed for its work, while a platform trigger starts the next run. The team can examine the resulting artifact and logs rather than assume an available machine means a completed report. This is an illustrative use of the documented lifecycle, not a reported customer result.
Where Maritime fits on SOTA2
| Product & task | Position | Comparison scope |
|---|---|---|
| MaritimeExecute Code in SandboxesAgent | #5 | 12 companies · 14 candidates 10 ranked products |
What we would look for in a pilot
We would run one recurring task through sleep, wake, restart and redeploy, checking which files and state survive each event. Test a failed task and confirm that an operator can inspect the relevant environment without confusing it with another user’s instance.
For a desktop workflow, verify identity pinning, human takeover and the application’s access controls. Compare the full cost of hosting, storage and model use with the current setup, and measure the operational effort required to keep the workflow reliable.
The SOTA2 view
Maritime is relevant to teams whose agents need a continuing workspace or a real desktop across tasks. Its useful proposition is to manage that environment’s lifecycle while leaving the model and application workflow with the product team. A successful evaluation should demonstrate persistence, clear ownership and recoverable operations.