Proto for enterprise / Alpha
Give your team an agent to prepare reports, reconcile invoices, and work on your code. We’re building an enterprise alpha that runs on your infrastructure, connected to the systems and models you choose.
The Proto desktop app is available today. Agent environments on your own servers are in development for enterprise pilots; private and air-gapped deployments require setup, engineering, and validation.
Proto directs the work. VMYard manages the compute.
We’re building the enterprise alpha around VMYard, a control plane for virtual machines and containers. The aim: let Proto spawn agent work environments on servers your organisation operates, connect them to approved resources, and bring the results back to your team.
Define the task, the relevant repositories and business systems, and the result your team needs.
VMYard is the planned compute layer for starting, pausing, resuming, and retiring work environments across enterprise hosts.
Review the code, reports, and proposed changes. Put the outputs through your existing approval and release process.
Business work. Programming included.
Ask Proto to understand a service, implement a feature, fix a bug, or prepare a report. Keep the task connected to the files, systems, and people it affects.
Explore the documentationUse an approved checkout from your internal Git service. Proto can work through installed Git and development tools using access configured in your environment. Private host, credential, and pull-request workflows are validated during the pilot.
“Find why this invoice import fails. Add a regression test, fix it, and show me the diff.”
Read documents and spreadsheets, prepare reports, and work with supported ERP•AI tools or websites in Proto’s browser. Plan connections to Salesforce, SAP, Oracle, Sage, and other enterprise systems around the interfaces and permissions available in your environment.
Explore enterprise integrations“Compare this supplier file with the import schema. Explain the mismatch and prepare the changes.”
Run the compilers, test runners, and package tools installed on the workstation. Configure internal registries and artifact mirrors in those tools. Connected CI and self-hosted Git integrations require host-specific setup and testing.
Proto can route its main model requests to a custom OpenAI-compatible endpoint. Keeping an entire deployment inside your network requires a review of every other service it uses.
Desktop agentLocal work & task historySign-in, managed decision calls, model metadata, app and skill updates, automatic failure diagnostics, and tools can still contact public services.
Model requests contain the context needed for the task, which can include source code and file contents. ERP•AI-connected tasks can also save conversations in app history. The pilot must verify these data flows against your requirements.
Plan Proto around the intelligence your organisation runs. Pair a capable programming model with specialist services for decisions, evidence checks, and warehouse operations.
Host a compact decision model locally to classify requests, score records, and review proposed actions. It returns structured decisions for bounded tasks.
Explore SmallDecideCheck records and proposed actions against requirements and supporting evidence. Combine deterministic checks with local model judgment, return traceable findings, and keep unresolved checks visible.
Explore OpenAuditorReview receiving, reservations, packing, counts, and carrier requests against warehouse records and rules. A locally hosted specialist model helps return a verdict, supporting facts, and a clear next step.
Explore RackSortThese services can be hosted locally. Connecting them to Proto is part of the enterprise pilot: adapters, permissions, deployment boundaries, and workflow behaviour are configured and validated for your environment.
Start with a defined environment and a small set of workflows. Treat each deployment mode as a separate acceptance test.
VMYard is the planned compute layer for Proto agent environments on your enterprise servers. Configure the hosts, resource limits, repositories, models, and business-system access for a defined pilot.
The Proto-to-VMYard integration is being developed. Deployment scope and controls are agreed and validated with your team.
Proto runs on the user’s computer, with local files and development tools. Models and connected services may operate outside your network.
Pilot now with approved data, endpoints, and tool access.
Point the custom provider at a compatible internal model service. Validate tool calling, network trust, credentials, and model performance on your tasks.
A private model is a starting point. It is not a complete on-premises package.
The target is an environment with no public network access, including models, repositories, packages, identity, updates, and support processes. Connected applications must be available inside that boundary; public SaaS requires network access.
Requires an engineered distribution, internal dependency provisioning, and clean-install no-egress testing.
05 / Control
Existing desktop settings are useful controls for an individual user. Organization-wide enforcement needs a separate design.
Limit repository credentials, filesystem access, and network routes. By default, shell commands run with the operating-system permissions of the user; a Git worktree is not a sandbox.
Configure approval behavior explicitly. New installs use Uninterrupted mode. Keep consequential changes behind your existing review and release controls.
Define what may enter model context, where history is kept, and how secrets are provisioned, stored, rotated, and removed.
Assess SSO, provisioning, policy enforcement, and audit retention. Do not assume centralized enterprise controls are included in the current desktop release.
Questions before deployment
Proto directs the agent’s work; VMYard is the planned enterprise compute layer beneath it. The alpha architecture uses virtual machines or containers on enterprise hosts for agent work environments. This integration is in development and is not included in the standard desktop download.
Yes. It has tools to read, search, create, and edit code, and can invoke installed development tools to build and test a project. The results still need review, and model and toolchain compatibility matter.
It can work on a local checkout and use installed Git with your configured access. Validate your Git host, private certificates, credentials, and review workflow during the pilot. Native integration coverage varies by provider.
That is a deployment requirement to validate. A compatible internal endpoint can receive the main model requests, but auxiliary model calls, sign-in, tool access, diagnostics, and connected app history must also be assessed. The standard client does not provide a verified no-egress guarantee.
The standard download is not a validated air-gapped distribution. It requires engineering and acceptance testing across installation, identity, model access, tool dependencies, updates, and support. Offline activation and entitlement must also be defined and validated. Blocking the internet alone is not sufficient evidence.
No. The current desktop client requires ERP•AI sign-in. Running the client and a model inside your network does not automatically relocate identity, auxiliary services, diagnostics, metadata, or updates. A full on-premises deployment needs an agreed architecture and validation of each dependency.
Bring one internal repository, one business workflow, and your deployment requirements.
Discuss your environmentEnterprise deployment scope, support, and availability are subject to technical assessment.