flyto-core is a Python execution engine for AI agents, and its core proposition is "AI says it is done, Flyto2 shows the evidence." It runs browser and API work as explicit steps, records what each step did, and supports replaying from the step that failed instead of rerunning the entire task.
Purpose flyto-core is used to turn AI work into a verifiable, replayable process. It is suitable for automation scenarios that require deterministic execution, step-level tracing, and failure recovery, such as browser automation, API calls, data transformation, validation, file operations, and encryption, among other tasks.
Main capabilities
- Execution Trace: structurally records the input, output, duration, and status of each step.
- Replay: re-executes from any step with the original (or modified) context.
- Breakpoints: pauses execution at any step, inspects state, and resumes.
- Evidence Snapshots: saves the complete state before and after each step boundary.
- Data Lineage: traces data flow across steps and builds a dependency graph.
- Timeout Guard: configurable workflow-level and per-step timeout protection.
- Module library: the current public manifest contains 482 registered modules, covering 89 directory categories, including triggers, queue modules, workflow version management, metering hooks, browser automation, API calls, data transformation, validation, files, and encryption.
Usage flyto-core exposes the same deterministic runtime through multiple supported interfaces, rather than each being a separate execution engine:
- Python: directly import the module registry and workflow engine.
- YAML workflows: compose registered modules into replayable processes.
- Execution API: use authenticated /v1/* HTTP routes for local integration.
- MCP: expose the registry to AI clients via stdio or Streamable HTTP.
- Module contract: each executable action is defined by registry metadata and a bounded parameter schema; host-only primitives such as capability.invoke also require an opaque runtime authorization and cannot be activated by serialized workflow data alone.
Workflows are written as YAML files. Each run produces an execution trace and state snapshots; if step 3 fails, you can replay from step 3, there is no need to rerun the entire task. It can also be added to the MCP configuration, giving the AI access to all 482 modules as tools.
Use cases
- AI agent automation that requires step-level observability and failure recovery.
- Browser automation and API orchestration, such as screenshots, extracting performance metrics, saving JSON reports, etc.
- Production workflows that require execution evidence, data lineage, and a replayable process.
- Expose the module registry as tools to AI clients via MCP.
Limitations and security flyto-core runs with secure defaults. Optional providers, browsers, validation services, and connectors must be explicitly enabled through package extensions and documented environment variables; secrets remain in the runtime environment/credential store rather than in the workflow YAML. Host-injected runtime capabilities and configuration are intentionally distinguished: a workflow cannot enable capability.invoke by setting environment variables or serializing parameters; instead, a trusted host must inject an execution-scoped opaque authorization for that run. Security boundaries are enforced by tests across the registry: any module that accepts a caller-provided path must go through the filesystem sandbox helper, and any module that accepts a caller-provided URL or hostname must go through SSRF protection.
License and deployment The project uses the Apache License 2.0 and is free for personal and commercial use. A hosted deployment is also available.
Other information flyto-core is a standalone execution package; executing workflows or generating evidence does not depend on any other package. The canonical description is: an open-source execution engine for AI agents, 482 modules, MCP-native, triggers, queues, versioning, metering.
