flytohub/flyto-core

**AI said it finished. Flyto2 shows the proof.**
A Python execution engine for AI agents. It runs browser and API work as
explicit steps, records what every step did, and replays from the step that
failed — instead of re-running the whole job.
The current public inventory is **482 registry-backed modules** across **89
catalog categories**, including triggers, queue modules, workflow versioning,
metering hooks, browser automation, API calls, data transforms, verification,
files, and crypto.
flyto2.com · Cloud Automation · Documentation · MCP Docs · YouTube
---
Try it in 30 seconds
Screenshots captured. Performance metrics extracted. JSON report saved. **Every step traced.**
---
What happens when step 8 fails?
With a shell script you re-run the whole thing. With flyto-core:
Steps 1–7 are instant. Only step 8 re-executes. Full context preserved.
---
How is this different?
| | Playwright / Selenium | Shell scripts | flyto-core |
|-|----------------------|---------------|------------|
| Step 8 fails | Re-run everything | Re-run everything | flyto replay --from-step 8 |
| What happened at step 3? | Add print(), re-run | Add echo, re-run | Full trace: input, output, timing |
| Browser + API + file I/O | Write glue code | 3 languages | All built-in |
| Share with team | "Clone my repo" | "Clone my repo" | pip install flyto-core |
| Run in CI | Wrap in pytest/bash | Fragile | flyto run workflow.yaml |
---
3 recipes to try now
Every recipe is traced. Every run is replayable. See all 41 recipes ->
---
Install
---
Write Your Own Workflows
Recipes are just YAML files. Write your own:
Every run produces an execution trace and state snapshots. If step 3 fails, replay from step 3 — no re-running the whole thing.
---
Usage
CLI — run workflows from the terminal
MCP Server — for Claude Code, Cursor, Windsurf
Or add to your MCP config:
Your AI gets all 482 modules as tools.
HTTP API — for integrations and remote execution
| Endpoint | Purpose |
|----------|---------|
| POST /v1/workflow/run | Execute workflow with evidence + trace |
| POST /v1/workflow/{id}/replay/{step} | Replay from any step |
| POST /v1/execute | Execute a single module |
| GET /v1/modules | Discover all modules |
| POST /mcp | MCP Streamable HTTP transport |
Python API — for programmatic use
---
API
Flyto2 Core exposes the same deterministic runtime through several supported interfaces rather than separate execution engines:
- **Python** — import the module registry and workflow engine directly.
- **YAML workflows** — compose registered modules into replayable procedures.
- **Execution API** — use the authenticated /v1/* HTTP routes for local integrations.
- **MCP** — expose the registry through stdio or Streamable HTTP to AI clients.
- **Module contract** — every executable action is defined by registry metadata and a bounded parameter schema; host-only primitives such as capability.invoke additionally require opaque runtime authority and cannot be activated by serialized workflow data alone.
Generated source-linked references are available in Python API Reference, Registered Modules, and the Full Module Catalog.
---
Configuration
Flyto2 Core runs with safe defaults. Optional providers, browsers, verification services, and connectors are enabled explicitly through package extras and documented environment variables; secrets stay in runtime environment/credential stores rather than workflow YAML. Start from .env.example for supported settings and see Operations for runtime/deployment guidance.
Host-injected runtime capabilities are deliberately different from configuration: a workflow cannot enable capability.invoke by setting an environment variable or serialized parameter. The trusted host must inject the execution-scoped opaque authority for that run.