Build apps that generate, reason, and act.

AI, built in, not bolted on

A Remy app isn’t only software. It’s software that generates content of every kind, reasons over the data it already holds, and runs agents of its own that take real action. That’s the kind of app a workforce builds now, and on Remy it’s the default, not a special project.

The usual way to add this is a project in itself. Text is one vendor, images another, transcription another, video another, each with its own SDK, its own keys to store and rotate, its own rate limits, its own line on the bill. Getting a single AI feature into production means wiring up and securing all of that before the feature itself exists.

Part of the platform, not an integration

Calling a model isn’t something a Remy app connects out to. It’s a capability of the platform the app already runs on. The app makes one call; the platform picks the model, runs it, meters it, and hands back a result the app can use. Three things follow, and none of them are the developer’s work:

No credentials in the app

The app never holds a provider key. There’s no vendor SDK to install, nothing to rotate, and nothing to leak.

One interface across every vendor

The same call shape reaches OpenAI, Anthropic, Google, and the rest. Switching models means changing an identifier, not rewriting an integration.

One metered edge

Because model calls route through the platform rather than out to a provider directly, every one is measured, attributed, and auditable. That’s the same chokepoint that produces the app’s unit economics and its audit trail.

Agents that belong to the app

Beyond single calls, the SDK can run agents of its own: agents that live inside the app and run when it does.

Task agents

A multi-step loop where an agent works toward a goal by calling tools, built right in. Give it a prompt, some starting input, a set of the app’s own actions it can use as tools, and a model. It reasons and calls those tools across as many turns as the work needs (20 by default, up to 100), so it finishes the job without running indefinitely. It shows its thinking and the tools it uses as it goes, remembers where it left off between runs, and reports exactly which tools it called and the tokens and cost it used. Because the tools are the SDK, one agent can search the web, generate an image, post to Slack, and write to the app’s database inside a single loop.

Packaged agents

Full MindStudio agents and workflows can be run from within an app, so a more involved automation is callable as a single step.

That’s the difference between an app that calls AI and an app that is an agent, and both are written in the same SDK.

Bring your own models

Everything above is the platform’s own model layer, and for most teams it’s all they’ll need: every model, one bill, no keys to manage. But an organization with its own model strategy or its own data-boundary requirements isn’t locked into it. Control escalates as far as it needs to:

Bring your own key

Route model calls through the organization’s own provider accounts, under its own contracts and terms. The same call, a different account behind it, and app code that doesn’t change.

Custom and self-hosted models

Register a model the organization hosts or has contracted, a fine-tune, a private or region-specific deployment, and call it the same way as any model in the catalogue.

Local, tunneled models

Reach a model running on the organization’s own hardware or inside its own network over a secure tunnel, so prompts and data never leave that environment at all.

Keys, routing, and usage are governed from the organization dashboard, not scattered across apps. The model layer is a choice, not a lock-in: the managed catalogue for reach, or the organization’s own infrastructure where policy requires it, without changing how apps are written.

Easy for the builder, accountable for the organization

Every model call goes through the platform. Nothing routes around it, which is what makes the rest of this true:

Private by default

Default models run under enterprise agreements, and the data an app sends is not used to train the provider’s models. Zero data retention applies wherever the provider supports it. Where a provider requires a short retention window, that period and the model’s training status are disclosed per vendor. The few models that do train are opt-in only, never a default. For absolute assurance, bring your own models: the data falls under your organization’s own contract, or stays entirely inside your own network.

Metered

The exact cost of every call is captured at the source and attributed by method, user, and model, split between building the app and running it. That’s true unit economics, not a provider bill reverse-engineered later. See the Audit Log deep dive.

Audited

Model use is activity on the platform edge, recorded like any other action: who ran what, when.

No scattered keys

With credentials held by the platform rather than pasted into apps, there’s no sprawl of provider keys across a fleet of tools to inventory, rotate, or lose.