Data architecture
Local storage and model data flow
Where a session is stored and where its task context is processed are separate questions. A useful architecture review answers both.
Start with three boundaries
Proto runs on your computer, where it stores files, sessions, and memory. To perform a task, it sends the AI model the context needed for each step. It can also read or change information in connected applications. These are three different boundaries: storage on the device, processing by the model, and work in an application.
Calling a product local-first is not enough to evaluate a sensitive workflow. The useful questions are what the task needs to read, which model receives context, which application receives changes, and where the resulting history is retained.
Follow a concrete task
Consider an illustrative task that reads a local invoice export and prepares an exception tracker in ERP•AI.
| Stage | Boundary to understand |
|---|---|
| Read the supplied export | The file is on the user’s computer and is made available to the task |
| Analyze the relevant records | Task context is sent to the selected AI model as the agent works |
| Create or update the tracker | Authorized actions write to the connected ERP•AI app |
| Review the session later | Proto keeps local session history; work in ERP•AI also saves the conversation to the app’s history |
The local original and the remote application record can coexist. Deleting or moving one should not be assumed to remove the other. Review retention in each system that actually receives information rather than inferring it from where the task began.
Model selection is a data-flow decision
Proto uses ERP•AI’s managed AI plan by default. You can also configure your own supported provider key or use Codex with a ChatGPT account. The models and keys guide explains the available setup paths.
Choosing a model changes more than response style. It changes the service handling model requests and the terms and controls that apply to that service. Review the arrangement your organization intends to use, including account ownership, permitted information, retention, and any required regional processing. This article does not assert a common retention policy or deployment region across providers.
Browser work has its own destination
Proto’s built-in browser can work in websites you are signed in to. A task that reads a CRM page or sends a message through webmail interacts with that website and its account context. Local session storage does not make those remote actions local.
Establish which account the browser is using and whether the task’s access is appropriate. For review before supported consequential actions, turn off Uninterrupted mode, leave Plan mode, and read the approval controls. Permission to read a source and permission to publish a result are separate decisions in the workflow you design.
Prepare an architecture review with evidence
A useful evaluation uses a representative task and maps its actual sources and destinations. Record the files provided, model configuration, applications used, output artifacts, and review points. Check the output and the destination application after the task. Use that evidence to answer security questions about the proposed use, rather than extending one successful demonstration into a general assurance.
Proto is alpha software. Validate the version and configuration you plan to use, and revisit the assessment when either changes. The security overview distinguishes product behavior from organizational controls and information that needs further verification. Local storage is an architectural property; it is one part of the full data-flow assessment.