One kortix.toml. One Git repo.
Your entire AI workforce, as code.
Agents, skills, tools, connectors, schedules — all just files in a repo. Edit them in your IDE, run them locally, ship to the cloud with one command. Open source, self-hostable, yours.
name = "acme-ops"
[sandbox]
image = ".kortix/Dockerfile"
[[agents]]
name = "support-triage"
model = "anthropic/claude-opus-4-8"
skills = ["ticket-triage", "kortix-memory"]
[[triggers]]
type = "cron"
schedule = "0 8 * * *"
agent = "support-triage"
[connectors]
slack = true
linear = trueThe coding-agent loop, for real work
Describe intent, an agent edits files, you review the diff. Kortix runs that same loop for support, ops, and research.
Agents are sandboxes
Every agent runs in its own disposable cloud VM, on its own git branch. Spin up thousands in parallel — nothing is shared between runs.
Work is code
Agents, skills, triggers, connectors and policies are plain files in one repo. Diff them, review them in a change request, roll them back.
You own the stack
Open and source-available. Self-host the exact same stack, bring your own runtime and model keys. No black box, no lock-in.
From curl to production
One repo, one config, one command. The whole path, top to bottom.
Install & scaffold
One line installs the CLI. kortix init scaffolds kortix.toml and .kortix/, wired to your coding agent.
Build it locally, like code
An agent is markdown — a persona, its model, and its tools. Skills are folders it loads on demand. Edit them by hand, or describe what you want and let your coding agent write them.
---
description: Acme's support agent. Resolves tickets end to end.
mode: primary
model: anthropic/claude-opus-4-8
tools:
lookup_order: true
---
You are Acme's support agent. Resolve customer tickets
end to end, with full product and order context.
Issue refunds under $500 on your own. Anything higher
goes to a human for approval.Declare the project in one manifest
kortix.toml holds secrets, sandbox images, triggers, connectors, and channels. Versioned from the first commit.
kortix_version = 1
[project]
name = "acme"
# the OpenCode runtime config dir
[opencode]
config_dir = ".kortix/opencode"
# a trigger runs itself, on a schedule
[[triggers]]
slug = "daily-digest"
type = "cron"
agent = "research"
cron = "0 0 9 * * 1-5"
prompt = "Summarize yesterday across Slack & Linear"
# connect a tool's API as agent tools
[[connectors]]
slug = "stripe"
provider = "http"
base_url = "https://api.stripe.com"
# answer where your team works
[[channels]]
platform = "slack"
agent = "support"Ship it
kortix ship commits, pushes, builds the sandbox, and prompts for missing secrets. Triggers and channels go live immediately — no separate infra to stand up.
It runs as a fleet of sandboxes
Every session is its own VM on its own branch, booting the runtime and your repo. Spawn thousands in parallel — zero interference. A change request is the only way work reaches main, so everything is reviewable and reversible.
Bring your own runtime & model
Sessions run on an open runtime. Bring your own keys — Anthropic, OpenAI, local — or use Kortix compute. Nothing about the runtime is hidden.
The whole lifecycle, one CLI
Scaffold, ship, run, automate, connect and review — one CLI does it all. The same binary is pre-authenticated inside every sandbox, so agents drive Kortix with the exact commands you do.
Scaffold & ship
$ kortix initScaffold kortix.toml + .kortix/
$ kortix shipCommit, push, link & go live
$ kortix validateType-check your manifest
Run & talk
$ kortix sessionsSpawn & manage sandbox sessions
$ kortix chatTalk to a session's agent
$ kortix filesBrowse the repo, diffs & branches
Automate
$ kortix triggersCron & webhook automations
$ kortix channelsConnect Slack & chat surfaces
Connect
$ kortix connectorsWire up 3,000+ tools
$ kortix secretsManage encrypted secrets
$ kortix envPull / push as dotenv
Review
$ kortix crOpen, review & merge change requests
$ kortix accessInvite, grant & revoke access
Operate
$ kortix self-hostRun your own Kortix cloud
$ kortix hosts useSwitch cloud ↔ local
$ kortix providersBring your own model keys
1 session = 1 sandbox = 1 branch
Every session runs in its own isolated sandbox — real, isolated compute — on its own Git branch off main. Spin up millions in parallel; nothing collides.
- Anything worth keeping comes back as a change request — and merges into main
- Main is always the source of truth: every agent action is auditable Git history
- It’s all Git under the hood — branch, diff, review, merge
- The same Kortix CLI runs inside every sandbox — so running locally and in the cloud is identical
- Isolated compute per session; one runaway agent can’t touch another
Every tool, behind one interface
Kortix connectors put 3,000+ apps — plus any MCP, OpenAPI, GraphQL or raw HTTP endpoint — behind a single Executor interface your agents call like any other tool.
- 3,000+ one-click apps via Pipedream — OAuth handled for you
- Or bring any MCP, OpenAPI, GraphQL or HTTP endpoint — same interface
- Credentials live server-side and never reach the sandbox
- Agents hold one scoped Kortix token; connect once, shared org-wide, self-healing
+ 3,000 more via Pipedream
A platform that improves itself
Because everything is code in a repo, the system can read its own blueprint, extend itself, and stay healthy as it grows. 100% extensible, controllable, self-hostable — nothing is a black box.
Everything is files
Agents, skills, tools, connectors and schedules live in the repo. Edit in your IDE, in the web UI, or let an agent edit them.
Agents edit themselves
Describe a change and an agent ships it — referencing what already exists, reusing patterns, opening a PR you review.
Skills, git-backed and invisible
Non-devs publish skills as markdown; Kortix handles the branch, PR and merge behind the scenes. Versioned, reviewable, auditable.
Self-healing integrations
When a token expires or a service blips, Kortix refreshes it or asks you to reconnect in plain language — never a cryptic error.
Quality gates built in
Type checks, lint, docs validation and dedup run before anything merges, so a fast-moving, agent-written codebase stays coherent.
Every feature is a conversation
The UI is a reference, not a requirement. Anything you can do in a menu, you can do with a message.