Your agents deserve more than just a git repo

What are the best ways to provide memory to your agentic organization?

Let me start with the greenfield case, because it’s easier to see the architecture when you’re building from scratch.

At Gather, I have four sources of truth. The first is a small, tight GitHub repo. It holds the agent definitions, shared skills, and high-level context that every agent needs: company vision, mission, culture, values. Agents also get their own subdirectories to persist session notes, individual learnings, and anything I’d expect an employee to remember but wouldn’t save to a playbook or system of record.

The second is a Postgres database. This is the central brain for the business and the coordination hub for the agents. Contacts, companies, projects, tasks, research findings, inter-agent messages: all structured data, all queryable, all accessible from any session on any machine.

The third is a wiki which allows me to persist playbooks for internal and external actors (venues, vendors, sponsors, participants, speakers, organizers, etc) with both human and agent readable content to minimize operational friction.

The final is Blob storage for pdfs, mp4’s or anything else that would bloat a git checkout and doesn’t need to be in a relational database.

That’s the whole architecture. Repo for identity and capability, database for state and coordination, wiki for collaboration and blob storage for binary files. The question is why this specific split, and what breaks if you get it wrong.

This isn’t novel. A new hire starts Monday. Where do they find what they need to know? Some of it’s in people’s heads. Some is on the team wiki. Some is in the CRM or the project tracker. Every organization has this layered knowledge architecture, whether they designed it deliberately or let it accumulate in random Slack threads and Google Docs.

Agentic orgs face the same question with different actors, and the answer is the same layered architecture, but with a constraint that changes the calculus: you might have ten Sloanes working on different projects at the same time.

The ten-Sloanes problem

Humans can’t be in two places at once. Agents can. My Head of Engineering might be reviewing a database migration in one session, building a new skill in another, and pairing with me on architecture in a third. Each instance checks out the repo. Each instance might want to write.

If Sloane’s working memory, project status, and task list all live in markdown files in the repo, those ten sessions are going to spend more time resolving git conflicts than doing useful work. This is not a theoretical problem. It’s the first thing that breaks when you scale past a handful of concurrent sessions.

The constraint has no human parallel, and it forces an architectural decision that turns out to work really well: separate what agents need to be from what they need to know.

Four layers, same as any org

You already saw the four sources of truth. Here’s how they map to the layers every organization already has, with the design rationale for each.

Personal memory (what’s in your head). Each agent has a memory.md in the repo. Session observations, working context, things the next version of them will need. This is the agentic equivalent of what a person just knows from experience. It’s small, it’s personal, and it lives in the repo because it’s part of who the agent is, not what the agent is working on.

Shared context (the team wiki). Less structured institutional knowledge that multiple agents or stakeholders need. A wiki backed by a database with row-level security. Internal agents see everything. External partners see what you share. Same pattern as an internal Confluence with guest access, but without the $8/seat/month.

Structured data (the system of record). People, companies, projects, tasks, workflows, event history. This is Postgres. A contact has a company. A company has a tier. A project has tasks. Tasks have agents. You can query “show me all critical tasks for Sloane across active projects.” Try doing that with markdown files.

Blob storage (the filing cabinet). PDFs, images, large exports. Supabase Storage, S3, whatever. The 50MB PDF in your git history slows down every checkout for every agent instance forever. Put it in blob storage and reference it by URL.

Why the database changes everything

The relational model gives you something markdown never will: relationships. When Morgan asks “which sponsors have we contacted in the last 30 days who are Series B or later?”, that’s a SQL query. It’s not a grep through a folder of markdown files hoping the formatting is consistent.

But the bigger win is communication. When Elise finishes a research brief and needs to hand it to Morgan, she calls send_to_agent('morgan', ...). That writes a row to Postgres. Morgan picks it up in her next session, on any branch, in any worktree, on any machine. No pull. No push. No merge conflict. No waiting for someone to merge a PR.

This works because databases are built for exactly this problem. ACID compliance means messages don’t get lost or double-processed. Multi-user access means ten agents can read and write concurrently without stepping on each other. You can distribute for availability if you need to. And tables are natural state machines: a task moves from queued to active to completed, a message moves from to_process to handled. Workflows, projects, messages, tasks: these are all state that belongs in rows, not files.

As your system matures, you harden it. Wrap database functions with deterministic scripts that validate business rules, authenticate permissions, and log every operation for future analysis. The scripts become API endpoints. The endpoints become guardrails. You’re not building this all on day one. You’re starting with raw SQL from agent sessions and graduating to a proper service layer as the patterns stabilize. Same way any startup hardens its infrastructure: get it working, then get it right.

The management parallel is the difference between passing a note in a meeting and having a proper ticketing system. Inter-agent communication through the database is instant, reliable, auditable, and doesn’t touch the repo. When you have dozens of agent sessions running concurrently, this matters enormously.

The thin repo principle

Your git repo should contain three things: agent definitions, key shared context, and skills. That’s it.

The goal is to minimize two things: time to check out a worktree and start a session, and the surface area for git conflicts when many instances are running simultaneously. Every file you add to the repo is a file that has to be cloned, a file that could conflict, and a file that makes every agent session a little slower to start.

Projects, tasks, contacts, companies, research findings, event data, communication between agents: all of these are structured data that belongs in the database. Meeting notes, large documents, exports: blob storage. The repo is for identity and capability, not for state.

Think of it this way. You wouldn’t store your company’s CRM data in a git repo. You wouldn’t put your project management tool’s database in version control. The same logic applies to your agentic org. The repo is the org chart and the employee handbook. Everything else lives in the systems built to handle it.

The question isn’t whether...

Your agents are already accumulating institutional knowledge. Every session generates context. Every interaction creates state. Every correction refines understanding.

The question is whether that knowledge is landing in the right layer, or whether it’s piling up in markdown files that will buckle under the weight of ten concurrent sessions and a hundred files that should have been database rows.

Where does your agents’ institutional knowledge live?