RumataAgent reference: build on Rumata
Start here for the technical contracts, rules and capabilities that AI agents and developers need when building apps on Rumata.
Step-by-step guidance.
Before you start
- A task that builds or changes an app on Rumata: accounts, a backend, data, files, workflows or AI.
How to use this reference
- Find your task in Find the guide for your task and read that guide’s Essentials first.
- Open its Technical details when you need exact routes, fields, limits or tool names.
- Before you tell a user that something is impossible, unavailable or available, check Platform capabilities.
- Cite the section URL you relied on. Every section has a stable address of the form `/guides/<slug>#<section-id>`.
This reference describes what Rumata provides and how to build on it. It does not read an account, run product actions or replace live verification: always confirm behavior in the running app, as described in Verification protocol.
Read fact statuses
Statements of capability use one of these labels. Report them as written; do not upgrade or downgrade them.
| Status | Meaning | How to say it to a user |
|---|---|---|
| Provided | A ready module or platform feature exists. | State it plainly and cite the section. |
| Buildable | Not shipped as a module; you write it on the cloud capabilities Rumata provides. | Say it can be built, and describe the path in Platform capabilities. |
| Agent rule | A build convention agents follow for security, cost or reliability. | Describe it as a rule for how the app is built, not as a platform limit. |
Separate rules from limits
Many instructions to agents are written as absolutes: “never”, “do not”, “always”. Most of them are agent rules that keep apps secure and consistent. They are not automatically product limits, and a user should not be told that Rumata “cannot” do something just because an agent is told not to.
| Wording an agent sees | What it is | What it does not say |
|---|---|---|
| Use the native accounts for email and password sign-in. | Agent rule. | That no other sign-in method can be built. See the support table. |
| Do not run an unconditional cron to poll a backend. | Agent rule about cost. | That cron triggers are unavailable. Cron is supported. |
| Never put credentials in frontend code. | Agent rule. | That the app cannot call providers. Server-side secrets are supported. |
Find the guide for your task
| I need to… | Read |
|---|---|
| Build a new full-stack app from a request | Build a full-stack app |
| Find the exact tool for a capability | Tool catalog |
| Build or connect a frontend | Frontends |
| Connect a backend and a workflow, or use API keys | Connect backends and workflows |
| Run a generation or ETL job that must survive failures | Durable jobs |
| Use a standard activity or build a custom one | Activities |
| Release an app | Deployment and release |
| Diagnose an error | Agent troubleshooting |
| Add sign-up, sign-in or per-user data | Accounts and authentication |
| Host an API, container or worker | Backends and bindings |
| Store records, run SQL or enable an extension | Database |
| Upload, list or download files | File storage |
| Orchestrate ETL, cron, connectors or durable jobs | Workflows and connectors |
| Add AI behavior or an assistant that uses app data | AI agent steps |
| Prove that something works | Verification protocol |
| Work through the public MCP without a development machine | External MCP capability map |
| Answer “can Rumata do X?” | Platform capabilities |