One Method, Eight Interfaces: How Remy Apps Run Everywhere at Once

At a Glance

• One method, eight interfaces: A single backend method in Remy automatically projects onto web, REST API, Discord, Telegram, MCP, cron, webhook, and email—no integration shims required.
• The method is the contract: Methods define typed inputs, outputs, and logic. The platform handles routing, auth, and serialization for every interface.
• Real example: A submitVendorRequest method powers a web form, a Discord slash command, a Telegram bot, an MCP tool for Claude Desktop, a Stripe webhook, a nightly cron job, an email handler, and a REST endpoint—all from the same 50 lines of TypeScript.
• Why it matters: You describe what the app does once. The platform makes it accessible everywhere. No per-interface rewrites, no API gateway configuration, no bot framework boilerplate.
• Built on MindStudio infrastructure: 200+ AI models, 1,000+ integrations, managed databases, auth, deployment—years of production substrate now powering Remy’s spec-driven architecture.

Most full-stack apps are built interface-first. You write a web frontend, then bolt on an API, then add a Discord bot as a separate project with its own auth and database calls. Each interface is a new integration surface, a new maintenance burden, a new place for bugs to hide.

Remy inverts this. You define methods—the application’s contract—and the platform projects them onto every interface automatically. One method becomes a web button, a Discord slash command, a Telegram bot action, an MCP tool, a webhook receiver, a cron job, an email handler, and a REST endpoint. Same logic, same auth, same database, eight surfaces.

This is the most underrated architectural payoff of what Remy actually is: a product agent that compiles annotated markdown into a full-stack app. The spec describes methods. The platform makes them universally accessible. You never write integration code.

What Does “One Method, Eight Interfaces” Actually Mean?

A method in Remy is a backend function with a typed signature. It declares inputs, outputs, and logic. Here’s a simplified example:

export async function submitVendorRequest(
  input: { vendorName: string; requestDetails: string; urgency: 'low' | 'medium' | 'high' },
  context: MethodContext
): Promise<{ requestId: string; status: string }> {
  // Validate input
  if (!input.vendorName || !input.requestDetails) {
    throw new Error('Vendor name and request details are required');
  }

  // Insert into database
  const request = await context.db.vendorRequests.insert({
    vendorName: input.vendorName,
    requestDetails: input.requestDetails,
    urgency: input.urgency,
    status: 'pending',
    submittedAt: new Date(),
    submittedBy: context.user?.id || 'anonymous'
  });

  // Notify the procurement team via email
  await context.integrations.sendEmail({
    to: 'procurement@company.com',
    subject: `New ${input.urgency} priority vendor request`,
    body: `Vendor: ${input.vendorName}\n\nDetails: ${input.requestDetails}`
  });

  return { requestId: request.id, status: 'submitted' };
}

That’s it. Fifty lines of TypeScript. No routing config, no HTTP handlers, no bot command parsers, no webhook signature verification. The method is the contract. The platform does the rest.

How the Same Method Powers Eight Interfaces

Once submitVendorRequest is defined in the manifest, it’s automatically available on every interface Remy supports. Here’s what that looks like in practice:

1. Web Interface

The web frontend can call the method directly from a React component:

import { useMethod } from '@mindstudio-ai/interface';

function VendorRequestForm() {
  const submitRequest = useMethod('submitVendorRequest');

  const handleSubmit = async (formData) => {
    const result = await submitRequest({
      vendorName: formData.vendor,
      requestDetails: formData.details,
      urgency: formData.urgency
    });
    console.log('Request submitted:', result.requestId);
  };

  return <form onSubmit={handleSubmit}>{ /* form fields */ }</form>;
}

The platform handles serialization, auth token passing, and error boundaries. The method runs server-side. The frontend just calls it.

2. REST API

The same method is exposed as a REST endpoint at /api/submitVendorRequest. Any HTTP client can POST to it:

curl -X POST https://yourapp.msagent.ai/api/submitVendorRequest \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "vendorName": "Acme Corp",
    "requestDetails": "Need 500 units by Q2",
    "urgency": "high"
  }'

No API gateway config. No OpenAPI spec generation. The method signature is the API contract. The platform enforces types, validates input, and returns typed JSON.

3. Discord Bot

The method becomes a Discord slash command automatically. A user types /submit-vendor-request in any channel where the bot is present, fills out the modal, and the method runs:

/submit-vendor-request vendor:"Acme Corp" details:"Need 500 units" urgency:high

The bot replies with the result. No discord.js boilerplate, no command registration, no manual parsing. The platform maps method parameters to Discord’s slash-command argument types and handles the interaction lifecycle.

For more on how AI agents integrate with messaging platforms, see how to set up Claude Code Channels with Telegram—the same multi-interface principle applies when connecting AI agents to communication tools.

4. Telegram Bot

Same method, different bot platform. A Telegram user sends /submitvendorrequest to the bot, and the platform presents an inline form. The user fills it out, taps Submit, and the method executes. The bot sends back a confirmation message with the request ID.

No Telegram Bot API wrangling. No webhook setup. The method is the interface.

5. MCP (Model Context Protocol) Tool

The method is exposed as an MCP tool. If you connect the app to Claude Desktop (or any MCP client), Claude can invoke submitVendorRequest as a tool during a conversation:

User: "Submit a vendor request for Acme Corp, we need 500 units urgently."

Claude: [calls submitVendorRequest tool with parsed parameters]

"I've submitted the vendor request. The request ID is req_abc123 and the status is 'submitted'. The procurement team has been notified."

The platform registers the method as an MCP tool automatically. The tool schema is derived from the method signature. Claude (or any MCP client) sees it as a callable function. For a deeper look at MCP-based agent architectures, see what OpenClaw is and how it connects to messaging apps.

6. Cron Job

Methods can be scheduled. If you want to run submitVendorRequest every night at midnight to auto-generate a summary report, you declare a cron trigger in the manifest:

{
  "cron": [
    {
      "schedule": "0 0 * * *",
      "method": "submitVendorRequest",
      "input": { "vendorName": "Daily Summary", "requestDetails": "Auto-generated", "urgency": "low" }
    }
  ]
}

The platform runs it on schedule. No cron daemon config, no separate worker process. The method is the job.

7. Webhook Handler

The method can receive webhooks from external services. If Stripe sends a checkout.session.completed event, you can route it to submitVendorRequest (or any method) by declaring a webhook trigger:

{
  "webhooks": [
    {
      "path": "/webhooks/stripe",
      "method": "submitVendorRequest",
      "transform": "stripeCheckoutToVendorRequest"
    }
  ]
}

The platform verifies the webhook signature, transforms the payload, and invokes the method. You write the transform function if needed. The method stays the same.

8. Email Handler

Methods can be triggered by inbound email. If you want users to submit vendor requests by emailing requests@yourapp.msagent.ai, you declare an email trigger:

{
  "email": [
    {
      "address": "requests@yourapp.msagent.ai",
      "method": "submitVendorRequest",
      "parseBody": true
    }
  ]
}

The platform parses the email, extracts structured data (using an LLM if needed), maps it to method parameters, and runs the method. The sender gets a reply email with the result.

One method. Eight surfaces. Same logic, same database, same auth, same error handling. You define the contract once. The platform projects it everywhere.

Why This Matters: The Interface-Agnostic Application

Most apps are built interface-first. You design a web UI, then realize you need an API for mobile, then add a Slack bot because your users asked for it, then bolt on webhooks for Stripe. Each addition is a new integration project. Each one duplicates logic, reintroduces auth bugs, and adds maintenance overhead.

Remy inverts this. The method is the source of truth. Interfaces are projections. You describe what the app does—the contract—and the platform makes it accessible however users want to interact with it.

This is what “full-stack” actually means in a product-agent architecture. Not “frontend + backend,” but “one contract, every surface.” The app isn’t a website with an API bolted on. It’s a set of methods that happen to be callable from a website, an API, a bot, a cron job, an email, and an AI agent’s tool palette.

For developers used to building an AI marketing company with Paperclip and Claude Code where each component has its own interface and integration layer, this is a fundamentally different model. The method is the agent’s action surface. The platform handles the rest.

How Remy Generates This Architecture

You don’t write the method signatures by hand (though you can). You describe the app in a spec—annotated markdown that says what the app does—and Remy compiles it into methods, database schemas, frontend components, and interface declarations.

Here’s what that looks like in practice. You tell Remy:

“I need an app where employees can submit vendor requests. They should be able to do it from the web, from Slack, or by email. Each request needs a vendor name, details, and an urgency level. When someone submits a request, notify the procurement team and log it in a database.”

Remy generates:

• A submitVendorRequest method with typed parameters
• A vendorRequests database table with the right schema
• A web form that calls the method
• A Discord bot command (if you said Slack, it adapts—Discord and Telegram are the current bot integrations)
• An email handler at requests@yourapp.msagent.ai
• An MCP tool definition for Claude Desktop
• A REST endpoint at /api/submitVendorRequest

All from one conversational description. The spec is the source of truth. The methods are compiled from the spec. The interfaces are projections of the methods. You never write integration code.

This is the architectural payoff of spec-driven development. The abstraction layer is high enough that “make it accessible from Discord” isn’t a new project—it’s a manifest entry the agent generates automatically.

What You Can Build with This

Internal Tools with Multiple Entry Points

An approval workflow where managers can approve requests from the web, from Slack, or by replying to an email. Same method, three surfaces. No per-interface rewrites.

AI Agents with Tool Access

An AI assistant (via MCP) that can query your CRM, create tasks, send notifications, and update records—all by calling methods your app already exposes. The agent doesn’t need custom API clients. It just calls tools. The tools are your methods.

Webhook-Driven Automation

A Stripe integration that creates invoices, updates subscription status, and notifies users—all by routing webhook events to methods. No separate webhook handler service. The methods are the handlers.

Scheduled Jobs with Shared Logic

A nightly report generator that calls the same generateReport method a user can trigger from the web. Same code path, same validation, same output. One runs on a button click, one runs on a cron schedule.

Conversational Interfaces

A Discord or Telegram bot where users can check order status, submit feedback, or request support—all by invoking methods via slash commands. The bot is a projection of the app, not a separate codebase.

For more on how conversational AI agents can control other systems, see Claude Code Dispatch and how to remote control your AI agent from your phone—the same principle of method-as-interface applies when agents orchestrate across tools.

The Platform Substrate That Makes This Possible

This architecture isn’t new infrastructure built in the last six months. It’s built on the MindStudio platform—a mature, production-hardened substrate that powers production apps for The New York Times, ServiceNow, and HMRC, with these capabilities baked in:

• 200+ AI models available as integrations (OpenAI, Anthropic, Google, Mistral, local models via Ollama)
• 1,000+ external service integrations (Stripe, Twilio, SendGrid, Airtable, Notion, Slack, Discord, Telegram, and more)
• Managed databases (serverless SQL with per-tenant isolation, automatic backups, per-release cloning)
• Auth system (email/SMS verification codes, cookie sessions, role-based access control)
• Deployment pipeline (git-native, atomic releases, instant rollback, per-release database snapshots)
• Interface runtime (web CDN hosting, bot command registration, MCP server, webhook verification, cron scheduler, email parsing)

Remy didn’t invent multi-interface projection. It’s a design pattern the platform has supported for years. What Remy adds is the agent layer—the ability to describe an app in a spec and have the agent generate the methods, the database schema, the interface declarations, and the frontend, all in one compile step.

The substrate is why Remy apps ship with Stripe webhooks, Telegram bots, and MCP tools out of the box. The platform already knows how to do all of that. The agent just has to declare it in the manifest.

Comparison: How Other Tools Handle Multiple Interfaces

Tool	Web	REST API	Discord	Telegram	MCP	Cron	Webhook	Email
Remy	✓	✓	✓	✓	✓	✓	✓	✓
Retool	✓	✓ (manual)	✗	✗	✗	✓ (workflows)	✓ (workflows)	✗
Bubble	✓	✓ (manual)	✗	✗	✗	✓ (backend workflows)	✓ (API connector)	✗
Lovable/Bolt	✓	✗	✗	✗	✗	✗	✗	✗
Cursor/Claude Code	Manual	Manual	Manual	Manual	Manual	Manual	Manual	Manual

Low-code tools (Retool, Bubble) support some of these interfaces, but each requires separate configuration. You build a web app, then add a workflow for webhooks, then configure an API endpoint. Each is a distinct project.

AI app builders (Lovable, Bolt, v0) generate web frontends. No backend, no API, no bot integrations. If you want those, you’re writing them yourself.

Coding agents (Cursor, Claude Code) can help you write the integration code faster, but you’re still writing it. Discord bot boilerplate, Telegram webhook setup, MCP tool registration—all manual.

Remy generates all of it from the spec. One method, eight interfaces, zero integration code.

FAQ

Can I disable specific interfaces if I don’t need them?

Yes. The manifest declares which interfaces are active. If you don’t want a Discord bot, don’t declare Discord in the interfaces array. The method still exists; it’s just not exposed on that surface.

What if I need custom logic per interface?

You can check context.interface inside the method to branch on the calling interface. For example, return a shorter message for Discord, a longer one for email. But most of the time, you don’t need to. The method logic is the same; the platform handles serialization.

How does auth work across interfaces?

The platform enforces the same role-based access control on every interface. If a method requires the admin role, a web user, a Discord user, and an API caller all need that role. The auth token (cookie, bot user ID, API key) is validated before the method runs.

Can I call methods from other methods?

Yes. Methods can call other methods. The platform handles the execution context. This is how you build composed workflows—one method orchestrates several others.

What happens if a method throws an error?

The platform catches it and returns a typed error response on every interface. The web frontend sees a JSON error. The Discord bot replies with an error message. The REST API returns a 400 or 500 with a JSON body. The MCP client sees a tool error. Same error, different serialization.

Can I add a ninth interface?

If the platform supports it, yes. The current eight are the ones Remy apps ship with today. The architecture is extensible—new interfaces can be added to the platform without changing existing methods.

How do I test methods locally?

The Remy CLI runs a local dev environment. You can call methods from the web preview, from a local Discord bot (via the platform tunnel), or directly from the terminal using the CLI’s invoke command. The local database is isolated from production.

What’s the performance overhead of this abstraction?

Minimal. The platform routes the request to the method, validates input, runs the method, and serializes output. The overhead is a few milliseconds. The method itself is normal TypeScript running in a Node environment—no performance penalty.

Can I export the code and run it elsewhere?

Yes. The generated TypeScript is yours. The methods are standard async functions. The database is SQLite (portable). The frontend is Vite + React (or any framework). The runtime-specific parts (the interface projections, the auth system, the deployment pipeline) are tied to the MindStudio platform. See the vendor lock-in discussion in the Remy docs for the full graduated-portability breakdown.

What Is Remy?

Remy is a product agent that compiles annotated markdown into a full-stack app—backend, database, frontend, auth, tests, and deployment—in a single step. See goremy.ai.

The one-method-eight-interfaces architecture is one of the clearest examples of what “product agent” actually means. You describe what the app does. The agent generates the contract (methods). The platform projects that contract onto every surface users might interact with. You never write integration code. You never configure API gateways. You never parse webhook payloads by hand.

You describe the app. Remy compiles it. The platform runs it everywhere.

Start building with Remy →