# Build an open-source agentic enterprise, one committed file at a time

> Most agentic programs start with a use case and end with five demos nobody can govern. Write the agent file and the approval rules first, then pick the work. Kortix is the open-source CompanyOS, so each step lands as a commit in a repo you own.

URL: https://agenticenterpriseguide.com/how-to-become-an-agentic-enterprise

## The policy block, as the manifest reference writes it

`kortix.yaml`

```yaml
policy:
  default_mode: risk
policies:
  - match: "helpdesk.delete_*"
    action: block
approvals:
  ttl: 4h
```

Source: https://kortix.com/docs/developers#kortixyaml-reference

A default mode, one rule per risky action, and a time limit on every approval.

## The two files step one commits

Both come from the starter, so the first change a team makes is an edit rather than a build.

### agents/worker.md

`agents/worker.md`

```
You are **Worker**, the general-purpose agent of **{{projectName}}**.
My Kortix, the built-in agent people talk to, routes each task to the
project agent that fits it. Tasks that no specialist agent covers come
to you: coding, research, writing, ops and data work. A person can also
open a session with you directly. Do the task end to end and report the
result.
```

Source: https://github.com/kortix-ai/suna/blob/dev/packages/starter/templates/base/agents/worker.md

### kortix.yaml

`kortix.yaml`

```yaml
agents:
  worker:
    permission: allow
    tools: all
    skills: all
    connectors: all
    workspace: { project_repository: true }
```

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

## Why the usual order stalls

Agentic programs start in the same place. A use case worth showing, a platform trial, a demo that lands well in a steering meeting. Salesforce's playbook follows that shape. It starts from business outcomes and picks one high-volume workflow. Governance arrives later, as a design requirement before production ([Salesforce](https://www.salesforce.com/agentforce/agentic-enterprise/)). Every step of it is sensible. What it never says is what the company owns at the end of each one.

Three failures follow. Each is cheap to avoid in week one, and expensive by agent five.

**Per-team agents.** The use case chooses its own tool. The first agent gets built where the work is, with a prompt only that team can read. Ask for the roster of agents six months later and you get five screenshots.

**Per-team grants.** Each team connects its own systems, and each connection carries a separate approval. The rule for what an agent may reach becomes a pile of decisions nobody can read together.

**No record of the boundary.** No one can say which agent touched the customer database. The approved action, and the change between demo and production, are gone.

Five teams with five demos need five security reviews and five readings of the same question. A reconciliation project then sits between them and a sixth agent. This order spends its first two moves on the parts that are expensive to redo. The use case lands third.

## The five moves, and the file each one leaves behind

1. **One agent and one skill, as files.** `agents/<name>.md`, its block in `kortix.yaml`, and a skill folder.
2. **The policy.** A `policy:` block that decides which actions run, which ask, and which are blocked.
3. **One outcome with a finish line.** A trigger, an outcome, and a definition of done a person can open.
4. **Memory and connectors in the same repo.** `memory/MEMORY.md`, connector entries, credentials outside the repo.
5. **The second agent.** Added when the first one's work has landed through a change request.

## Step 1: write one agent and one skill as files

An agent is a prompt and a grant. The prompt is a markdown file with no frontmatter, `agents/<name>.md`. The grant is an `agents.<name>` block in `kortix.yaml`. It names that file, the model and the permission mode, then the tools, skills and connectors this agent may use. The starter ships both. The worker's opening line says the idea in one sentence: "You are **Worker**, the general-purpose agent of **{{projectName}}**."

Read the starter worker before you write your own. It says what the agent is for, how it works, and how it keeps memory. It also says where to look when the platform is unfamiliar. The whole file reads as instructions rather than a personality.

The skill is the half teams skip. One folder with a `SKILL.md`. That file holds the procedure for one kind of job: which systems to check, in what order, what to do when a number disagrees with the ledger. Write what a new hire would need on day one. "Answer tier-1 tickets" is not a skill. "Read the ticket, find the order, check the delivery scan, reply with one of four outcomes" is.

Committed at the end of step one: `agents/<name>.md`, one skill folder, and the agent's block in `kortix.yaml`. All three arrive in one change request.

## Step 2: write the policy before you choose the work

The policy decides whether this holds at ten agents. It is the piece the usual order leaves until a security review forces it. Write it second, while there is one agent and the answer still fits on a page.

Kortix starts open on purpose. The manifest key is `policy:`, with `default_mode:` nested under it. The documented default is `allow_all`: the call runs. 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 ([kortix.com](https://kortix.com)). The reference lists two modes. `allow_all` runs the call. `risk` lets a read run and holds a write or a delete for approval ([manifest reference](https://kortix.com/docs/developers#kortixyaml-reference)). That is why this step comes before the use case: until the file holds a rule, the decision about what an agent may not do exists only in a meeting.

A first policy answers five questions, and each answer is one rule. Most of them fit in a glob over `<connector>.<tool>`.

- **Production writes.** Anything that changes a system of record asks a person. `require_approval`.
- **Customer data reads.** Reads of a customer record run. Writes to it ask.
- **Spend.** Anything that moves money or places an order asks, whatever the amount.
- **External messages.** Send actions ask until someone has read a week of drafts and changed the rule deliberately.
- **Credentials.** Use actions on the secret store are blocked for the first agent.

Committed at the end of step two: a `policy:` block with a default and one rule per system the first agent can reach. Whoever signs off on those systems reviews it.

## Step 3: give the first agent one outcome with a finish line

Now the use case, third. Choose work with a countable end and an artifact a person can open. A queue that reaches zero unresolved counts. So does a monthly close that explains its variances.

Write the outcome as one sentence in the prompt. Then define done as something that exists outside the agent's own account. "The queue is empty" is not a finish line if nobody can check it. "A change request with the reconciliation attached and every variance over tolerance explained" is.

Triggers start the work without a person in the loop each time. The manifest lists them with one line: `#   triggers            run an agent on a schedule or an event`. Set one. One agent on one schedule produces a record you can compare week to week. Four agents on four schedules produce four stories.

Committed at the end of step three: one trigger and one written definition of done. Both sit in the repo beside the agent they belong to.

## Step 4: keep memory and connectors in the same repo

Two things usually live in a console and belong in the repo instead. Memory first: the starter keeps a project brain at `memory/`, read and written with the file tools. `memory/MEMORY.md` is the entry point, and the worker is told to read it before starting a task. Because it is markdown in the repo, a correction is a diff. A wrong belief is reviewable, and memory survives the next vendor change.

Then the connections. `kortix.yaml` names the connector each agent may use, and the credential stays out of the file. Connector credentials are brokered server-side and never enter the machine. An approval someone clicked in a console last spring leaves no trace. A grant in the repo sits next to the agent that holds it.

Committed at the end of step four: `memory/MEMORY.md` with the first week of decisions in it. Connector entries are scoped per agent, not per team.

## Step 5: add the second agent when the first lands work you can read

The gate for agent two is three checkable things:

- the first agent's work has landed through a change request;
- every system it touched has a rule in the policy file;
- the skill it leaned on is written down, not in someone's head.

When those hold, the second agent costs a prompt and a block. It inherits the policy and the memory already written. The review is the same shape as the last one. Agent two works on its own branch and leaves a diff of its own, so the reviewer reading agent nine's diff does the job the reviewer did on agent one.

That is the whole difference from the usual order. The tenth agent reuses a decision made at agent one. The company never runs the reconciliation project.

Committed at the end of step five: the second agent's block, and a policy file the new agent inherits rather than duplicates.

## What it costs

Someone owns the policy file, and that person needs the standing to say no to a team. The repo becomes a production system. It needs branch protection, a named set of people who may merge, and a backup somebody has restored once. The first agent will show less in its first two weeks than a demo would. The two weeks go into files and rules.

Two habits keep the cost from compounding. Review the policy on a schedule, the way you review access. When an agent needs something new, change the file and not the console. The decision then sits where the agent is.

None of the five steps waits on a vendor release: each one is a commit in a repository the team holds. [The architecture page](/agentic-enterprise-architecture) maps each of these files to the layer it holds. [The governance page](/agentic-enterprise-governance) writes out the rules that bind an agent once it runs, and [the definition page](/what-is-an-agentic-enterprise) covers what the term promises before any of this.

## The questions people ask before step one

### How do I build an agentic agent?

Write two files: a prompt at `agents/<name>.md`, and a block in `kortix.yaml` that sets its model, permission and the tools, skills and connectors it may use. The starter ships one, called worker, that a team can edit in an afternoon.

### What is an agentic enterprise?

A company where agents take on work across functions and people set the boundaries. What decides whether it holds is the layer underneath: which agents exist, what each may touch, what they remember, and who approves their work.

### How do I start my own AI company?

Start with one agent, one written procedure and one job with a finish line, all in a single repo. A company of one can run that on a laptop or a cloud account. The decision worth getting right early is who owns the configuration.

### How to earn from agentic AI?

From work you already sell, delivered with agents: tickets closed, reports produced, code shipped, billed the way you bill it today. The agents change cost and speed; the customer still pays for the work.

## Start with the file, then the work

One repo, one agent, one policy a person can read.

[Try Kortix](https://kortix.com) · [Read the governance page](https://agenticenterpriseguide.com/agentic-enterprise-governance)