Introduction

What is Appstrate?

Appstrate is an open-source platform that runs autonomous AI agents in isolated sandboxes. An agent is defined by a prompt, connects to the services your organization already uses through integrations (Gmail, Slack, GitHub, Jira, internal APIs, any MCP server), and works through its task on its own. You launch it from the dashboard or the chat, on a schedule, from the CLI, or from your own code through the REST API.

Appstrate does not execute a predefined graph of steps. The agent receives a prompt, credentials and context, and the model decides how to accomplish the task, tool call by tool call. See Design choices for what that means in practice.

How a run works

You → launch an agent (dashboard, chat, schedule, CLI, API)
            ↓
     ┌───────────────────────────┐
     │   Isolated environment    │
     │                           │
     │  ┌─────────┐ ┌─────────┐  │
     │  │ Sidecar │ │  Agent  │  │
     │  │ (proxy) │ │  (Pi)   │  │
     │  └─────────┘ └─────────┘  │
     └───────────────────────────┘
            ↓
   Result, files, state, logs, cost

Each run gets its own sidecar and agent process. The sidecar holds the credentials and the LLM access, and exposes them to the agent as MCP tools: the agent calls api_call on an integration, the sidecar injects the stored credential and checks the target URL against the integration's allowed URIs, and the agent never sees the secret. On Docker installs each run is a pair of containers on a private network. On a Tier 0 install the agent runs as a plain Bun subprocess, without container isolation. An opt-in Firecracker backend runs each agent in its own microVM. See Sandbox and Sidecar.

What you get

• Isolated runs. One sandbox per run, created and destroyed with it. Logs stream live and are kept for replay.
• Integrations. Connect external services with OAuth 2.0 (with discovery and PKCE), API key, basic auth, mTLS or custom credentials. Appstrate ships a catalog of system integrations, and you can write your own as an AFPS package, backed by an MCP server or a plain HTTP API.
• Chat. A conversational assistant in the dashboard that acts with your own permissions: it can run your agents, read your runs and files, and connect accounts. See Chat.
• Skills. Reusable SKILL.md instructions that agents (and the chat) load on demand.
• Scheduling. Cron schedules with timezones. With Redis they are distributed and fire exactly once.
• AFPS packages. Agents, skills, MCP servers and integrations are all versioned AFPS packages you can import, publish and share.
• Spaces, roles and end-users. An organization holds spaces, each with its own agents, runs, schedules and API keys, and role-based access. End-users let a product you build run agents on behalf of its own customers.
• Webhooks. Run events delivered with Standard Webhooks signatures, with up to 8 delivery attempts.
• A complete REST API. Everything the dashboard does goes through an OpenAPI 3.1 API. Each instance serves its own spec at /api/openapi.json and Swagger UI at /api/docs.
• MCP server. With the default modules, every organization exposes the API as a Model Context Protocol endpoint, so Claude Code, Cursor or any MCP client can drive the platform. See MCP clients.
• Self-hosting. Four infrastructure tiers, from a zero-install Bun process with an embedded database to a full Docker stack.

Ways to drive an instance

Who is Appstrate for?

Teams that want agents to do real work against their own systems, with the credentials, isolation and audit trail an organization needs. Platform and engineering teams build and publish agents and integrations. Other members use them from the dashboard or the chat. Products can embed agents through the API and run them for their own end-users.

Appstrate is not a workflow builder. If you are wiring two SaaS products together with fixed triggers, a workflow tool is the simpler choice. Appstrate fits work where the agent has to read, reason, branch and call tools, and where the result depends on what it finds.

Typical uses:

• Internal workflow automation. Triage support tickets against a knowledge base, classify requests, route alerts, draft replies from internal policy documents.
• Agents inside internal tools. Let non-technical staff delegate tasks (reports, reconciliation, thread summaries) from a tool they already use.
• Private data work. Run agents against internal databases and private APIs on a self-hosted instance.
• Engineering workflows. Review pull requests, enforce conventions, open issues from customer reports.