Architecture
Architecture and data flow
Proto coordinates work from a desktop workspace. Local storage and connected execution have different boundaries.
The desktop is the working environment
Proto is an Electron desktop application for macOS, Windows, and Linux. A workspace gives a task access to its local files and instructions. The agent selects actions, reads their results, and continues until it finishes, encounters a blocker, or is cancelled. Longer tasks can divide work into sub-agents with separate context.
Local session records preserve the conversation and action history for continued work. Workspace memory holds selected context across sessions, while skills hold reusable instructions. These are different from the live records in an external system or the contents of an ERP•AI app.
Follow the data, not only the interface
Using a desktop application does not mean that all processing happens on the device. A model request sends the messages and selected context needed for that step to the chosen model service. File excerpts, page content, or action results can become part of that context.
| Boundary | What happens there |
|---|---|
| Local workspace | Source files, generated artifacts, instructions, and workspace memory are read or written on the machine |
| Model service | Selected task context is sent for model inference through the managed plan or a configured provider |
| Built-in browser | Pages load from their websites; browser actions interact with the selected signed-in account |
| ERP•AI | Native operations read and change app resources under the user’s permissions; app task conversations are also saved to app history |
| Configured integration | A plugin receives the arguments and data needed for its requested action |
The destination matters as much as the action name. Reading a local file and uploading that file to a website are separate operations. A model-provider choice changes the inference destination; it does not change the service that owns an ERP•AI record or a browser session.
An action has several controls
The agent’s request passes through permission and policy checks before execution. The selected mode affects when a person is asked to review a confirmable action. Separate controls govern sensitive ERP•AI operations, and the receiving service still applies its own account permissions.
Operating-system permissions also apply to desktop capabilities. Native application control is experimental and disabled by default. The built-in browser is a distinct surface with its own profiles and sessions.
These layers should not be interpreted as a general-purpose sandbox for every tool. Shell commands and local integration processes can operate with the privileges available to their process. Evaluate the actual tools, accounts, folders, and destinations your task will use.
Choose where a repeatable process lives
A local task can combine research, analysis, and artifact creation. An ERP•AI app provides shared business records and interfaces. A saved ERP•AI workflow can run from an event or schedule. Those are different execution locations with different dependencies.
The released alpha does not expose every capability present in development source. Local-model selection and cloud-task controls are hidden in the release build. Do not plan an offline or remotely hosted rollout around those development capabilities.
Review one representative data path
For an evaluation, trace a real example from source to result. Identify the file or record read, the model destination, each external action, and where the output and conversation are retained. Use representative non-sensitive material until those choices match your requirements.
This gives technical and business owners a shared basis for deciding what Proto may handle, which account it should use, and what a completed task must demonstrate. The security overview explains the current action defaults and review boundaries.