Start an AI-Native Company

TL;DR: Whether you are opening a medical practice, a clothing shop, or the next unicorn startup, start with one master Git repository for shared company knowledge, then nest restricted repositories inside it for legal, finance, HR, investors, and client-specific work.

The clean-start advantage

Existing companies need a migration. New companies need a scaffold.

No legacy SharePoint jungle. No final_v7_REAL.docx. No folder named after an employee who left three years ago. You start with a structure humans understand and AI agents can search from day one.

The goal is not a perfect filing cabinet. It is a company that is readable:

• by you
• by future hires
• by AI agents
• without asking a SaaS vendor for permission

It needs to become a set of folders with discipline, not a database with drawers inside drawers.

Security lives in the folder, not the file

A file that says “For C-suite eyes only” is not security. Real security comes from where the files live and who can reach that location.

For a new company, that location is a Git repository. A Git repo is a folder that remembers every change ever made to it, syncs through a host like GitHub, GitLab, or Forgejo, and decides who is allowed to copy it.

If Git is new to you, start with Git Essentials for Company Files.

You could use a cloud-sync folder like Nextcloud, Dropbox, or Google Drive. But for a new company going AI-native, do not make that the default. Cloud sync is convenient, but Git gives you history, review, and cleaner access boundaries.

Git is not just for programmers. It is a versioning system: it keeps full history of your text files, lets people work offline, and syncs changes through a server. More importantly, Git repos have access control: you decide who can reach which repo. See [Configuring Forgejo access for your team -> upcoming article].

The model: one master repo + nested repos

There is one master repo.

The master repo holds the common company knowledge every trusted team member should have: strategy, product/service notes, CRM, marketing, operations, and onboarding context.

When something needs a different access level, it becomes a nested repo: a normal Git repo placed inside the master repo at a numbered path. Not a Git submodule. Not a special Git trick. Just another repo living inside the folder tree.

Nested repos are also practical for customer work. A client can get one project repo with read-only or edit access without seeing the rest of the company.

Why not Git submodules? Because submodules point to a specific commit and updating them requires extra commits in the parent repo. Too much ceremony. This article is for lean teams, not Git archaeology.

Use this mental model:

Everything carries an xx- prefix for readability:

my-company/                          # master repo: common company brain
├── AGENTS.md
├── Company_Plan.md
├── .gitignore
├── 01-Strategy/
├── 02-Product-or-Service/
├── 03-CRM/
├── 04-Customer-Discovery/
├── 05-Marketing/
├── 06-Operations/
├── 07-Presentations/
├── 50-Legal/                        # nested repo: founders + counsel
├── 51-Finance/                      # nested repo: founders + finance
├── 52-HR-GDPR/                      # nested repo: founders + HR
├── 53-Investors/                    # nested repo: founders only
└── 99-Archive/                      # nested repo: restricted, read-only

That is the model. One visible tree. Common knowledge at the root. Restricted knowledge nested as normal repos. Everyone can see that 51-Finance/ exists; only finance-approved people can clone its contents.

Media is fine at first. Do not over-engineer day one. Just watch the bloat. If images, video, CAD, or design files start making the repo heavy, move them to Git LFS. Git LFS lets large files download only when needed, which protects both local storage and repo performance. See Git Essentials for Company Files.

The rule: access before taxonomy

Play safe:

Split by access level, not by department.

The master repo is shared. Each restricted area is a nested repo with its own access rule.

Do this: one master repo + restricted nested repos.

my-company/
├── 01-Strategy/ ... 07-Presentations/ # common
├── 50-Legal/                          # nested repo: founders + counsel
├── 51-Finance/                        # nested repo: founders + finance
└── 52-HR-GDPR/                        # nested repo: founders + HR

Do not do this: one shared root per department.

Company/
├── Marketing/
├── Sales/
├── Product/
├── Legal/
├── Finance/
└── HR/

Looks clean. It is a trap. The shared root means everyone with access can walk into every department. The master + nested repo model gives you one tree and separate doors.

Folder architecture is security architecture. Design it that way from day one.

Examples: same model, different companies

The nested repos below are examples, not a second rulebook. Keep only what your access model needs.

Canonical startup tree for llama-launch-labs/:

llama-launch-labs/
├── AGENTS.md
├── Company_Plan.md
├── .gitignore
├── 01-Strategy/
├── 02-Customer-Discovery/
├── 03-CRM/
├── 04-Marketing/
│   └── Website/                      # normal folder, symlink, or nested repo
├── 05-Sales/
├── 06-Operations/
├── 07-Presentations/
├── 08-Product/
│   ├── Product_Requirements/
│   ├── Technical_Decisions/
│   ├── Release_Notes/
│   └── App/                          # normal folder, symlink, or nested repo
├── 50-Legal/                         # nested repo: founders + counsel
├── 51-Finance/                       # nested repo: founders + finance
├── 52-HR-GDPR/                       # nested repo: founders + HR
├── 53-Investors/                     # nested repo: founders only
└── 99-Archive/                       # nested repo: restricted, read-only

Website content usually belongs with marketing. App code belongs with product. Each can be a real folder, a symlink, or a nested repo. The folder name stays simple: Website/ or App/.

Architecture client example for 3-piglets-architects/:

3-piglets-architects/
├── 01-Clients/
├── 02-Proposals/
├── 03-Suppliers/
├── 04-Standards/
├── 05-Marketing/
├── 06-Operations/
├── 50-Client-2026-001-Office-Renovation/
│   ├── AGENTS.md
│   ├── Project_Brief.md
│   ├── Meeting_Minutes/
│   ├── Site_Reports/
│   ├── Change_Requests/
│   └── Drawing_Register.md
└── 51-Client-2026-002-Warehouse/

That is the point of nested repos: one client can get one project without seeing the rest of the firm.

The minimum the master repo needs

The master repo starts with three files and the common numbered folders:

my-company/
├── AGENTS.md
├── Company_Plan.md
├── .gitignore
├── 01-Strategy/
├── 02-Product-or-Service/
├── 03-CRM/
├── 04-Customer-Discovery/
├── 05-Marketing/
├── 06-Operations/
└── 07-Presentations/

Always run broad AI work from the master repo. The agent reads AGENTS.md to understand the map and Company_Plan.md to understand what matters now.

Security controls before setup

This comes before the practical setup because it protects the whole model.

Some folders do not belong in the master repo. If a folder contains confidential documents stored elsewhere, mark it as exclude or reference in AGENTS.md. If you are unsure, mark it manual review and decide later.

The master repo .gitignore must ignore nested repo folders. That prevents the master repo from accidentally tracking restricted contents.

Starter .gitignore:

# Nested restricted repos
50-*/
51-*/
52-*/
53-*/
99-Archive/

# Secrets
.env
.env.*
*.key
*.pem
secrets/
credentials/

# App and tool noise
node_modules/
.venv/
.ruff_cache/
.obsidian/workspace*
.trash/
.DS_Store

Without this, every search scans noise. An AI searching active notes plus archived dumps returns confusion. A good ignore pattern returns signal.

Practical setup: ask an AI agent to build it

The theory ends here. The setup starts here.

Do not ask a non-technical founder to run Git commands. Ask an AI agent to create the scaffold. If you do not know which tool to use, read Run your AI Agents.

Customize this prompt with your company name and access rules:

Create an AI-native company folder scaffold for a new company.

Use one master Git repository named: my-company

Create these common folders in the master repo:
- 01-Strategy
- 02-Product-or-Service
- 03-CRM
- 04-Customer-Discovery
- 05-Marketing
- 06-Operations
- 07-Presentations

Create these files in the master repo:
- AGENTS.md
- Company_Plan.md
- .gitignore

Create these nested restricted repositories (with git init) inside the master folder:
- 50-Legal: founders + counsel
- 51-Finance: founders + finance
- 52-HR-GDPR: founders + HR
- 53-Investors: founders only
- 99-Archive: restricted, read-only by default

Do not use Git submodules.
Nested repositories are normal Git repositories placed inside the master folder.
The master .gitignore must ignore the nested repo folders using this pattern:
50-*/
51-*/
52-*/
53-*/
99-Archive/

Generate Company_Plan.md with sections:
- long-term direction
- next 90 days
- current OKRs or objectives
- active products or services
- onboarding summary for a new hire

Generate AGENTS.md using this outline:
- What is [Company]?
- Products
- Repository structure
- Source code locations
- How this repo works
- Tooling
- How progress is tracked
- Key context for AI agents
- Non-negotiable rules

In AGENTS.md, include the nested repo list in Repository structure.
Keep everything readable for non-technical operators.

At this point, the structure works locally. It is not backed up yet. It lives only on your computer.

To back it up and share it, create remote repositories on GitHub, GitLab, Forgejo, or another Git host:

The principle is simple: one local repo gets one remote repo. The master repo has broad access. Each nested repo has its own narrower access list. Use HTTPS remote URLs by default.

Onboarding with Git: download, adapt, run

Once the remote repos exist, onboarding another machine has two processes.

1. Create the script for your company based on the template

Download the onboarding script:

templates/onboarding/onboarding_git.py

Ask your AI agent to customize it for your company:

I have this onboarding script: onboarding_git.py.

Customize it for my company Git setup.

Edit only these variables:
- MASTER_REPO_PATH
- MASTER_REPO_URL
- NESTED_REPOS

Do not change the rest of the script.

Master repo:
- local folder name: my-company
- HTTPS remote URL: https://forgejo.mycompany.com/mycompany/my-company.git

Nested repos:
- 50-Legal: https://forgejo.mycompany.com/legal-team/my-company-legal.git
- 51-Finance: https://forgejo.mycompany.com/finance-team/my-company-finance.git
- 52-HR-GDPR: https://forgejo.mycompany.com/hr-team/my-company-hr-gdpr.git

Use HTTPS remote URLs only.
Do not use Git submodules.
Return the final edited onboarding_git.py file.

The only editable block should look like this:

MASTER_REPO_PATH = "my-company"
MASTER_REPO_URL = "https://forgejo.mycompany.com/mycompany/my-company.git"

NESTED_REPOS = [
    ("50-Legal", "https://forgejo.mycompany.com/legal-team/my-company-legal.git"),
    ("51-Finance", "https://forgejo.mycompany.com/finance-team/my-company-finance.git"),
    ("52-HR-GDPR", "https://forgejo.mycompany.com/hr-team/my-company-hr-gdpr.git"),
]

Send it over to your next hire.

2. Run it on the machine you are onboarding

On the new machine, put onboarding_git.py where the company folder should appear:

Work/
└── onboarding_git.py

When the script runs, it creates this:

Work/
├── onboarding_git.py
└── my-company/
    ├── AGENTS.md
    ├── Company_Plan.md
    ├── 01-Strategy/
    ├── 50-Legal/
    └── ...

Then ask an AI agent to guide the run:

I have an onboarding script named onboarding_git.py.
It is in this folder: [paste folder path]

Help me run it safely.

Before running it:
- check whether uv is installed; if not, give me the right install command for my operating system
- check whether Git is installed; if not, help me install it
- check whether my Git credentials work for the HTTPS master repo URL in the script
- if credentials are missing, guide me through the right login or credential setup for this host
- use HTTPS remote URLs only

Then run:
uv run onboarding_git.py

If the script skips a repo, explain whether it is a missing permission which may be normal except for the main repo, wrong URL, or missing remote repository.

The script downloads each repo into the right folder. If the person does not have access to a repo, it skips that repo. That is expected. Access decides what appears on their machine.

AGENTS.md guidelines

AGENTS.md tells AI agents how to behave inside the repo. Keep it short. See AGENTS.md Template for AI Agents.

Use this outline:

# [Company] — Knowledge Base Guide

## What is [Company]?
## Products
## Repository structure
## Source code locations
## How this repo works
## Tooling
## How progress is tracked
## Key context for AI agents
## Non-negotiable rules

Wide rules:

• Point agents to Company_Plan.md before strategic work.
• Point agents to Repository structure before looking for restricted material.
• Tell agents which folders are active, archived, excluded, or manual review.
• Tell agents never to write secrets, passwords, API keys, bank data, raw patient records, or private employee records to Markdown.

Do not start by designing a 14-agent corporate pantheon. Start with rules the AI will actually need.

Add the living product carefully

Website/ and App/ can be normal folders, symlinks, or nested repos. Use the simplest option that matches access.

Safety rule: never put secrets, .env files, private customer databases, raw exports, or a whole personal folder there. Convenience is how leaks start.

How the pieces work together

This is the glue, not another folder model.

Having access to everything does not mean every AI task should see everything.

What’s next

The folder is ready. Now add the tools that make it produce work.

Start with General Setup:

• Git vs Google Drive — choose how to store your files.
• Run your AI Agents — pick your AI tool.
• AGENTS.md Template — tell your AI how the company works.

Then build your content tools: CRM for relationships, PDFs for documents, Decks for presentations, Social for content.

Do not connect everything on day one. Start with the master repo. Then add the tools that make it produce work.

The folder is the company. The tools are just handles.

The takeaway

Starting AI-native is not about installing more software. It is about making the company readable from the beginning without making it reckless.

• Use one master Git repo: my-company/.
• Nest restricted areas as normal repos (50-+), one per access level.
• Number everything (xx-) so the company is scannable from one tree.
• Use Git LFS when media starts bloating the repo.
• Keep regulated records in regulated systems.
• Put AGENTS.md, Company_Plan.md, and .gitignore in the master repo.
• Solo founder: start with the master repo only.
• Team member: open the master repo plus only the nested repos they can access.
• Founder: clone what you need, but run restricted AI tasks inside the matching nested repo.

Start with the master repo. Keep it plain. Let the AI read what it should, ignore what it shouldn’t.

Company structure is company strategy. Name it well, lock it properly, and the AI can work.

Your data. Your rules. Let’s write it that way. By Charles Henri Gayot.