Skip to main content

Serverless Agents: from idea to API

Every product that ships an agent-powered feature ends up rebuilding the same parts: the agent loop, the tool layer, state, scheduling, retries, logs. None of that is your product.

This guide takes one worker from a sentence to a live API endpoint your code can call. Two routes, same result - pick whichever you already live in:

  • In the web app - describe it in chat, freeze it, copy the snippet.
  • From your coding agent - Claude Code, Cursor, Codex or anything else that speaks MCP.

The end state is identical either way: a frozen agent with its own id, declared inputs and outputs, and a callable endpoint.

Route A - in the web app​

1. Describe the worker​

Open app.flymy.ai, hit New Agent, and write what it should do in plain language. Attach the tools it needs from Creation tools - or just say what it needs and let the agent find them.

Describing an agent in the composer

The model picker and effort control sit under the message box. Keep talking to it in the same chat until the run does what you want - this chat is the training surface, not a one-shot prompt.

2. Open "Run it"​

Once a run has produced the result you want, switch the right rail to Run it. This is where a working chat becomes a callable thing.

The three ways an agent can run

Three modes:

ModeWhat it gives you
On a scheduleRuns on a cron you pick, laptop closed
On an eventRuns when something external fires
For developersFreezes the agent and hands you an API call

Pick For developers.

3. Variables, then compile​

Variables and compile

Step 1 - VARIABLES (optional). Declare the inputs the same agent should accept on later runs, and the outputs it should return. In the screenshot the agent takes date and topic and returns podcast_link and thumbnail_link. Skip this if the worker always does exactly one thing.

Step 2 - COMPILE. Freezing turns the conversation into a fixed instruction and pins the variables as placeholders - {{ date }}, {{ topic }} - so the same agent can run with different parameters. You get a numbered freeze (Freeze #66 · compiled).

From here you can re-compile with different variables, read the frozen instruction, or run it once from the UI before wiring anything up.

4. Take the code​

Step 3 - INTEGRATE hands you a ready-to-run snippet against the freeze you just made - no ids to look up by hand.

The integrate step with a ready snippet

# pip install flymyai
from flymyai import AgentClient, VariablesValidationError

client = AgentClient(api_key="fly-***")

# Already frozen via the UI - compilation #66.
frozen_id = 66

try:
    run = client.compilations.run_instruction_and_wait(
        frozen_id,
        variables={"date": "...", "topic": "..."},
    )
except VariablesValidationError as err:
    print(err.field_errors)
    raise

print("Status:", run.status)
print("Result:", run.output)

Variables are validated against the schema you declared, so a caller that sends the wrong field gets a clear error instead of a confusing run.

Route B - from Claude Code or any MCP client​

Connect once:

claude mcp add --transport http flymyai https://mcp-agents.flymy.ai/mcp

The server asks for authorization on first use, so there is no key to paste. If you would rather pin a key explicitly, pass it as a header instead - see Connect Claude & MCP Clients.

Check it landed:

whoami

Then drive the same flow in conversation. The tools map one to one onto the steps above:

StepTool
Find tools the worker needssearch_tools, add_tool
Create the agentcreate_agent
Run and iteraterun_agent, append_message, get_run
Declare inputs/outputs and freezefreeze_agent
Call the frozen agentrun_frozen
Put it on a cronschedule_agent

A worked example, in plain conversation with your coding agent:

Create an agent that takes a date and a topic, searches the news for that day, writes a short summary, and returns podcast_link and thumbnail_link. Run it once for today so I can see the output. If it looks right, freeze it with those two inputs and give me the call.

Your coding agent does the tool calls; you review the run and say when to freeze. Anything you build this way shows up in the web app, and anything you built in the web app is reachable here - it is one account, not two systems.

What you get​

  • Its own API endpoint, callable from your product
  • 1,000+ tools and integrations already wired
  • Persistent state across runs
  • Scheduled and background execution, laptop closed
  • Full execution history for every run

Scheduled runs are not chats​

Once an agent is on a schedule, each firing produces a run, not a conversation. Open one and it says so, shows the schedule as text, and links back to the agent - because that is where the schedule can be changed or stopped.

A scheduled run explains itself

Runs stay out of your chat list and live with the agent that produced them.

Where to go next​