Why an agentic enterprise has to own an open-source layer

Four things the company has to own

The layer is four things: the roster, the rules, the memory and the connections into real systems. Each of the four is a file, a grant or a policy somebody can open. That is what separates the layer from the models it calls. Each one breaks in its own way once it is rented.

The agents. An agent is a defined worker: a prompt, a model, a permission level, the tools it may call. When the roster lives in a vendor console, nobody can answer which agents ran against production last Tuesday. When the roster is a file, a reviewer reads the change in a diff and a person merges it.

The skills. A skill is the written procedure for one kind of job. It is how this company closes a month, answers a tier-2 ticket, or prices a renewal. Rented skills arrive as templates, and revisions come from the vendor. Your procedure drifts toward their default, one update at a time. Owned skills are folders beside the agent, and editing one is a commit.

The memory. Memory is what agents keep between sessions: a customer's history, a decision from last quarter, a correction a person made. Held in an account you cannot export, it is rebuilt at every vendor change. The rebuild stays invisible until the answers go wrong. Held as text in the repo, it can be read, diffed and corrected.

The connectors. A connector is the path from an agent into a system with real data: a ledger, a CRM, a mailbox. Renting it usually means each person approves the app on their own account. The rule for what an agent may reach then becomes a pile of individual decisions. Microsoft documents that model for Copilot in one line: "Access scoped by user permissions" (Copilot overview). Those answers are grounded in Microsoft Graph and work data. Writing the rule down as a policy is the part you keep.

What the published definitions leave open

Salesforce defines an agentic enterprise as an organization "where humans, AI agents, and platforms work together inside governed business systems, operating with shared context, explicit accountability, and trust designed into the foundation" (Salesforce). Infor calls it "an operating model in which AI agents reason across connected systems, take governed action, and complete work end to end" (Infor).

Both put agents inside governed systems, and both stop before the question a buyer has to answer: who owns that system. A company can meet either definition through a vendor's console and still be unable to read its own roster of agents.

What carries over from the assistant world

Most teams have met the assistant version first, in Claude Cowork or Microsoft 365 Copilot. Both are real products with real work behind them. An assistant answers a question in a window. An agent takes a goal, works through it in the tools, and reports what it changed. The gap only shows in the second week, when somebody asks which of those changes a person approved. Three habits carry over from that world. Each is smaller than the problem it gets asked to solve.

A chat history keeps the conversation. Enterprise work needs a record of the action itself: which system changed, which rule allowed it, and who decided. That record has to be written beside the action, by whatever ran it.

A permissions dialog per app leaves the company with as many permission sets as accounts, and nowhere to read them together. A written policy, matched per action, gives one place to answer what an agent may reach.

Five teams with five assistants produce five sets of prompts and five answers to the same question. One roster, one memory and one record come from one layer the teams share.

The layer is a file you can read

The smallest complete example of an owned layer is 35 lines, as of November 2026. It is the starter manifest Kortix ships. The eight-line excerpt is that manifest.

The first two lines say what the file is for: agents, what each may use, triggers and sandboxes, committed beside your files. default_agent: worker names the agent a session runs when nobody names one. The default path is written where a reviewer can find it. skills: {} is a registry, empty in the starter. Project skills are folders, and each agent turns on the ones it needs with its own skills: grant.

The worker block is one roster entry, and the grants under it are the contentious part. permission: allow sits above tools: all, skills: all and connectors: all, so the starter agent may do everything. Kortix documents that plainly. It is also the honest shape of a default. The layer starts open, and narrowing it is the first change a company makes. workspace: { project_repository: true } gives each session a checkout of the repository on its own branch in /workspace (Read the docs).

The agent behind the block is a markdown file. It opens with one sentence: "You are Worker, the general-purpose agent of {{projectName}}." A person can read the whole thing in a minute. That is the difference between a roster you own and a roster you subscribe to.

Four questions worth asking a vendor

Every demo answers these in the same smooth voice. What matters is the answer you can check the following week, with nobody from the vendor in the room.

1. Where does an agent's definition live? Ask for the file. A vendor that can only show you a screen has told you where the layer is.
2. Who records the permission and the decision? An approval prompt is not a record. Ask where the approval is stored, who can read it, and whether it survives the end of the contract.
3. What does an agent remember, and can you diff it? Memory you cannot read is memory you cannot correct.
4. Can it run where your policy says, on your own model keys? A product that runs only in the vendor's cloud has answered the ownership question already.

Kortix answers the four from the same side, and each answer is a file rather than a screen. The roster, the model and the grants sit in kortix.yaml. The rules sit in the policy block beside it. Memory lives in memory/, and the record of a decision in the session's change request. 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. A reviewer can open all four before an agent runs. That is the difference between a layer the company reads and one it subscribes to.

The definition settles what follows. The architecture page maps each part of the layer to the file or system that holds it. The governance page writes out the rules that actually bind an agent.