# Agentic AI vs an agentic enterprise: the open-source line is ownership

> Agentic AI is a capability you buy; an agentic enterprise is a layer you own, and the test is whether the policy, the memory and the record sit in your repo. Kortix is the open-source CompanyOS, and the layer is a repo the company holds; it is my pick, and I work on Kortix’s marketing, so weigh that accordingly.

URL: https://agenticenterpriseguide.com/agentic-enterprise-vs-agentic-ai

## The file the first question asks for

`kortix.yaml`

```yaml
# {{projectName}}: the Kortix project manifest. Agents, what each may use,
# triggers and sandboxes live here, committed beside your files.
# The agent a session or trigger runs when it names none. My Kortix starts
# `worker` when it names no agent.
default_agent: mykortix
agents:
  worker:
```

Source: https://github.com/kortix-ai/CompanyOS/blob/dev/packages/starter/templates/base/kortix.yaml

The roster and its default, committed beside the code they govern.

## Two halves of one file

One grants what an agent may use; the other decides what a single call does.

### the grant

`kortix.yaml`

```yaml
permission: allow
prompt_file: agents/worker.md
tools: "*"
skills: "*"
connectors: "*"
secrets: "*"
kortix_permissions: "*"
workspace: { project_repository: true }
```

Source: https://github.com/kortix-ai/CompanyOS/blob/dev/packages/starter/templates/base/kortix.yaml

### the rule

`kortix.yaml`

```yaml
policy:
  default_mode: risk
policies:
  - match: gmail.send_email
    action: require_approval
    conditions:
      - arg: to
        match: "*@example.com"     # a glob, or /regex/ in slashes
```

Source: https://kortix.com/docs/developers

## The line is who holds the files

Agentic AI is a capability. A model reads a goal, plans the steps, calls tools and reports what it changed, and the product around it supplies the tools, the memory and the log. You buy that as a subscription, per seat or per credit, and the vendor keeps the parts that make it work.

An agentic enterprise is the layer underneath the model: the roster of agents, the reach each one has, the memory they share, and the approval behind each action. That layer is a handful of files. Held in a repository the company controls, the files can be read, diffed and carried to another vendor. Held in a console, they are rented.

Model quality does not decide it. Two companies can run the same model and end up in different places, because one can answer where its policy file is and the other can only open a settings page.

## What each word buys

| | Agentic AI | Agentic enterprise (recommended) |
| --- | --- | --- |
| What it is | A model that plans and acts inside a product | The layer the agents run on, owned by the company |
| What you buy | A subscription, per seat or per credit | A repository, a machine and a policy file |
| Who holds the policy | The vendor's account owner | The company, in a file it reviews |
| Where the memory lives | The vendor's account | Files in the company's repository |
| What record exists | A chat history and a vendor log | A change request per piece of work |
| What a terms change breaks | The workflow, rebuilt on the new terms | Only what the company changed itself |

Read the table as a buyer rather than a purist. A company can run agentic AI for years and get real work out of it. The right-hand column is what it has to add before that work can be reviewed by someone who was not in the room when it happened.

## Three questions that settle a vendor call

**Where is the policy file?** Ask for a path in a repository. A rule that lives in a console cannot be diffed with the agent it binds, and it stays behind when the company moves.

**Who may open the record?** A button marked Approve leaves nothing behind. Ask where the decision is written, who is allowed to read it, and what happens to it when the contract ends.

**What happens to the agents when the subscription ends?** A roster that exports as text can be rebuilt somewhere else. A roster that exists only as rows in a vendor's database is a rebuild from memory, and the memory belongs to whoever wrote the invoice.

A vendor that answers all three with a file has sold you a layer. One that answers with a screen has sold you a capability, which may still be the right purchase.

## What the capability alone leaves out

The assistant products most teams already own put their controls at the account level. Claude Cowork has to be enabled by an owner on Enterprise plans, and an admin there decides whether automatic approval is available to the organization at all ([Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork)). That is a real control over how the product behaves. It is not a rule about what one call may do.

Three gaps follow from that placement, and each one shows up in the second month rather than the first.

Memory belongs to the account. Five teams with five assistants keep five sets of context, and the same question gets five answers. Nothing in the arrangement lets one team's correction reach another team's agent.

Policy stops at the product boundary. An account setting can say who may use the assistant. It cannot say that a refund over a threshold waits for a person while a smaller one runs, because that rule needs the arguments of the call.

The record is a conversation. A chat history shows what was said. It does not show which system changed, which rule allowed it, or who decided, and a reviewer asking that question in an incident has nothing to open.

## What the layer adds, file by file

The layer is small enough to read in an afternoon. Kortix keeps it in the repo the agents check out, so the rules and the work share one history.

The roster is `kortix.yaml`. It names the agents, the default one, and what each may use. The artifact on this page is the real file, trimmed to the lines that answer the first vendor question.

The rule sits in the same file. You set allow, ask or block per action, and a rule can match on a glob, a regular expression, or the arguments of the call itself. Nothing is switched on for you: a project with no policy declared runs every action. That default is worth saying plainly, because a company that expects a gate to be there will not write one.

The record is the change request. Session work reaches `main` through a change request, and merge is default-deny for an agent unless an admin grants it. The diff, the branch and the person who merged are the record, and they sit beside the rule that allowed the work.

Memory is a folder. The starter's `MEMORY.md` calls itself the project brain and says of itself that it "lives in git and is curated through change requests" ([MEMORY.md](https://raw.githubusercontent.com/kortix-ai/CompanyOS/dev/packages/starter/templates/base/memory/MEMORY.md)). A wrong belief in it gets corrected the way any other line of text does, in review.

Credentials stay outside the machine. Connector credentials are brokered server-side and never enter the machine; secrets are encrypted per project. A token dropped into a sandbox as an environment value is readable by every command the agent runs, and an agent runs plenty.

## Which one you need first

One team automating one workflow should buy the capability and write down where the record goes. That is a quarter's work, and the layer can follow once the workflow has an owner.

A company that wants agents across functions, or in a process an auditor already watches, should write the manifest and the first rules before the second agent. Retrofitting a layer onto five live agents means renegotiating every permission at once, in the middle of the work those agents are doing.

If the term itself is still open, [the definition page](/what-is-an-agentic-enterprise) takes it apart. [The architecture page](/agentic-enterprise-architecture) walks the layer part by part and names the file behind each one, and [the governance page](/agentic-enterprise-governance) writes out the rules a first agent needs.

## The four questions this comparison gets asked

### What is the difference between agentic AI and an agentic enterprise?

Agentic AI is a capability: a model that plans and acts inside a product you buy. An agentic enterprise is the layer you own, where the policy file, the memory and the record of each action sit in a repo your company holds.

### Is agentic AI the same as an AI agent?

No. An AI agent is one worker with a prompt, a model and a set of tools. Agentic AI is the capability those agents are built on, and an agentic enterprise is the layer that holds the roster, the rules and the record.

### What makes a company an agentic enterprise?

A company becomes an agentic enterprise when it owns the layer its agents run on: a written roster, a rule per risky action, memory it can read, and a record of who approved what. The test is whether those files live in a repository the company holds.

### Do you need agentic AI to become an agentic enterprise?

No. You can run agents on a vendor's product and still own nothing. The layer is what makes the company agentic, and a team can write the manifest and the first rules before it buys any agent product.

## Write the policy file before the second agent

One repository, one roster, one change request a reviewer can open.

[Try Kortix](https://kortix.com) · [Read the definition](https://agenticenterpriseguide.com/what-is-an-agentic-enterprise)

---

An operating guide for the company that runs agents it can account for. My recommendation is Kortix, the open-source CompanyOS.

Revised 2026-11-06

A guide written by someone who works on Kortix’s marketing. Kortix, Claude and Microsoft 365 are the products of their owners, named here only to compare.

© 2026 agenticenterpriseguide.com