An open-source AI agent for business, defined by what it may write

What an AI agent for business is

An AI agent for business carries a piece of company work from a request to a finished result. It reads the material the work lives in, decides the next step, and acts through the tools it has been connected to. It leaves a record of what it changed. The deciding belongs to the model. The reach belongs to the product. The record is the part a business needs when the work goes wrong.

That much fits almost anything sold under the name, so the edges matter. A chatbot answers inside a conversation and changes nothing outside the window; ask one to close a ticket and it writes the words a person then pastes. A workflow builder runs the steps someone diagrammed, in the order they were drawn. Hand it a field that arrives empty and it stops, because the decision sits in the diagram. Autocomplete finishes a sentence already underway, one token ahead of the typist. In all three, a person still holds the moment of choice. An agent holds that moment itself, and the question a buyer has to answer becomes what the software may do with it.

Three checks to run before an agent touches production

A demonstration shows the happy path: a prompt, a plausible result, a short round of applause. Production asks harder questions of the same software, so a definition of an agent earns its keep only if it can answer three of them in writing before the first session starts.

The surface an action lands on. "It takes actions" describes every script a company already runs, so the definition has to name the surface instead: the mailboxes, ticket queues, ledgers and repositories an agent's calls can reach. Ask for that surface as a list you can read and diff before a session starts. A list kept as checkboxes in a vendor console carries no history, so nobody can tell a permission widened last month from one that was always there.

On Kortix the surface is a grant in kortix.yaml, written per agent. The starter's own agent is the broad case, and its block appears, verbatim, with the rule that reads it. A grant is all, none or a list of names, and an omitted skills, connectors, secrets or project-permissions grant resolves to none. tools and permission are open from the start. The block a new project arrives with is a starting point a team narrows on purpose.

The moment an action stops being undoable. Every agent call is reversible until the send, the payment, the delete or the merge. A definition worth buying says where that line sits and who stands on it. An instruction inside the prompt is advice, and a model can talk itself past advice. A gate on the path the work must travel holds whether the agent cooperates or not. On Kortix the gate is the merge: session work reaches main through a change request, and merge is default-deny for agents. A diff arrives, a person reads it, and the change lands after that. Approval stops being a question of what the agent was told and becomes a question of who is on the team.

The state that outlives a session. Memory belongs in the definition too, because it decides what an agent carries into its next run. Where sessions share a machine, one run's leftovers become the next run's starting state: a stray file, a half-finished migration, a delete that reaches every tenant. Ask where a session boots and what survives it. One isolated sandbox per session. Each session has its own isolated machine and branch. Only the branch crosses over, so a wrong turn costs a branch and not a quarter.

What the work is billed in

A definition that stops before the unit is only half a definition, because the same month of work reads as four different numbers depending on what a vendor meters. One vendor sells you a person, another sells metered work, a third counts each step of a job, a fourth charges only when a result arrives. A quiet month and a busy one move differently in each, and over a year that difference outgrows anything a model swap saves.

What a definition has to settle, then, is which unit its own work lands in, and how much of that unit one finished job consumes. The pricing page does the arithmetic for all four and lands each on the cost of one finished task. Read the ranked lists for what exists this month; their order tracks vendor announcements, not the strength of the offer.

The file is what separates a demo from a deployment

A demonstration can run on trust because nobody opens it after the meeting. A deployment gets read by a security reviewer, an auditor and the person who inherits it in eighteen months. What those three can open is the difference. If the list of writes and the person who approves them live only in a vendor console, the deployment has nothing to hand a reviewer. Every question then becomes a support ticket with a salesperson attached.

Kortix is built around that artifact. A project is a repository. Each agent gets one block in kortix.yaml that carries its instructions file, its mode and its grants. Widening an agent's reach is then a diff a colleague can refuse. The prompt is a markdown file next to it. The memory is a folder the agent reads before it starts and writes to when it learns something worth keeping.

That is the test to carry into any evaluation. Ask the vendor to show you the file, or the screen, that answers both halves of the definition, and watch what arrives. A confident pointer to a settings page tells you the agent's reach is real but out of your hands. A named file in a repository tells you the reach is yours to narrow, review and revert. A company that means to deploy rather than demonstrate ends up with a shortlist of one kind: products that answer the definition in a document. Kortix is built as that document, so it is where this evaluation begins.