One folder per client is right. The client cannot open a repo.

The structure that is spreading

On 19 August 2026, Jordan Ross posted a description of how he thinks the better marketing agencies are now organised. Two hundred and fifty five likes, and worth reading as an architecture rather than a hot take: the agency operates out of GitHub. Every client has a folder in a repo. The AI skills, agents and workflows live in there too. Company SOPs get their own folder.

It is not an isolated post. The same month, an operator described running a firm on forty agents split across marketing, sales, finance and operations, with every open piece of client work tracked in one place. Another described an agency that grew by handing work to an AI employee that pulled the data, built the sequences and pushed deliverables through for approval. Different scales, different levels of hype, one shared assumption: the work is produced by machines that need a filesystem, and the filesystem should be organised by client.

Meanwhile, on 19 August, an agency asked r/nocode how to build a custom client portal, explaining that they were currently managing clients across Drive, Notion and Slack. That is the same instinct arriving from the other end of the technical spectrum. Both groups have worked out that the client is the unit. Both then hit the same wall, and only one of them can see it.

Why the folder is the right unit

Take the pattern seriously for a moment, because it deserves it.

Organising by client rather than by project or by tool is the correct call, and it is more correct now than it was two years ago. Three reasons.

• Agents are good at filesystems. A directory of context is the most reliable way to tell a model what it is working on. Point an agent at clients/acme/ and the brand rules, the last four deliverables, the tone of the account and the constraints of the business are all in scope without anyone assembling a prompt by hand.
• Specificity is the thing being sold. The complaint clients make about AI-assisted work is that it reads like it could have been written for any business in the sector. Per-client context is the direct fix, and it only exists if there is a per-client place to keep it.
• Everything gets a history. Version control is not glamorous, but knowing what changed, when, and against which brief is the difference between an agency and a folder of PDFs. The SOPs improve in the same repo as the work, which is how they stay true.

None of that is the part I want to argue with. The structure is right. The problem is that it is only half specified, and the missing half is the half the client pays for.

The half nobody specifies

Read the posts again and notice what they describe. Ingestion, context, generation, tracking, approval. Every one of them is an internal loop. The deliverable moves from the agent to the team, and there the description ends.

But the deliverable is not finished when the team approves it. It is finished when the client has it, can find it again next quarter, and can tell it came from you. That last stretch, from the folder to the client's browser, is doing an enormous amount of unglamorous work in these architectures, and in almost every account of them it is left as an exercise for the reader. In practice it collapses back into whatever it always was: a PDF attached to an email, a Drive link, a screenshot pasted into Slack.

So you end up with a genuinely modern production system feeding a delivery method from 2011. The internal half is versioned, structured and per-client. The external half is an attachment with a filename ending in _v3_FINAL.

What happens if you try anyway

The obvious move is to make the repo do it. It does not work, and it is worth being specific about why rather than hand-waving.

Giving the client the repo. Read access to a private repository is granted to a GitHub account. The client needs one, needs to accept the invitation, and then needs to operate an interface built for people who read diffs. You set out to escape a portal login and arrived at a harder login attached to a steeper interface. For a non-technical client this is not a marginal downgrade, it is a deliverable they will never open.

Publishing with GitHub Pages. GitHub is clear in its own documentation: Pages sites are publicly available on the internet by default, even when the repository behind them is private. Private publication exists, but it requires GitHub Enterprise Cloud, and a privately published site is readable only by people with read access to the repository, which returns you to the client needing an account. The two available shapes are a public URL for confidential client work, or an account requirement. Neither is a handover.

Wiring up a static host. This is the version that mostly works, and it is where careful agencies end up: a build step, a deploy target, a subdomain, an auth layer bolted in front because the work is confidential. It is a real solution. It is also a small infrastructure project per client, maintained forever by the person who least wants to maintain it, and it puts a deploy pipeline between an agent finishing a document and a client reading it.

The common failure in all three is a category error. A repository is a system of record for things that change and need history. A deliverable address is a system of presentation for things that are finished and need to be read. Asking one to be the other produces either an exposed URL or an account requirement, every time.

The same idea, pointed outward

Here is the reframing that makes the missing half obvious. One folder per client is an inside-facing structure. What it implies, and what almost nobody builds, is the outside-facing twin: one address per client.

Same unit, opposite direction. The folder holds sources, drafts, context and history, and is read by you and your agents. The address holds finished work only, is read by the client, and contains nothing they should not see. The folder is versioned. The address is current. The folder is private by permission. The address is private by being unguessable and gated.

An agency organised by client on the inside and disorganised at the handover has built half a structure. The tell is that the client's experience of a well-run, agent-native agency is identical to the client's experience of a chaotic one: an email with a file on it.

Plain disclosure before the next section, since it is the part where we describe our own software: this is Stacktree's blog, and Stacktree is the outside-facing half of this argument. Weigh it accordingly, and note that nothing below asks you to change the inside half at all.

What it looks like in practice

Keep the repo exactly as it is. Add one step at the end of the pipeline.

When the agent finishes a deliverable, it publishes the HTML and names the client in the same call. The client space is created on first use, so there is no setup call and nothing to keep in sync with your folder names. The page becomes a private address, and it joins everything else published for that client at one permanent address, newest first, with dates.

Point acme.youragency.com at that space and it is your domain in the client's address bar rather than ours. Under a verified parent domain there is no per-client DNS to do, which matters when the twentieth client arrives. Put a passcode or a restriction to the client's company email domain on the space, and every page under it inherits the gate: the client passes it once and that browser stays in for thirty days. No account, no invitation, no seat on your invoice.

The agent-side loop is the part that matters for a repo-first agency. From Claude Code, Codex, Cursor or any other MCP client, an agent can list what it has already published for a client, read a page back, revise it, and update it in place at the same URL. Revision in place is what stops the client accumulating four links and reading the wrong one. The link you sent in March is still the link, and it still shows the current version.

Filing pages under a client is free on every plan, including the free one, because grouping your own work should not be a paid feature. The paid unit is the address: Solo at $19 a month includes one activated space, Studio at $79 includes ten and Firm at $249 is unlimited. Clients are never seats, so a space costs the same whether one person at Acme opens it or nine do.

What this does not replace

The boundary is worth stating plainly, because the whole argument is about keeping two systems distinct.

This is not version control and it should not be treated as one. There are no branches, no diffs, no pull requests, no history of the sources. Your repo remains the system of record, and if the repo and the published page ever disagree, the repo is right. Source files belong in the folder and nowhere else. A published page is a rendered artefact for a reader, not a backup and not a distribution channel for your working files.

It is also not a portal suite. No file collection from the client, no e-signatures, no invoicing, no payments, no messaging, no project management. If the login in your workflow is genuinely earning its keep on any of those, keep the portal you have. Plenty of practices run all three: the repo for production, a suite for paperwork, and an address for the work itself.

The point

The agencies moving into repos have got the hard part right. They worked out before most of the market that the client is the unit of organisation, that agents need per-client context to produce anything worth sending, and that the work should carry a history.

Then they stopped at the edge of their own network. The last hop, the one the client actually experiences and the only part of the system they will ever form an opinion about, is still an attachment.

One folder per client on the inside. One address per client on the outside. The second one is not a smaller version of the first, and it is not the repo with the permissions loosened. It is the other half of the same idea, and it is the half your client is paying to see.