Tools from our team

Different jobs.
Different boundaries.

We build Emisar, Ryker and co:op. Each handles a different part of an agent's work.

Emisar: controlled access to infrastructure

An agent uses Emisar to discover and request declared actions on remote infrastructure. The action defines its arguments and limits. Policy decides whether the request can run, needs approval or is denied. A runner checks the action on the host, and the system records what happened.

Agents can use MCP or direct CLI commands. Emisar does not run the agent's reasoning loop. Its runner is not a process sandbox, and an allowed destructive action still has real effects. The host permissions and action definitions remain part of the boundary.

Explore Emisar · Read its security model

co:op: a workspace for a coding agent

co:op runs coding agents in a sandbox around a project. It controls which files, credentials and network destinations the agent can reach, according to the selected mode and configuration. It also provides task queues and isolated copies of a repository for coding work.

The project files an agent can write are still writable. Review changes and keep a recovery path. Local sandbox controls and permission to change remote infrastructure are separate concerns.

Explore co:op · Read the guide

Ryker: an AI teammate for engineering work

Ryker is a self-hosted AI teammate that works through Slack, GitHub and its web console. It can investigate an alert, answer a technical question, and work on requested code changes. Coding work uses co:op sessions. Changes to running systems use Emisar's controls.

You choose the connected repositories and tools. Draft pull request publication needs configuration. Ryker does not merge, deploy, sign commits or bypass Emisar policy.

Explore Ryker · Read the documentation

One example workflow

A teammate asks Ryker to investigate an alert. Ryker gathers evidence through its allowed tools. If a code change is needed, it can work in a co:op session and prepare the change for review. If the team requests an infrastructure action, Emisar applies the access rules and any required approval before execution.

Each part needs its own configuration and checks. A successful request to one component does not prove that the whole workflow is safe or correctly configured.