AI agent management platform: governing a fleet with open-source Kortix

Kortix answers the four questions from one place. The agents, their skills, the company memory, the connectors and the triggers live in a git repository the company owns, each session runs its agent on an isolated machine, and work reaches the main branch only through a change request a person approves.

The five decisions a management layer makes

Managing AI agents at scale comes down to five decisions: who owns the configuration, what each agent may touch, how credentials reach a tool, what a running agent is doing, and which work is allowed to land. That set is AI agent governance in practice: the policy, access and change control a company applies to a workforce that runs on its own. Kortix implements each decision as a mechanism a security review can read.

One git repo is the source of truth for the fleet

In Kortix the company itself is a git repository. Agents and skills are markdown files, memory is a set of files that accumulates as the company learns, and kortix.yaml declares the machine image every session boots, the connectors the company is wired to, the triggers that start work on their own, and the rules each agent may touch. A skill written once is shared into every session, and an agent can be installed in a click. Because the whole configuration is text, a team can grep the entire company, diff any change to an agent or a skill, and roll any part of it back. Open-source agent management means the state of the platform is readable and ownable, so a company can audit it, move it or leave with it. The code is public at Kortix on GitHub, and the harness that runs the agents can be read and audited.

Permissions for people and agents, set per tool call

Per-resource permissions in Kortix apply to people and to agents, using members, groups and roles that match the organization's structure. A person and an agent can hold different rights over the same resource. Tool access is governed by an allow, ask or block rule applied to each tool call, down to a single shell command or the arguments a model was handed. Merge is deny-by-default for an agent, so no agent approves its own work, and approval gates can be switched on for the actions that matter, such as sending an outbound email or moving money. The permission rules sit in the repository beside the agents they constrain, so a reviewer reads them as code.

Secrets and connectors: the raw key never enters the machine

Connectors are the systems an agent acts on. Kortix connects more than 3,000 apps in a click and also speaks MCP, OpenAPI, Postman, GraphQL and raw HTTP, so a company rarely has to build an integration before an agent can use it. Connector credentials are brokered server-side through one scoped token and never enter the session's sandbox, and secrets are encrypted at rest, granted per agent, and injected into the sandbox at runtime. An agent therefore holds exactly the access it was granted, with no path to the underlying key. A confused or compromised agent cannot leak a credential it never saw.

Monitoring and control: watch the session, then merge the diff

Every Kortix session runs an agent on its own isolated Linux machine, on a branch named after the session, and a person can watch that session live while it works. The agent may install, run and break anything inside its machine, but only what it commits survives. The work lands as a change request against the default branch, and a human reads the diff and merges or closes it. Every action is recorded in an audit trail, and sessions can be started from the web app, Slack, Teams, email, mobile, the CLI or the API. Thousands of sessions run in parallel on one configuration with no crossover between them. The merge gate is the same control point that AI agent orchestration uses when sessions start from cron or a signed webhook.

What managing agents at scale changes

Scale in Kortix is a property of the configuration, and the operations team does not grow with the agent count. One repository declares how every session boots and what every agent may do, so adding the hundredth agent means a new file and a review; no new server or dashboard is needed. Work still reaches main only through change requests, so the company improves one reviewed change at a time. The same configuration runs in the managed cloud, in a VPC, or on-prem, and the self-hosting guide covers running it on your own infrastructure.

The layer Kortix is building: train and eval on your own work

Kortix describes the layer it is building next as train and eval inside the same platform: your own models, trained on the work your agents already did, then evals and reinforcement learning scored on the company's own sessions. Public benchmarks measure models on data the company does not own. The train and eval layer can exist here because the work, the skills, the memory and the configuration already live in a repository the company controls. A hosted dashboard cannot offer it, because the sessions behind that dashboard were never the customer's to train on.

Own the layer that manages the fleet

Kortix is the open-source AI Management System, with any model and your own keys, self-hosted on a laptop, a VPS, your VPC or on-prem, or run as managed cloud. A team still mapping the category can start with the open-source AI agent platform overview, which places the management layer among the others a platform provides. To run it, Get started with open-source Kortix.