// the find
kortix-ai/suna
The Company AI Command Center
Kortix is a platform for running AI agents inside isolated, disposable Linux sandboxes where each session works on its own git branch and submits change requests back to a main company repository for human review. The premise is that a company's agents, skills, memory, and automations all live in a single versioned git repo you own outright. At 20k stars and active daily commits it has real traction, but 'source-available' is doing quiet work in the README.
The session isolation model is genuinely well-designed: each agent runs in its own sandbox on a named branch, and the only path to main is through an approved change request. That's a real safety mechanism, not theater. The IAM layer is unusually mature for this kind of project — resource-scoped tokens, service accounts, SSO sync, token revocation with expiry, all with dedicated integration tests. Most AI platforms treat authz as an afterthought. The dotenvx approach to secrets is clever: encrypted .env files committed to git, single private key stays off the repo, rotate secrets with a normal commit and CI needs only one secret instead of fifty. The skill system stores reusable agent capabilities as markdown files inside the repo itself, which means an agent can literally rewrite its own skills and that change goes through the same change-request review as any other commit.
The word 'source-available' appears twice in the contributing section and zero times anywhere prominent — this is not MIT or Apache, and before self-hosting in production you need to read the LICENSE carefully. The 3,000+ connectors claim is brokered through Pipedream server-side, so if Pipedream is down or rate-limits you, agents lose most of their integrations; that dependency is not prominently disclosed. The self-host path is technically 'three commands' but behind kortix self-host start is a non-trivial Docker Compose stack spanning API, web, sandbox, and tunnel services — the quickstart experience only works cleanly on Kortix Cloud. The 'company as git repo' workflow assumes everyone reviewing change requests is comfortable with branch-per-session and PR review, which describes developers, not most of the non-technical people at a company.