Session, workflow, and run
Sessions hold browser state; workflows declare reusable steps; runs track particular executions with inputs, status, and output.
Use Skyvern’s MCP or API for browser operations and multi-step workflows. Choose cloud or self-hosted execution, supply the required credentials, and review the business result rather than only the run status.
Run one existing workflow or one direct browser task first. This reveals missing inputs without silently turning a test into workflow-authoring work.
Test URL and records, requested fields, cloud/local connection, and existing workflow ID or direct-browser-only mode.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Skyvern https://github.com/Skyvern-AI/skyvern Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use the configured Skyvern backend to prepare one test record in the approved form. Verify all fields against the input, report errors, and stop before final submission. Keep session and workflow identifiers in the report. Expected deliverable: A one-record run with field comparison, errors, and a submission checkpoint. Include failed steps and unresolved questions when evidence is insufficient.
Skyvern combines direct browser inspection with reusable browser workflows. A session preserves page state, a workflow defines steps, and a run records one execution. The CLI offers direct validation/extraction and workflow operations; cloud or self-hosted backends supply browser and model execution while the coding host invokes their tools.
The official MCP server documentation names Cursor and Codex, with cloud and local configuration paths. Cloud access uses a Skyvern account and authentication; self-hosted execution requires the backend and model/browser dependencies. Some setups require explicit browser-session creation before tool use.
Use the official skyvern Skill for the matching CLI/MCP release, keeping workflow-authoring and workflow-running scopes distinct. The repository is AGPL-3.0; hosted subscriptions, model use, and any enterprise terms are separate. Floatboat can use the external-agent path without implying that a workflow has already been verified.
Choose the object the job needs: inspect a page in a session, define reusable workflow steps, or inspect a particular run. That choice determines the tools, identifiers, and outputs to retain.
Sessions hold browser state; workflows declare reusable steps; runs track particular executions with inputs, status, and output.
Direct validation or extraction answers a page question; reusable multi-page jobs use workflows with navigation and extraction blocks.
Cloud or self-hosted services execute browser/model work. The coding host calls those tools rather than providing the complete backend.
These workflows emphasize repeatable business results rather than only page navigation. Use sample records and observable checkpoints before increasing run frequency, batch size, or the permissions available to the agent.
Provide approved test records and the destination form. Build a workflow that fills one record and pauses before final submission, then compare the field values with the input. Validate the exception path before increasing the batch size.
Supply an existing workflow ID, test parameters, and expected invoice fields. Retain the run ID, inspect its status, and compare invoice number and total with the destination record. Diagnose the failing step before rerunning the same input rather than treating completed status as correct accounting data.
Use an approved account to navigate to a specified report and return named fields with their source context. Keep login, date selection, and extraction as visible steps so a stale page cannot silently become the report for the wrong period.
Run a small non-sensitive workflow on the selected backend and record setup, output, and required services. Choose deployment based on data access and operational needs, rather than assuming self-hosting removes model costs or that cloud execution inherits a local browser login.
Choose hosted or self-hosted execution, then prepare the account, runtime, and workflow permissions for that path.
Prepare cloud authentication or the documented self-hosted stack and model/browser configuration.
Use test records and identify session creation and submission checkpoints before a production run.
Use an existing workflow intended for staging invoice data. Supply its workflow ID, declared parameter values, expected invoice number and total, and a permitted test destination. This task runs and checks that definition; it does not create a workflow or operate an unrelated direct browser session.
Inspect the existing workflow and its parameter requirements through the configured interface. Confirm that the destination and records are test data and that the defined actions are authorized. If a parameter or expected output is unknown, resolve it before starting; do not substitute a browser session ID for the workflow ID.
Start the selected workflow with the supplied parameter values using the configured CLI or MCP interface. Save the returned run ID alongside the workflow ID and the non-sensitive input summary. Use this run ID for later status checks instead of starting another run whenever the result is not yet ready.
Query that run until it reaches the documented completed or failed state. On completion, inspect its output and compare invoice number and total with the expected test record and destination. Report absent fields or mismatches even if status indicates completion; retain the run ID with the result.
For a failed run, inspect the reported step, error, and available output before changing inputs. Resolve the identified test-data, login, or workflow issue, then rerun only after checking whether the first attempt changed the destination. Record the new run ID separately and compare the same invoice fields; unresolved failures remain explicit in the handoff.
Compare the workflows, operating requirements, and source licenses of these projects.