A repository is a folder of files that lives on the internet, is shared with your entire team, and remembers every single change ever made to it — who made it, when, and why.
What a repository is
That’s it. It is not complicated software. It is not a developer tool, though developers have used it that way for years. At its core, a repository is just a place where files live together, openly, with a complete history of everything that has ever happened to them.
GitHub is the most widely used platform for hosting repositories. It is where millions of software projects are built and maintained by teams spread across the world, many of whom have never met in person. GitHub gives a repository an address, a web interface, and a set of tools for teams to collaborate, review each other’s work, and track what needs to be done. It is where this way of working starts.
Now, here is the shift: a repository is not only for code. A repository is for files. And almost everything a digital agency produces, plans, or manages is, at its foundation, a file.
A website is a collection of files until it is built and deployed. A proposal is a file. A creative brief is a file. A content calendar is a file. A client’s contact list is a file. A brand’s SEO strategy, its redirect map, its analytics configuration, its ad copy — all files. The entire surface area of a digital agency’s work can, in principle, live in a repository. Not as a backup. Not as an archive. As the active, living place where work happens.
The analogy: the job site
Think about how a construction project works in the physical world. There is a job site. Anyone who needs to know how the project is going can walk onto that site and see for themselves. The framing is either up or it isn’t. The electrical rough-in is either done or it isn’t. You do not need to schedule a call with the framing contractor to find out how framing is going. You walk over and look.
Now think about how a digital project works today. The designer is in Figma. The copywriter is in a Google Doc. The developer is in a codebase. The project manager is in Asana. The client feedback is in an email thread. The strategy is in a deck that was presented three weeks ago and has since been updated twice, with the latest version sitting in someone’s personal Google Drive under a folder called Final_v3_ACTUAL.
Nobody can walk onto this job site and see what is happening. The job site does not exist. Instead, a significant portion of every team member’s week is spent asking other team members where things stand, summarizing progress for people who weren’t in the last meeting, and reconstructing context that should have been visible all along.
A shared repository is the job site. It is the place you go to see what is actually happening on a project, without asking anyone.
What work looks like inside a repository
A digital agency that adopts this way of working would have a repository — or several, organized by client or by project — where the actual work accumulates. Not summaries of the work. Not status updates about the work. The work itself.
Here is what that might look like for a website launch:
The repository contains the website’s code and files. It also contains the content brief, the sitemap, the SEO keyword research, the copy drafts, the redirect mapping document, the analytics implementation plan, the launch checklist, and the client approval notes. Every one of these is a file. They all live in the same place. When the developer needs to know what the SEO team decided about URL structure, they do not send a Slack message and wait. They look at the file. When the project manager needs to know what is left before launch, they do not pull three people into a standup. They look at the repository.
The website being built and the documents surrounding its construction live side by side, in the same place, visible to everyone on the team at all times.
This is not a parallel planning layer that exists alongside the real work. This is the real work. The repository is the job site.
On-site work and off-site work
Not everything will happen inside the repository — at least not immediately, and in some cases not ever. Some tools are deeply embedded in how agencies operate. A client may require work to happen inside their HubSpot portal, their Google Ads account, or their legacy CMS. These are what you might think of as off-site work: execution that happens in an external platform, outside the shared repository.
But the repository remains the center of gravity even when execution happens elsewhere.
Before anyone logs into Google Ads to build a campaign, the campaign’s structure, its ad groups, its copy variations, its budget logic, its targeting rationale — all of that can be assembled in the repository first. The work of deciding and planning happens on-site. The work of deploying happens off-site. And when the campaign is live, the documentation of what was built, why it was built that way, and what was changed over time lives back in the repository.
The practical consequence of this gravity is that agencies and their clients will increasingly ask: does this work need to live in an external tool, or has it simply always lived there by default? A client’s CRM might be a sophisticated Salesforce implementation that cannot be migrated overnight. But a smaller client’s contact and pipeline management might translate perfectly well to a structured spreadsheet or a set of markdown files living right inside the project repository — simpler, more visible, and no longer locked inside a platform that charges a monthly fee to access your own data.
The direction of gravity is clear. Work migrates toward the place where everyone can see it.
Why AI changes everything about this
For most of the history of digital work, there was a practical reason why work got scattered across tools, platforms, inboxes, and individual hard drives: no single person or system could read all of it.
A large agency project might generate hundreds of documents, thousands of messages, dozens of briefs, multiple rounds of revised strategy, and a sprawling change history over the course of months. The only way to make sense of that volume of information was to hire people whose job was to gather it, summarize it, and pass it on — project managers, account leads, coordinators, directors of operations. These roles exist, in significant part, because information was trapped and someone had to move it.
AI changes this at a fundamental level. A modern AI system can read an entire repository — every file, every document, every line of copy, every decision log — and answer questions about it in seconds. “What is the current status of the homepage redesign?” “What did we decide about the site’s navigation structure and why?” “What is left before this project is ready to launch?” These questions used to require a meeting. They now require a well-maintained repository and a question.
This is not a speculative future capability. It works today, with tools that are already available.
The implication for agencies is significant. The organizational infrastructure that exists to move information between people — the status meetings, the update emails, the project summaries, the cross-functional syncs — does not disappear overnight. But its necessity weakens substantially when the work itself is visible, shared, and readable by both humans and AI systems. The agencies that build this infrastructure now, that establish the repository as the job site for all digital work, will operate with a structural efficiency that agencies still working across fragmented tools will not be able to match.
The job site already exists. The question is whether your team’s work is happening on it.