Knowledge management for AI-native startups

Knowledge management for AI-native startups: why Notion is the floor, what an AI-readable layer looks like, and how git-versioned markdown beats the wiki graveyard.

There is a moment in every growing company where someone says, out loud, that the Notion has become a graveyard. Pages last edited eighteen months ago. Three competing versions of the onboarding doc. A dashboard that nobody opens because it has been wrong for so long that the wrongness is itself the brand. The team has stopped trusting the wiki and started DMing the one engineer who actually remembers where things are.

This is not a Notion-specific failure. Confluence has it. SharePoint has it. The earlier generation of wikis had it. It is the structural failure of any documentation system whose only consumer is a busy human being scanning for the one paragraph they came to read. Documents rot at the speed of attention.

What is new in 2026 is that you have a second consumer now. An agent. A Claude Code session, an AI sub-agent, a digest bot, a research orchestrator. It reads your knowledge base too. And it does not skim. It crawls every file, follows every link, holds every claim in working memory, and at some point starts shipping work back into your repo based on what it found. The question of whether your knowledge management system is good for machines turns out to be more interesting than the question of whether it is good for humans. A documentation layer that is good for machines is, almost by accident, also good for the humans who are paying attention.

This article is about that second layer. Why Notion is wonderful as a human inbox and mediocre as agent substrate. What "AI-native" knowledge actually looks like in practice. How to think about the parallel layer most small teams should build alongside their existing wiki, not instead of it. And why we think the first AI-native company you join will not have a Notion at all. It will have a git repo with markdown that the team reads and the agents read, and the distinction between "the wiki" and "the codebase" will be much smaller than it is today.

Notion is genuinely good. We want to say this first, because most "Notion is dead" posts come from people selling something, and we are too, so the bias has to be acknowledged up front. Notion is the cleanest, most thoughtfully designed knowledge product of the last decade. The fact that a 15-person startup can have a usable wiki in 48 hours, with databases and templates and dashboards, is a small miracle of product design. Saying otherwise is intellectually dishonest.

The iPhone is also genuinely good. It is the cleanest, most thoughtfully designed consumer device of the last two decades. And yet you would not run your build server on it. You would not write your codebase on it. You would not give your AI agent root access to it. The iPhone is a perfect endpoint and a terrible substrate. Notion is the iPhone of knowledge bases.

Garden's thesis, which we will spend the rest of this article defending: the first AI-native company you join will not have a Notion. It will have a git repo with markdown that the team reads and the agents read. Notion will still exist somewhere in the stack, probably as an inbox or a social-collab surface or a public-facing intranet. But the ground truth, the substrate the agents actually crawl when they do work, will be a folder of versioned text files that humans can also read.

The transition cost from "Notion-only" to "Notion plus a markdown ground-truth layer" is real and we will not pretend otherwise. Most small teams should still start with Notion. We mean this. The cost of a markdown-and-git substrate before you have any agents using it is mostly a cost without benefit. The interesting question is when the transition becomes worth paying for, and our argument is that it gets cheaper faster than most teams realize, because the agents that make it worth paying for are showing up in their stack whether they planned for it or not.

The phrase "AI-native" has been so thoroughly looted by vendors that we have to define it carefully or it means nothing. Here is what we mean.

A piece of documentation is AI-native if all four of the following are true:

1. An agent can read it losslessly through a stable, low-friction interface. Not through a rate-limited API that returns 100 blocks at a time. Not through an OAuth flow that has to be refreshed every session. Through cat or read_file or grep. The full content, in one operation, in the format the agent's tokenizer expects.

2. It has diffable, attributable history. When something changed, an agent (or a human) can ask: when, who, why, and what did it look like before. Not "the page was edited yesterday." A line-level diff, with commit messages explaining intent.

3. It is composable into atomic units. An agent can pull in just the relevant section, not the whole 4,000-word strategy doc, when it needs to make a decision. The unit of retrieval is smaller than the unit of authorship.

4. It lives next to the agents and skills that operate on it. The instructions for "how to summarise a playtest report" are stored in the same repo as the playtests, versioned alongside them, and updated when the format changes. The knowledge and the procedures that act on it are not in different systems.

By that definition, most Notion workspaces are not AI-native. Most Confluence instances are not AI-native. Most Google Drives full of Google Docs are catastrophically not AI-native. They were not built to be. They were built for humans browsing, which is a different problem.

This is also, importantly, not a criticism of those tools. A hammer is not bad because it is not a screwdriver. It is just that the work has changed, and the tool that was perfect for the previous work is now suboptimal for the new work. If your team has zero agents in the loop, none of these properties matter and Notion is great. If your team has one agent in the loop (and it almost certainly does, by 2026, even if nobody officially calls it that), some of these properties start to matter. If your team has five agents in the loop, all of these properties matter, and Notion as the only substrate becomes a tax you pay every day.

Let us be specific about the failure modes. We have spent enough time with the Notion MCP and the Notion API to be precise about where it bends.

Weak hierarchy. Notion's data model is a tree of blocks, but the tree is shallow and the semantics of nesting are inconsistent. A heading does not always indicate a section boundary. A toggle is sometimes a structural container and sometimes just a UI affordance. A page can be a database row, a database itself, a sub-page, or an embed of another page. When an agent crawls this, it cannot reliably infer "what is the unit of meaning here." It has to guess, and the guesses are wrong often enough that you start writing wrappers, and the wrappers are brittle.

No diffable history. Notion has page history, in the sense that you can see "this was the page yesterday." It does not have what git has: a line-level diff with a commit message, attributable to a specific change, replayable as a sequence. When an agent wants to understand why a piece of documentation says what it says, it cannot. The reasoning is lost. This matters more than people realise once you start trying to debug an agent's behaviour: half the time the agent is wrong because the doc is wrong, and you cannot reconstruct when or why the doc became wrong.

No atomic notes. A Notion page is the unit. There is no good way to say "the second paragraph of the page about pricing, specifically, is the canonical source for our enterprise discount policy." You either link to the whole page (and hope the agent finds the right paragraph) or you copy the paragraph into another page (and now you have two sources that will drift apart). Atomic note-taking systems (Zettelkasten, Obsidian's "every note is a node") solve this. Notion structurally does not.

Lossy API access. The Notion API returns blocks in batches of up to 100. A long page requires multiple round trips. Database queries with rollup or formula properties sometimes return values that look right but lose precision compared to the UI. Synced blocks, embedded databases, and inline page references are notoriously underspecified through the API. An agent reading a complex Notion workspace through the API is not reading the workspace humans see. It is reading a degraded shadow of it, and the degradation is silent.

Rate limits. Notion's API limits are tight enough that an agent doing serious work hits them in normal use. Three requests per second average. For a single agent doing a focused task this is fine. For a team of five agents running in parallel, sharing one workspace, it becomes a serialisation bottleneck you did not design for.

Notion AI only writes back into Notion. The most-mentioned Notion limitation, and worth saying again because it is true: the AI features inside Notion are scoped to Notion. They cannot create a tag in Linear, push a commit to a repo, post in Slack, or trigger a CI build. For a team where the work lives in Linear and Git and Slack, an AI that only sees Notion is an AI looking at a stale reflection of the actual work. The friction is not catastrophic but it is constant.

None of these are reasons to abandon Notion. They are reasons to be honest about what Notion is and is not. Notion is a beautiful surface for humans browsing. It is a mediocre substrate for agents acting.

If we strip the Notion-specific argument away and ask what a substrate optimised for both human reading and agent action looks like, four properties emerge. These are the four we want to design for, regardless of which tool we end up using.

Locality. Knowledge lives next to the work it describes. The README for a project is in the project's repo. The skill that generates release notes for that project is in .claude/skills/ of the same repo. The team's coding conventions are in CLAUDE.md at the root. An agent working on the project does not have to traverse three systems to find the context it needs. A human doing the same does not either.

Plain text. The file format is human-readable without special software, machine-parseable without an API, and stable across decades. Markdown is the obvious answer. It has the rare property of being both pleasant to write in a text editor and trivial to grep. There is a reason every major AI lab settled on it as the lingua franca of agent context.

Versioned with intent. Every change has an author, a timestamp, a diff, and a commit message that explains why the change was made. This is what git gives you for free and what every other system either lacks or simulates badly. The commit message is the single most underrated piece of documentation in software, and we extend it to documents.

Composable. A knowledge unit can be a one-line MOCs.md (map of content) entry that links to a 4,000-word reference doc, which itself can be split into sections that other docs reference by anchor. The unit of retrieval is whatever the agent needs, not whatever the author happened to write at once.

Notice that none of these require git or markdown specifically. You could in principle build an AI-native knowledge base on a different substrate. We just have not seen one that works better in practice. The combination of "plain text in a folder + git for versioning + markdown for structure + a CLI any agent can read" is the lowest-friction stack we have found, and the one production systems are converging on. (See, for instance, the architectural patterns described in the markdown-versioned-folders-agent-brain post that has been circulating among practitioners, or any open-source agent project on GitHub, where this is now the default.)

So what does the alternative actually look like when you sit down to build it. Here is what we install for clients in a Garden "dynamic office" engagement, with the rough rationale for each piece.

A single git repository per company-or-team. Not one per project. One per team, with subdirectories for projects. The reason is that agents do their best work when they can see the relationships between projects, and a single repo makes "find every mention of customer X across all our work" a ripgrep command instead of an integration project.

Markdown as the primary format, with a clear convention. Every doc is .md. Headings follow a predictable pattern (# Title, ## Section, ### Subsection). The first paragraph of every doc is a one-sentence "what this is" summary that the agent can pull as a snippet. Filenames are kebab-case, descriptive, and stable. None of this is novel; it is just disciplined.

A CLAUDE.md at the root. This is the contract between the team and the agents. It explains, in plain language, the team's conventions, the meaning of unusual directory names, who the team is, what is in scope and out of scope, and any "watch out for X" pitfalls a fresh agent should know. Every agent run starts by reading this file. It is the single most important file in the repo and the one that requires the most ongoing care.

A .claude/ directory next to it. This is where agents and skills live, versioned alongside the documents they operate on. .claude/agents/ contains role definitions for sub-agents (the GDD editor, the playtest digester, the meeting summariser). .claude/skills/ contains reusable skills (how to format a customer brief, how to draft a release note, how to summarise a research paper) that any agent can use. .claude/settings.json defines the permissions (what the agent is allowed to do without asking) and is itself a versioned artifact that the team can review in pull requests.

Git itself. Hosted wherever the team's code already lives: GitHub, GitLab, Gitea, your own server. Every change goes through a pull request, including changes made by agents. This is the audit trail. It is also the review mechanism: when an agent does something weird, the PR shows you exactly what it did, and you can roll it back with one command.

A read path for agents. The agent reads the repo through whatever runtime it uses. For Claude Code, this is just the filesystem: Read, Grep, Glob. For an MCP-based agent, it is a filesystem MCP server or a git MCP server. For an LLM in an API call, it is a tool that returns file contents. Crucially, the read path is the same path a human takes. The agent is not getting a degraded view of the data. It is getting the same data, in the same format, with the same fidelity.

A write path for agents. Agents do not push to main. They branch, commit, and open a PR. A human (or, for low-risk changes, a less-permissive agent) reviews and merges. The branch-and-PR pattern gives you a chance to catch agent mistakes before they propagate, and it gives you a record of every change the agent ever made.

Optional: a semantic search layer. For repos beyond a few hundred files, plain ripgrep starts to lose. An optional layer (an Obsidian-style graph + embeddings, a knowledge-base MCP server, or a vector index over the repo content) gives the agent retrieval by meaning instead of by keyword alone. The knowledge-base-server project is one community-maintained option here. We treat this as a "phase 2" addition, not a day-one requirement.

That is the stack. There is no single vendor, no enterprise license, no proprietary format. It is shockingly cheap in tooling costs and shockingly expensive in discipline costs. We will be honest about this trade-off in the "When this is the wrong approach" section.

Abstract architecture is abstract. Here is a concrete folder structure we have used, with light adaptation per client. Read it as a starting point, not a prescription.

team-os/
├── CLAUDE.md                    # team contract for agents
├── README.md                    # for the humans
├── .claude/
│   ├── agents/                  # sub-agent role definitions
│   │   ├── researcher.md
│   │   ├── editor.md
│   │   ├── digest-builder.md
│   │   └── meeting-summarizer.md
│   ├── skills/                  # reusable agent skills
│   │   ├── draft-release-notes.md
│   │   ├── format-customer-brief.md
│   │   └── summarize-research-paper.md
│   └── settings.json            # permissions, allow/deny lists
├── people/                      # who's who, ownership maps
│   ├── alice.md
│   ├── bob.md
│   └── _team-map.md
├── projects/
│   ├── project-A/
│   │   ├── README.md            # what this project is
│   │   ├── design/              # specs, decisions, ADRs
│   │   ├── operations/          # plans, status, retrospectives
│   │   ├── customer/            # customer-specific context
│   │   └── postmortems/
│   └── project-B/
├── ops/                         # infrastructure, deploys, runbooks
├── meetings/
│   ├── 2026-06/                 # one folder per month
│   │   ├── 2026-06-03-weekly.md
│   │   └── 2026-06-10-customer-call.md
├── knowledge/                   # internal wiki, glossary, evergreen
│   ├── glossary.md
│   ├── decisions/               # architecture decision records
│   └── references/              # external sources, link archive
└── inbox/                       # fast capture, to be triaged

A few principles encoded here that are worth pulling out.

Project-shape directories are predictable. Every project has design/, operations/, customer/, postmortems/. When an agent is asked "what is the status of project A," it knows where to look without being told, because the shape is the same across all projects.

Time-bucketed folders for ephemeral content. Meetings, weekly digests, daily logs go in YYYY-MM/ folders. Old folders are read-only by convention. This gives agents a consistent way to ask "what happened this month" without ambiguity.

A small set of canonical evergreen folders. knowledge/ is the place for things that should outlive any one project: definitions, decisions, references. This is where the team's institutional memory accrues.

An explicit inbox. Things that are not yet sorted go here. Agents triage the inbox on a schedule (we usually have a digest-builder agent that empties it into the right home folders weekly). The presence of an inbox is the safety valve: it stops people from refusing to write things down because they do not know where to put them.

.claude/ is next to the work. Not in a separate "AI tooling" repo. The agent that summarises playtests lives in the repo that contains the playtests. When the format of a playtest changes, the agent definition changes in the same commit. There is no drift between "what the agents do" and "what the team does."

This is roughly the structure we describe in our dynamic office proposal, and the structure several of our clients have adapted into their own setups. Yours will be different. The important thing is that there is a structure, that it is documented in the repo itself, and that it is stable enough that agents can rely on it.

It is one thing to argue that this layer is "better for agents" in theory. It is another to look at what an agent does, mechanically, when it starts a session. Let us walk through a concrete example, because abstraction at this point is unhelpful.

A team uses Claude Code as their daily agent runtime. A developer opens a session and asks: "Draft the release notes for v0.4.2."

Step 1, the agent reads CLAUDE.md at the root of the repo. This tells it the team's conventions: that release notes live in ops/releases/, that they follow a specific format, that they should pull from the git log between tags, and that the previous release was v0.4.1.

Step 2, the agent checks .claude/skills/draft-release-notes.md. This is the team's reusable skill for this task: a precise prompt describing the format, the tone, the level of detail, examples of good and bad release notes from past work.

Step 3, the agent runs git log v0.4.1..HEAD --oneline to get the list of commits. It reads the bodies of the more substantive ones to understand what shipped.

Step 4, it cross-references the commits against projects/*/operations/ to find the intent behind the changes (the spec that triggered the work, the customer ticket that drove it). This is where the locality property earns its keep: the spec and the code are in the same repo, in predictable places, and the agent can find the connection without an integration.

Step 5, it drafts the release notes, opens a branch (release-notes/v0.4.2), commits the draft, and opens a PR. The PR description includes the prompt the user gave, the skill used, and the list of commits considered. This is the audit trail.

Step 6, the human reviews the PR. If anything is wrong, they edit it directly in the PR or comment for the agent to revise. The merge is the publication.

Notice what is not in this workflow. No API rate limit. No OAuth refresh. No "the agent could not access block B-7c2 because it is nested under a synced block." No "the agent saw the page but missed the database property." The agent has full, lossless access to the repo and full, lossless access to git history. Every step is reproducible. Every step is auditable. The release notes are written in the same place they are stored, in the same place they will be read.

Now imagine the same workflow with a Notion-only stack. The release notes live in a Notion page. The team's "how we write release notes" guide is in another Notion page. The git log is, of course, not in Notion. The intent (specs, tickets) is partly in Notion, partly in Linear. The agent has to make four cross-system trips, one of which is rate-limited, two of which require auth, and one of which silently truncates. The release notes get drafted in a Notion page, but the audit trail (what commits were considered, what skill was used) is either lost or hand-pasted into a comment.

It works. We are not saying it does not work. We are saying the friction is constant, the failure modes are silent, and the trust the team can place in the agent is correspondingly lower. The Notion-only workflow scales to one agent. The git-and-markdown workflow scales to ten without changing shape.

We have been arguing for a parallel layer, not a replacement. This is the part where we are specific about what goes where.

Keep in Notion. The things humans browse socially. Team handbook, public-facing pages, customer-facing wikis, the company-wide all-hands recap. The HR documents that need a pretty interface. The marketing calendar. The onboarding checklist that has GIFs in it. The internal blog. Anything where the consumer is a human in a hurry, not an agent doing focused work.

Move to the git-versioned markdown layer. The things agents need to act on. Project specs (the canonical version; a one-paragraph "what this is" can stay in Notion as a pointer). Engineering decision records. Customer-context briefs that agents draft against. Skills and agent definitions. Internal reference docs (the API of your own systems, your data schemas, your conventions). Anything where the consumer is a human or agent doing focused work.

Bridge between them. A pointer in Notion that links to the canonical doc in the repo. A one-line snippet generated by an agent and synced into Notion as the "public" version, with a footer that says "canonical source: team-os/projects/X/design/Y.md." This avoids the worst Notion failure mode (two versions of the same doc drifting apart) by being clear about which one is the source.

In practice, the split tends to be 60-70% of pages remain in Notion (the social and human-browsing layer) and 30-40% move into git (the ground-truth layer the agents read). The exact ratio depends on how much focused work the team does versus how much social coordination.

There is also a third option that some teams adopt and we think is generally a mistake: putting everything in the markdown layer and deleting Notion entirely. It works for teams of mostly engineers who are comfortable in a terminal. It fails everywhere else, because non-technical team members feel exiled from their own knowledge base. The cost of losing them is much higher than the cost of running both layers. Run both.

This is the architecture we describe in our three-options whitepaper for teams trying to decide between "Notion-first," "Notion + AI agents," and "AI-native server office." The middle option (Notion plus a markdown ground-truth layer) is the one most small teams should land on, in our experience. It is rarely the one they start with.

This section is the one most architecture posts skip and we will not. Here are the cases where building a git-versioned markdown layer is the wrong call.

Your team has zero agents in the loop and no plans to add any. If the only consumer of your docs is humans, and you are not exploring agentic workflows, the AI-native properties cost you something and buy you nothing. Stay on Notion. Revisit in a year.

Your team is < 5 people and entirely non-technical. The cost of the markdown layer is paid in terminal-fluency. If nobody on the team is comfortable in a CLI, you will spend more on training than you save in agent productivity. Build a great Notion workspace, hire someone who knows how to maintain it, and revisit when you have an engineering hire.

You cannot or will not adopt PR-based review. The whole agent safety story rests on agents writing to branches and humans (or higher-trust agents) reviewing PRs. If your team's culture is "everyone has admin access and edits straight into prod," the markdown-and-git layer does not solve your problems, it amplifies them. Fix the review culture first.

Your docs are mostly visual. If your knowledge base is half-figma-embeds, half-Loom-recordings, half-screenshots-with-arrows, the markdown layer is going to feel sparse. Markdown supports images and embeds, but it is fundamentally a text format, and a team whose primary medium is visual is going to find it constraining. (We have one client, a games studio, where the GDD has thousands of inline images. We use markdown for the structure of the GDD and Notion for the gallery of mood references. The split is not always clean.)

You are betting on a non-agentic future. If you genuinely believe AI agents are going to plateau, that the LLM-as-team-member pattern is a fad, that 2027 looks more like 2022 than like 2024, then most of this article is irrelevant. Stay on Notion. We disagree with the bet, but it is a coherent position to hold, and someone holding it should not pay the transition cost.

The honest framing: there is a window in a company's growth where the parallel layer makes obvious sense, and that window opens earlier than most teams realise (somewhere between five and twenty people, around the time the first agentic workflow gets reliable enough to depend on) and closes later than most teams realise (you can keep adding it to a larger team, but the cost grows with the size of the existing Notion). If you are inside that window, this is the architecture conversation worth having. If you are outside it, do something else.

Is this just "use git for docs"? Yes, partly. The novel thing is not git or markdown; both have been around for decades. The novel thing is treating the same git repo as both the human knowledge base and the agent substrate, with the agents and their skills versioned alongside the docs they act on. That second piece (.claude/agents/ and .claude/skills/ in the same repo as the work) is the architectural shift, not the choice of file format.

Do we lose the nice UI? Notion is so pretty. You lose the rendering, yes. You gain it back, partly, through editors like Obsidian (which renders markdown beautifully and supports backlinks and graph views), VS Code (with markdown preview), Logseq, or a static-site generator that publishes the docs as an internal site. None are as visually polished as Notion. All are good enough for most internal work. If "pretty" matters more than "agent-readable" for a specific doc, keep that doc in Notion. The point is to use the right substrate for the right job, not to give up beauty entirely.

What about people who don't use the terminal? Two options. First, Obsidian works on a folder of markdown files and is what most non-developer users prefer in our deployments; it has a mobile app, a clean editor, and no required CLI. Second, web-IDE tools like Coder or Gitpod (self-hosted) give a browser-based VS Code experience that even non-engineers can adopt. The "you must be a terminal expert" framing is outdated; the substrate is markdown-and-git, the interface can be anything.

How do we handle search across the markdown layer? For repos under a few hundred files, ripgrep is enough. For larger repos, add a semantic-search MCP server (a small Python service that indexes the markdown into embeddings and exposes a search tool to agents). Several open-source options exist, including the knowledge-base-server project. The pattern is: keep the canonical content in plain markdown, layer indexing on top for retrieval, do not let the index become the source of truth.

What about real-time collaboration? Notion lets two people edit the same page. This is the one place git-and-markdown is genuinely worse. Real-time co-editing on markdown files is awkward; you typically end up with one person editing at a time, or you use a tool like HedgeDoc or VS Code Live Share for the co-editing moment and commit the result back to the repo. For docs where co-editing matters (meeting notes, brainstorm sessions), some teams keep those in Notion or a HedgeDoc instance and only promote them to the repo when stable. This is a real trade-off and we will not pretend it is not.

How do permissions work? Notion has page-level sharing. At the layer of "who can read what," permissions live in the git host (GitHub, GitLab, Gitea): repo access, sub-module access, separate repos for sensitive content. At the layer of "who can run what," permissions live in .claude/settings.json and in OS-level user groups on the server hosting the agents. This is more powerful than Notion's permission model (it scales to thousands of files and supports cryptographic secrets management) but also more involved to set up. Plan a half-day for the initial permissions design; it is a one-time cost.

Doesn't this require a DevOps person? At small scale, no. A git repo on GitHub plus Claude Code on a laptop is enough to get started; no server needed. At medium scale (a team of 10-20 sharing a server with multi-user Claude Code), yes, you want someone comfortable with Linux user management, SSH hardening, and basic monitoring. We typically scope this at 0.1-0.2 FTE for a 15-person team; it is not a full-time role, just someone who owns the substrate. If nobody on the team can or will do this, the architecture is wrong for you.

We do not believe Notion is going away. We do believe it is going to settle into a more honest role than "the canonical knowledge base for everything we do." That honest role is closer to "the human-facing inbox and social-collab layer," with a parallel ground-truth layer underneath it that the agents actually crawl. The two systems will coexist, and the bridge between them will be a small, careful set of pointers and synced summaries rather than a heroic attempt to make one tool do both jobs.

If you are starting a company in 2026, our advice is: open Notion on day one because you need a knowledge base now, not in three months. Then, the moment you have your first reliable agentic workflow (the digest bot, the customer-brief drafter, the meeting summariser that the team actually trusts), start the parallel markdown layer. Move the ground-truth docs the agent depends on. Keep the social layer in Notion. Live with both, deliberately, for the rest of the company's life.

If you are running a 5-20 person team and the Notion is rotting, this is the architecture conversation we have in a Garden engagement. We audit the actual knowledge flow (where docs live, who edits them, what the agents need to read), we propose a split (what stays in Notion, what moves to the markdown layer, what bridges between them), and we install the substrate (the repo, the CLAUDE.md, the first set of skills and agents, the permissions model). It typically takes 6-10 weeks end-to-end and leaves the team with a substrate they can extend without us.

If you want to talk about whether this fits your situation, email a@gardenresearch.eu. We do not sell roadmaps. We install systems and train teams to maintain them.

This article is part of Garden Research's writing on AI-native infrastructure for small companies. If you have built one of these layers and learned something we missed, we would like to hear from you.