An agentic company takes the job back. Open source lets you check.

An agentic company is a company whose own work runs on agents it can hand a job to and take back. The job, the reach and the record stay its own. Most results for the term describe something else: consultancies selling agentic AI, explainers of agentic systems, lists of the top agentic AI companies. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.

What the results describe instead

Search for agentic company and the first page is mostly supply. Salesforce answers the head term with Agentforce, its platform for what it calls the agentic enterprise. A conference publishes a ranking of the top agentic AI companies. A research firm defines agentic AI as systems that plan and act with limited supervision, then stops there.

Ask an assistant which company leads in agentic AI, or for the top five AI companies, and the answer has the same shape. Vendor names, ordered by the week's news. Those questions are about the market. None of them says whether your own company is agentic, which is what the person typing the term wants to know.

A job, a grant list and a record

Three things have to exist before a company can call itself agentic. Each one is checkable by someone outside the team that built it. The job is written in a file that says what the agent is for and what finished looks like. A habit that one person remembers does not survive a vacation. The reach is written beside it. An agent that may touch the CRM, the deployment pipeline and a customer's mailbox has a list somewhere that says so, and a person decided each line. The record outlives the machine. Work arrives as a branch that can be reviewed and merged, so the session that produced it can end without taking the reasoning with it. Two of the three are files. The third is a habit the company keeps.

The manifest a new project starts with

Every new Kortix project begins with the same short kortix.yaml, and its agents: map holds one agent, worker. Here is that block as the starter ships it (raw file):

agents:
  worker:

    mode: primary
    permission: allow
    prompt_file: agents/worker.md
    tools: all
    skills: all
    connectors: all
    secrets: all
    kortix_permissions: all
    workspace: { project_repository: true }

Every key in that block belongs to the job description. prompt_file points at the markdown the agent reads. description is the line My Kortix uses to route a task here. mode: primary makes this the agent a session starts with. workspace mounts the project repository, so commits land somewhere. permission: allow is the approval mode for tool calls.

The five lines under it are the grants: tools, skills, connectors, secrets and platform permissions. Each all is the widest value its key accepts. A job that needs one connector can name one connector. The difference between the two versions is a diff with an author.

The job is a file, and the work arrives as a branch

The worker's own file opens by naming the role: "You are Worker, the general-purpose agent of {{projectName}}." Then the standard, in one sentence: "Do the task end to end and report the result." It describes the machine too. The session runs on an ephemeral branch of this repo, so the agent can install and experiment, and "Only what you commit + push survives." The sandbox is disposable. The commit is not. The agent is told to read memory/MEMORY.md before it starts. It is also told to write durable knowledge back under memory/, on the assumption that its context can reset halfway through a task. So the answer to the question of what this job knows is a path, not somebody's recollection of a conversation.

What a handover has to survive

Handing a job over tests all three parts at once, and the part that fails first is rarely the model. It is usually the paperwork around it. Three questions find that paperwork.

Who can take it back. Every job needs a named person who can narrow its grants, pause its trigger and revoke a connector. That person should be able to do it without the agent's cooperation. The case companies miss is the one where that person leaves. If the only account able to stop the agent belonged to them, the job is now unowned. An access review that looks at people instead of agents will not catch it.

What the reviewer sees. A change to the job should arrive as a diff of the file. The new connector sits on its own line, and the removed permission is marked. That is a small thing to ask for and a hard thing to fake. Session work reaches main through a change request. Merge is default-deny for agents. Approval gates you set. Off until you set them. Where those gates live in a console, the reviewer reads a summary somebody else wrote. They cannot tell which lines the agent now holds.

What the next owner inherits. A job that changes hands needs three paths on the first morning: where it is written, what the agent already knows, and where the work lands. A repository answers all three. A conversation history answers none of them, so the successor starts by interviewing whoever is still around.

The platforms keep the job in their tenant

The products that come up when you ask which platform to use are real, and each is good at something. Kortix keeps the job file, the grant list and the record in a repository the company owns. That is why the handover test can run before the invoice. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

Salesforce describes Agentforce as agents that use data, reasoning and actions to perform tasks. They are built on the Salesforce Platform and grounded in CRM data. Microsoft describes Copilot Studio as a low-code studio for building and managing agents and workflows. It adds connectors, then monitoring and governance once those run in production. The context and the controls are theirs.

Gumloop describes agents that open a real browser. They use saved logins, clear CAPTCHAs, hand the live browser to a person when a site needs one, and record every session. OutSystems describes Agent Workbench as one place to build, deploy and govern a portfolio of agents. It carries guardrails, evals and separate development and production endpoints.

LangChain describes building agents with or without code, choosing your model and owning your harness. Fleet, its team product, lets teams build agents in natural language. CrewAI describes an enterprise build and runtime for agent teams, with role-based agents and a visual editor that exports to Python. Its control plane carries access control and audit trails. Each one answers where the agents run, who builds them, or how they are governed. None of those answers says whether the job survives the contract.

Hand one job over this quarter

Take the first job you would delegate, and write it in the agent's prompt file in the words its best operator would use with a colleague. Then write the reach: the two connectors it needs, the one secret, the two permissions.

Run the handover before anyone depends on it. Name the person who can take the job back, open a change request against the grant lines, and read the diff as the reviewer will. Then imagine the job moving to a colleague next month, and check that all three paths are already there. The company that can do that with one job is agentic in the sense the term describes. The one that has to ask a vendor for the log is not. Two posts that go further: why an AI-first company keeps its operating model in a repo it owns, and why an agentic operating system is one whose permissions you can read.

Try Kortix and hand one job over.