Integration architecture
Build around Proto and ERP.AI
Understand the desktop agent, the ERP.AI platform, and the verification steps that turn a prototype into a usable integration.
Proto is the desktop agent that runs a user’s task. ERP.AI is the connected platform that owns business apps, records, workflows, permissions, and hosted output. Choose the surface according to who initiates the work and where the resulting state belongs.
Choose an integration path
| Need | Starting point |
|---|---|
| A person wants help with files, research, or business work | A Proto task with explicit inputs and expected output. |
| The same procedure should be reusable across tasks | A skill with instructions, references, and validation steps. |
| Business records should live in an application | An ERP.AI app with its schema, views, roles, and source records. |
| Work should run from a schedule or record event | An ERP.AI workflow with a tested trigger and configured connections. |
| External software needs programmatic access | The deployed ERP.AI service contract and a scoped integration identity. |
These guides do not define a public HTTP API for controlling the Proto desktop app. Internal desktop tools, command names, and development services are implementation details, not a supported external endpoint contract.
ERP.AI’s Headless SaaS overview describes the shared service boundary used by its web app, Proto, hosted pages, and approved integrations. Obtain actual endpoint locations, credentials, and request/response contracts from the documentation for the environment you are integrating with.
Start with a small observable result
For an app integration, choose one table and a small set of synthetic records. Define what a successful read or write looks like before adding background execution.
For example, a supplier-review prototype might read two quotes, create a comparison record, and attach the source references. Its first acceptance check should confirm that the record exists in the intended app and contains the expected values. Adding an email notification is a separate behavior with a separate observable result.
Record the identity, organization, app, and environment used for the test. A successful request against a draft or test environment does not establish a production deployment.
Keep instructions and access distinct
A skill is a useful place for field meaning, business rules, and verification steps. It is not a place to embed service credentials. A working model connection is also separate from the identity that reads or writes business records.
Use the installed release as your compatibility baseline. The current standard release hides plugin-management controls and local-model setup. Configured MCP servers can still load; the integrations overview explains that configuration path. Development examples for hidden controls should not be presented as general installation instructions.
Define completion as a checked outcome
Ask an integration to report the saved record, generated file, workflow execution, or deployed page that proves the requested result. Preserve uncertain outcomes and reconcile them before retrying consequential actions.
For the next step, follow ERP.AI integration. To package a repeatable operator procedure, start with Skills.