MCPWorks Agents: LLM-Agnostic Autonomous Agents on Managed Infrastructure

Q: What happens if my LLM API key runs out of credits?

The agent continues to execute functions in direct mode (no AI required). Any trigger using reason_first or run_then_reason will fail the AI reasoning step and log the error. The function execution in run_then_reason still completes — only the reasoning step fails. Replace the key with configure_agent_ai and the agent resumes full operation.

Last week we shipped MCPWorks Functions — dynamic function creation, fully managed on our infrastructure. Your AI builds them, they run at {namespace}.run.mcpworks.io.

This week: MCPWorks Agents.

LLM-agnostic autonomous agents that run on our hosted infrastructure. Your AI builds them. They just run. Forever.

Here is what that actually means.

What are MCPWorks Agents and how do they work?

MCPWorks Agents are named, containerized autonomous entities running on MCPWorks infrastructure. Each agent gets its own subdomain, persistent encrypted state, scheduled triggers, webhook endpoints, communication channels, and an optional AI brain that reasons about function outputs and decides what to do next. Agents are MCP-native — each agent IS an MCP server with its own endpoint.

The key principle is BYOAI: Bring Your Own AI. You supply your API key from Anthropic, OpenAI, Google, or OpenRouter. No vendor lock-in. Your key, your model, your choice. Switch providers any time and the agent keeps running. MCPWorks provides the infrastructure — compute, state, scheduling, channels, external connections. You bring the reasoning engine.

This matters because your AI costs are your AI costs. We don't markup token prices. We don't force you through our inference layer. If OpenRouter gives you access to a model at a better rate than going direct, use OpenRouter. If you want Claude for nuanced analysis and Gemini Flash for high-frequency monitoring, configure different agents with different engines. The platform does not care.

Functions and Agents live on the same platform. Last week's launch feeds directly into this week's. The functions you built last week are the capabilities your agents use this week. No migration, no reimplementation, no bolted-on protocol support.

What are the three orchestration modes?

MCPWorks Agents support three orchestration modes that control the relationship between function execution and AI reasoning. Choosing the right mode is the core design decision for any agent. Each mode optimizes for a different balance of cost, latency, and autonomy — and you can set the mode per trigger, not just per agent.

Direct mode

Cron or webhook fires a function. No AI involved. The function executes, returns its result, and the cycle ends. This is the cheapest mode because zero tokens are consumed. Use it for data collection, ETL jobs, health checks, or any task where the logic is fully expressed in code.

add_schedule(
  agent_name="data-collector",
  function_name="scraping.fetch-prices",
  cron_expression="*/5 * * * *",
  orchestration_mode="direct"
)

The function runs every five minutes, writes data somewhere, and that is the end of it. No AI reasoning overhead.

Reason-first mode

The AI receives the trigger context and decides what to do. It has access to all the agent's functions and can call them in whatever order makes sense. This is the most autonomous mode — the AI is the decision-maker, not the executor.

add_webhook(
  agent_name="support-bot",
  path="ticket",
  handler_function_name="triage.classify-ticket",
  orchestration_mode="reason_first"
)

When a webhook hits, the AI sees the incoming payload and decides: should I classify this ticket, escalate it, look up the customer's history, or respond directly? The AI orchestrates the entire flow.

Reason-first is the right mode when the response depends on context the code cannot anticipate. Customer support triage, incident response, content moderation where edge cases matter. The AI has judgment; the functions have capabilities.

Run-then-reason mode

The function executes first, then passes its output to the AI for analysis. The AI decides whether the result warrants further action — sending a message, calling another function, or doing nothing.

add_schedule(
  agent_name="eth-tracker",
  function_name="monitor.fetch-price",
  cron_expression="*/5 * * * *",
  orchestration_mode="run_then_reason"
)

This is the sweet spot for monitoring and alerting. The function always runs (you always want the data), but the AI only reasons when it has something to reason about. Most five-minute price checks are boring. The AI sees the structured output, recognizes nothing unusual, and returns silently. No Discord message, minimal token usage. When the price spikes 5%, the AI writes a market alert and posts it to your channel.

Run-then-reason keeps AI costs proportional to signal, not to frequency.

What is heartbeat mode and why does it matter?

Heartbeat mode is autonomous reasoning on a loop. The agent wakes on a configurable interval, loads its persistent state — its goals, context, memory — and the AI decides whether to act. This is not cron-with-extra-steps. This is an agent with a soul that periodically checks in on its own objectives and takes action when warranted.

configure_heartbeat(
  agent_name="market-analyst",
  interval_seconds=300,
  enabled=true
)

Every five minutes, the agent wakes up. The AI receives the agent's state and system prompt. It can call any function available to the agent. It might check market conditions, review pending tasks, evaluate whether a goal has been met, or decide that nothing needs attention right now.

The difference between heartbeat and a scheduled reason_first trigger is persistence of intent. A scheduled trigger responds to an event. Heartbeat responds to the agent's own goals. The AI is not reacting to external input — it is pursuing an objective over time, maintaining context between wake cycles through persistent state.

Consider a research agent tasked with tracking regulatory changes in a specific industry. On heartbeat, it wakes every hour, checks its list of monitored sources (stored in state), fetches new content, compares it against its criteria, and posts summaries to Slack when something relevant appears. Between wake cycles, nothing runs. The agent sleeps. But it remembers what it has already seen, what it is looking for, and what it has already reported.

This is the mode that makes agents feel like agents rather than scripts.

How does multi-trigger architecture work?

MCPWorks Agents accept triggers from multiple sources simultaneously. A single agent can have cron schedules, webhooks, and channel listeners all active at once, each with its own orchestration mode. The agent is not limited to one activation pattern — it responds to whatever happens, whenever it happens.

Cron schedules are timezone-aware with configurable failure policies. Set a schedule in America/Toronto or Asia/Tokyo and it fires at the right local time. If an execution fails, the failure policy determines whether the schedule continues, retries, or pauses.

Webhooks are HMAC-verified and accessible at https://{agent}.agent.mcpworks.io/webhook/{path}. Any external system that can make an HTTP POST can trigger your agent. CI/CD pipelines, payment processors, monitoring systems, other agents.

Channels — Discord, Slack, WhatsApp, and Email — are bidirectional. Your agent posts to channels, but channels can also trigger the agent. A Slack message mentioning the agent fires the AI brain. A Discord command triggers a function. The agent lives where your team already communicates.

What can agents remember with persistent state?

Every agent has an encrypted key-value store that survives restarts, redeployments, and function updates. Any JSON-serializable value can be stored. Your agent remembers configuration, learned preferences, accumulated context, tracking data — whatever you put in state.

set_agent_state("research-agent", "monitored_topics",
  ["SEC rulemaking", "CFPB enforcement", "Basel III updates"])
set_agent_state("research-agent", "last_checked",
  {"sec.gov": "2026-03-17T08:00:00Z"})

State is readable from inside function code via context["state"] and from the AI brain during reasoning. Functions can write to state through their return values. The AI can request state updates during orchestration.

This is what gives heartbeat mode its power. The agent wakes, reads its state, understands where it left off, and continues. Without persistent state, every wake cycle would start from zero. With it, agents accumulate knowledge over time.

How do external MCP server connections work?

Agents connect to external MCP servers as clients using SSE, streamable HTTP, or stdio transports. Your agent's toolbox is every MCP server on the internet. Configure the connections once and the AI brain can call tools on any connected server during orchestration.

configure_mcp_servers(
  agent_name="research-agent",
  servers=[
    {
      "name": "news-api",
      "transport": "sse",
      "url": "https://news-mcp.example.com/sse"
    },
    {
      "name": "sentiment",
      "transport": "streamable_http",
      "url": "https://sentiment.example.com/mcp"
    }
  ]
)

During a reasoning cycle, the AI sees tools from your agent's own functions AND tools from connected external servers. It can fetch news from one server, run sentiment analysis on another, and post results to Discord — all in a single orchestration cycle.

This is MCP doing what MCP was designed to do. Open protocol, composable tooling, no walled gardens.

What are the runtime capabilities and limits?

Agents run Python and TypeScript functions in secure sandboxes with 59 allowed packages, 512MB memory, 90-second timeout, and full network access. Functions have version history with rollback — if a deploy breaks something, roll back to the last known good version in one call. Lock functions with lock_function for production safety so the AI can call them but cannot modify the code.

Clone agents with clone_agent and get a full copy: state, schedules, channels, and functions intact. Use this for staging environments, A/B testing agent configurations, or spinning up variants of a proven agent pattern.

Orchestration limits are configurable per agent to prevent runaway AI reasoning cycles:

Parameter	Range	Default
Max iterations	1–200	10
Max tokens	1K–10M	100K
Max function calls	1–500	20
Max execution time	10–3,600s	120s

These limits exist because autonomous agents need guardrails. An agent in reason_first mode with access to 30 functions could theoretically loop forever. Configurable limits let you dial in the right balance of autonomy and control for each use case.

How do MCPWorks Agents compare to other agent frameworks?

The agent framework space is crowded. Here is how MCPWorks differs from the frameworks you are probably evaluating, based on architecture and operational model rather than marketing claims.

OpenClaw is the fastest-growing open-source project on GitHub for a reason. It is a brilliant personal assistant for local use. But it is self-hosted by design. You are running the infrastructure — the servers, the uptime, the scaling. If that is what you want, OpenClaw is excellent. MCPWorks runs the infrastructure for you. Your agents get managed hosting, persistent state, scheduled triggers, and always-on endpoints without you touching a server.

LangGraph Cloud charges per node executed plus standby minutes plus a per-seat observability subscription. The metering model is complex for what should be simple: run my agent, let it reason, execute functions. You are also locked into LangGraph's orchestration abstractions — their graph model, their state management, their deployment pipeline. MCPWorks orchestration is three modes, each one sentence to explain.

CrewAI's managed platform offers limited free executions, then usage-based pricing that scales with execution volume. Their enterprise tier requires custom pricing conversations and minimum commitments. MCPWorks Developer Preview gives you full Builder tier access free for 90 days. Build something real before you pay anything.

AutoGen recently merged into the Microsoft Agent Framework. It is Azure-coupled, which is fine if you are already in Azure and intend to stay there. If you want infrastructure that is cloud-agnostic and AI-agnostic, that is a constraint you do not need.

The fundamental difference: MCPWorks Agents are MCP-native. Each agent IS an MCP server with its own endpoint. Functions and Agents are the same platform, the same protocol, the same management interface. Other frameworks bolted MCP support onto existing architectures. We built on MCP from day one.

How do I get started with MCPWorks Agents?

MCPWorks Agents are open for Developer Preview. Sign up at mcpworks.io, connect your MCP client to your namespace, and start building. The entire agent — functions, AI brain, schedules, channels, state — can be configured through conversation with your AI assistant.

No YAML. No dashboard clicks. No infrastructure to provision. Tell your AI what you want the agent to do, and it builds it.

Questions? Reach out at [email protected] or find us on Bluesky.

Frequently asked questions

What does BYOAI mean in practice? BYOAI means you supply your own LLM API key from any supported provider — Anthropic, OpenAI, Google, or OpenRouter. MCPWorks never touches your AI tokens or marks up inference costs. You configure the engine and model per agent, and you can switch providers any time without rebuilding the agent.

Can a single agent use multiple orchestration modes? Yes. Orchestration mode is set per trigger, not per agent. One agent can have a direct cron schedule for data collection, a run_then_reason schedule for monitoring with alerts, and a reason_first webhook for handling unpredictable inputs. Each trigger operates independently.

Is heartbeat mode the same as a cron schedule with AI? No. A cron schedule triggers a specific function. Heartbeat mode wakes the AI brain with no specific function context — the AI loads the agent's persistent state, evaluates its goals, and decides whether to act and which functions to call. The AI is pursuing objectives over time, not reacting to a scheduled event.

What happens if my API key runs out of credits? The agent continues to execute functions in direct mode (no AI required). Any trigger using reason_first or run_then_reason will fail the AI reasoning step and log the error. The function execution in run_then_reason still completes — only the reasoning step fails. Replace the key with configure_agent_ai and the agent resumes full operation.

Can agents talk to each other? Yes. One agent's webhook endpoint is a standard HTTPS URL. Another agent's function can call that URL, triggering the second agent. You can build multi-agent workflows where a monitoring agent triggers an analysis agent, which triggers a reporting agent. Each agent maintains its own state, its own AI brain, and its own orchestration mode.