Inside an app
Understand the records, interface, agent tools, and access rules that make an app useful.
manifest data model permissions tools skills notifications resourcesOn this page
One app, several surfacesRecords belong to a business domainTools make the app usable by agentsSkills explain the workflowAccess follows the action and recordBuild for the whole workflowOne app, several surfaces
An Opser app is more than a page in the sidebar. It brings together records, a human interface, and the capabilities it exposes to agents and other apps. Its manifest describes those surfaces so the platform can discover and govern them.
Not every app needs every surface. A small reference app may only provide screens and reads. An operational app may also provide changes, events, notifications, integrations, and agent guidance.
| Part | What it does |
|---|---|
| Records and rules | Define the information the app owns, its validation, and allowed changes |
| Views and actions | Let people find records and carry out the workflow |
| Agent tools | Let an agent perform named actions with structured inputs |
| Skills | Explain when and how to use the app's capabilities |
| Permissions and resources | Control access to actions and, where implemented, individual records |
| Contracts | Offer named operations to other parts of the workspace |
| Events | Announce changes to subscribing workflows |
| Notifications | Bring a change or decision to a person's attention |
Records belong to a business domain
An app owns its data model and the rules around it. When an agent builds an app, it defines the records and relationships needed by that workflow. Updating a live app needs to preserve existing records as well as introduce the new behavior.
Apps do not gain unrestricted access to each other's database tables. To reuse information another app owns, they call an operation that app exposes. This keeps the owning app's rules in the path. User-managed datasets have a separate data and reporting surface.
Tools make the app usable by agents
An agent tool is an action with a name, a description, and structured inputs. An equipment app could expose actions to find an asset, create a checkout request, or record a return. These are examples of a design, not a promised app catalog.
The platform discovers the tools from the loaded app and checks access when they are listed and invoked. An action can also require approval. For an interactive shared-agent request, the initiating person's access matters alongside the agent's access; membership alone is not permission to every record.
Ask the builder to make the human interface and agent tools use the same service rules. Review both paths: a working form does not prove the agent can complete the workflow.
An app can also expose searchable primary records to workspace search. Include that behavior when you want people to find its records from the workspace's search control.
Skills explain the workflow
An app can provide instructions about its concepts, required inputs, and preferred sequence of actions. This helps the agent choose the right tool and interpret the result. Installing a skill does not grant the permissions that its tools need.
For example, a checkout skill might explain that an asset must be available before a request can be approved, and that recording a return should close the active checkout. Read Built-in skills for the difference between instructions and execution.
Access follows the action and record
Apps declare permissions, and can bind actions to resource rules for ownership, sharing, or other relationships. Access can therefore be narrower than the ability to open an app. A person who can view requests may still be unable to approve one.
When reviewing a custom app, test with the intended roles and with someone who should not see the record. Include agent calls in that review. Permissions & access groups explains the workspace controls.
Build for the whole workflow
Specify the records, screens, agent actions, access rules, notifications, and connections when you brief the agent. The builder's readiness checks inspect declared capabilities as well as the build. Then try the workflow yourself, including missing data and rejected actions, before installation.
Continue with connected apps or the app building guide.