Open-source AI agents for business: what runs on Monday

Two different products under one name

Open-source AI agents for business means two different products. The lists that rank them rarely say which one they are selling. Search the phrase and you get frameworks: CrewAI, LangGraph, AutoGen, and more lists of the same. A framework is a library. You install it, write Python, pick a model client, and become the runtime yourself.

The other product is the one a business usually wants: somewhere the agents run, a record of what they did, and a person who approves anything that writes. Call it an operating system. It has a machine and a config file, not a package you import.

The confusion costs weeks. A buyer follows a list, lands on a repo, and has a hello-world crew running by Friday. Then the work nobody listed shows up. The machine the agent runs on. The review before its output reaches a customer. The question of what it did last Tuesday.

What a business needs that a framework does not give it

A framework answers one question well: how to express an agent in code. Business work asks three more.

A place to run it. In a Kortix project every session boots on its own cloud computer. The agent file says the session is "an isolated sandbox" and "an ephemeral branch of this repo", with its own /workspace. Framework code has no opinion about that machine. You supply it, then you own the patching, the credentials on it, and the cleanup after a run that went sideways.

A record of what happened. The same file closes the thought: "Only what you commit + push survives." That line separates a demo from an audit trail. Work that never lands is gone. Work that lands sits in a diff a reviewer can open. A framework leaves logging to you, and a log file is weaker evidence than a reviewed change.

A person who approves the write. Kortix's manifest is deny-by-default. An omitted connectors, secrets, kortix_permissions or skills grant resolves to none, so an agent starts with no reach until someone writes it down. Session work then reaches main through a change request, and merge is default-deny for agents. Both halves carry weight: one limits what an agent may touch, the other decides who signs off on its work.

Where an open-source AI Operating System fits

Kortix is the second product: an AI Operating System. A project is a repo, and that repo holds the agents, the grants that bound them and the memory they keep. Open source. Read it, fork it, audit it.

The manifest is short enough to read in one sitting. Version 2 is governance only. For each agent it lists the connectors, secrets, permissions, skills and workspace that agent may use, plus the path to the .md file that holds its behaviour. The prompt does not hide in it, and the grants do not hide elsewhere. Behaviour is prose a person edits. Reach is YAML a reviewer reads.

The Kortix launch post puts the same point plainly: "A company that runs on AI shouldn't be a dashboard you rent and can't inspect. It should be a codebase you own." The model underneath is a setting rather than a vendor. Any model provider with your own keys. Or the ChatGPT plan you already pay for.

A library cannot hand that over either. The agent, the review and the record all point at one file. A new joiner reads kortix.yaml to learn what the agents in the building may do, and memory/ to learn what the company already knows. Onboarding to a framework means onboarding to someone's Python.

Choosing between them

Start with what you are building. If the agent logic is the product, a support bot you sell or a research tool clients pay for, a framework is the right raw material. The runtime underneath matters less than the code you write. If the agent does company work, drafting quotes and chasing invoices and answering the shared inbox, the code is not the product. Maintaining a runtime to get it is a cost you never budgeted for.

Then check where a run leaves a mark. Three questions, each answerable in a minute:

• Where does a session run, and who is responsible for that machine?
• Where does the record of the run live, and can a reviewer read it as a diff?
• Who approves a write, and does the agent start with refusal or with permission?

An agent that starts at none and earns its grants is easier to defend in a security review than one that starts with everything. That test holds whether the tool is a framework, an automation canvas or a suite.

For the second kind of work, Kortix is the recommendation. The agents are files, the grants are a manifest you can diff, and a change request stands between every session and main.