Installation

What is open today. Step 1, the account, is open now. The Korps app for Windows and Android, where the rest happens, opens at launch; its staged builds and checksums are on Get Korps. A worker acts on a machine you pair in step 3, your own PC or a server you rent. Hosted execution by Korps is planned and not available yet.

1. Create an account. Sign up with an email address and a password at the account portal. You receive recovery codes: keep them, they are the way back in if the password is lost, and they are shown once.
2. Install Korps and sign in. Korps for Windows is the command centre; Korps for Android answers Needs You from anywhere. Sign in with the account and your organisation is created there. The Android package is an APK installed directly, not through Google Play; allow installs from this source when asked.
3. Pair a machine. Your own PC is enough to start. To keep the team working when the PC is off, pair a server you rent: ask for a pairing code on the Servers page and run the pairing command on the machine. It appears in the workspace, with its health read from its last check-in rather than a stored status.

Configuration

1. Connect an agent. Hermes is included. To run a worker on Claude Code, Cursor, OpenAI Codex, OpenClaw or OpenCode instead, install that agent’s CLI on the paired machine and sign in once; Korps drives it the same way it drives every other worker. Runtimes and models.
2. Connect a model. Point the worker at your own provider account: Anthropic, OpenAI, xAI, Google Gemini, OpenRouter or a local Ollama host, on your own key or sign-in. A connection records which provider a worker uses and where the key lives, never the key: Korps stores no model provider credential and refuses a request that carries one.
3. Hire a worker. Pick a role template or name the role yourself. Korps creates the identity, the mission, the skills for the role, a memory namespace and a direct conversation, then tells you whether the worker is ready, needs a connection, needs an approval, or failed and why.
4. Give it work. Send a message, or create a task with an objective. The machine claims the task, reports progress under the worker’s job title, and raises an approval when a grant says it must ask first.
5. Answer approvals. A pending approval is pinned in the worker’s conversation, counted on the Needs You tab, and stays pending across devices and restarts until you approve or deny it.
6. Watch Activity. Routines, delegations, tool executions and skill changes are recorded in Activity, so the conversation stays a conversation.

Teams, delegation and skills

1. A worker can belong to several teams and appears once in the roster.
2. A manager delegates through a delegation object; the receiving worker’s conversation gets a durable receipt, and completion flows back.
3. Skills have immutable versions. Installing a version over another is an upgrade or a rollback, and a rollout can move a canary first, a percentage at a time, or everyone.
4. Changing a worker’s model or runtime keeps its identity, memory, teams and history.

Integrations

A worker reaches a business system one of three ways, and the difference matters for what you sign in to and where the credential lives.

1. A Korps connection. Gmail, Google Calendar, Google Drive, Outlook, Microsoft Teams, Slack, GitHub, Notion, Linear, Jira, Asana, Salesforce, HubSpot, Stripe and Dropbox: sign in once and every worker in the workspace can use it. The token is sealed in the vault and referred to by id; a client never receives it.
2. Through the runtime. Confluence, Trello, Zendesk, Intercom, Shopify, Airtable, Figma, Zoom and hundreds more: the worker reaches them through MCP, Composio, a browser session or its agent’s own tools. The account is yours, and Activity names every system a worker touched.
3. Metered services. Browserbase, Composio, Twilio and ElevenLabs are on your own account and billed by that provider.

What Korps holds, and does not

1. Korps holds no model provider credential. A connection records which provider a worker uses and where the key lives, never the key.
2. Connector tokens and other secrets are sealed in a vault and referred to by id. A client never receives the material.
3. Every request carries a request id, which appears in error responses and in the audit log, so a problem can be traced without a transcript.
4. The Security page states the limits, the retention periods and the claims we do not make.

API reference

For building against Korps directly. Nothing above this line needs it. Every route the control plane answers, as the control plane describes it. Base URL https://api.korps.ai. Authenticate with Authorization: Bearer <access token> from sign-up or sign-in; paired machines authenticate with their own token.

• Reading the API index.

Get help

Something not doing what this page says it does, a question a buyer needs answered, or a vulnerability to report: the contact page lists the mailbox for each and who reads it. Include the request id from the error if you have one; it is in the technical details of every refusal and finds the exact event in the log.

Legal

1. Terms of Service, Privacy Policy, Cookie Policy, Data Processing Addendum, Acceptable Use, Subprocessors, Accessibility.