Questions teams ask before they gate changes.

Saykai is a CI safety gate for robots and high-stakes agents that reruns real scenarios and past logs on every change and blocks the pull request (PR) if it breaks your safety rules.

If you want the longer version, see the Product page.

You need three things: a CI system, at least one way to run scenarios or log replays on demand, and a clear idea of what “safe enough” means for one system. If you can already run a test or replay job in CI, we can usually plug Saykai in without new infra.

We aim for weeks, not quarters. A typical pilot is: define the first Safety Spec in a working session, wire a single CI job with the Saykai gate, then run for a few weeks until you are seeing Safety Packs on every PR. If it is not catching useful issues in the first month, you stop.

No. Saykai runs in CI and analysis environments, not in the runtime path. It never sits between your agents or robots and the real world. If the gate passes, your deployment runs as it does today.

You should keep your tests and simulations. Saykai does two extra things: it forces you to write down what “safe enough” means in a Safety Spec, and it turns that Spec into a consistent gate that runs on every change and produces a Safety Pack. You go from “we ran some tests” to “here is the artifact that shows exactly what we tested and why this passed.”

Configs and policies are often scattered across services, docs, and people. A Safety Spec is one versioned file that defines scenarios, metrics, thresholds, and drift rules for a system. It is designed to be read by both engineers and risk owners, and it is the only thing the gate uses to decide pass or block.

You can see a full example Spec on the Safety Spec page.

A Safety Pack is a JSON artifact per CI run that records the Spec version, metrics before and after the change, the gate decision, and the scenarios that were executed. Engineers use it to debug why a change was blocked. Safety and leadership use it as evidence for why a change was allowed to ship.

The Safety Spec page has a real Safety Pack example.

Both. Saykai works anywhere behavior can be exercised in CI or in an analysis environment. Today that includes warehouse fleets, industrial autonomy, and internal agents or copilots that move money, touch configs, or trigger real work.

The Use Cases page has concrete examples.

We start with GitHub Actions and a CLI runner that can be called from any CI system. Under the hood it is just a process that reads saykai.yml, runs your commands, and returns a pass or non‑zero exit code. If your pipeline can run a script, we can usually drop the gate into it.

No. Saykai expects you to have a way to run scenarios and replays and to write metrics to a file. You keep using your existing harnesses and simulators. Saykai calls them through a standard interface and aggregates the results into a Safety Pack.

Specs live in your repo next to the code they protect. Packs are emitted by CI and can be stored in your artifact store and in the Saykai control plane. That way a reviewer can click from a run to the Pack and see exactly what was tested.

Engineers still open pull requests, push code, and watch CI. The main difference is that a Saykai check now shows up in the PR. If it passes, you get a green Safety Pack attached to the run. If it fails, the PR is blocked and you get a clear reason based on Spec rules and metrics.

Engineering usually drafts and maintains the Spec, since they know the stack and metrics. Safety, risk, and operations help define thresholds and sign‑off rules. The Spec is versioned in git so any change to the safety bar goes through the same review process as code.

Good. Saykai is not a replacement for that. It gives those teams a standard artifact for each change instead of one‑off screenshots or slide decks. Incidents become scenarios that are added to the Spec so they will be replayed on every future change.

For a pilot we usually start with your existing log and sim infrastructure and store only the metrics and Safety Packs that CI emits. If we need to ingest logs to run replays, we scope that clearly and keep them in a dedicated project. You stay in control of what leaves your environment.

Right now we are in private beta and focus on getting a small number of high quality pilots live. Pricing is simple and based on the number of systems you gate with Saykai. We talk about it openly when we scope a pilot with you.