The Mega-Context Sandbox: how we stopped explaining our own projects to our tools

A note on the data: every number here comes from a system read taken on 25 August 2026 and is verifiable in the repositories and in telemetry. Where data is young or carries a caveat, we say so plainly rather than rounding in our own favour. Screenshots are unaltered.

The problem: context that doesn't survive a holiday

A marketing agency is a machine for producing context. Every month brings reports, audits, recommendations, decisions from calls, budget calls. The trouble is that this context almost never has a place to live.

So it lives a little bit everywhere: in the account manager's head, in a chat thread from three weeks ago, in a spreadsheet on someone's drive, in an email to the client. As long as the same people sit on the same project for a year, it more or less works. It stops working the moment somebody goes on holiday, a new person takes over — or, increasingly, an AI tool sits down to work.

Because an AI tool has exactly the same problem as a new person on the project: it knows nothing. Every session began with the same ritual — paste the data, explain the situation, recall what was agreed last month, mention that this client speaks English and that one speaks Polish. Fifteen minutes went by before the first useful question, and the quality of the answer depended on how much anyone could be bothered to paste.

It was the same cost an agency pays when onboarding a human — except paid daily, in every session, by every person.

Getting into a project isn't always the pleasant part — someone is on holiday, someone isn't around, someone hasn't got time. With repositories we can accumulate people's work and their knowledge in one place. Five minutes, instead of chasing the account manager and passing everything on by word of mouth.

The decision: the unit of context is a repository, not a folder

Client context gets its own git repository, not a folder on a drive.

That looks like a technical choice and is in fact an organisational one. A repository gives you four things a folder never will: history (who changed what, and why), permissions (who has access), a single source of truth instead of fourteen copies, and — this turned out to matter most — a structure you can enforce from the outside.

Because if all 113 sandboxes share an identical layout, a rule written once applies everywhere. A new skill reaches everyone in a single pass. So does a security fix. And a person moving between projects doesn't learn a new layout — they land in the same place.

We deliberately rejected the "one big knowledge base for all clients" approach. The reason isclient data separation. One client's sandbox cannot see another's data: each is a separate repository, and access is granted per team rather than across the whole group. In a shared base that boundary is a matter of discipline; here it is a matter of architecture.

Data is fetched through a gateway and never copied into the repository.The sandbox knows where the data is and how to reach it, but does not hold it. Client system credentials therefore never land in a repository, and the data is always current rather than as-of-last-export.

How it works: the anatomy of one session

Here is what happens between opening a project and the first answer.

1. A person opens the client repository and starts a session. They paste nothing and explain nothing.
2. Context loads itself — about 28,800 characters. A start-up hook assembles it from a dozen or so sections and hands it to the model before the first question. It includes, among other things: project identity (client, agency, maturity level), authentication status for the data gateway, data freshness with a warning when something has gone stale, the list of skills available in this specific repository, a map of connected data sources, repository state, and the policies in force.
3. The model knows what it does NOT have. In practice this matters more than the previous point. The sources section states plainly what is connected live — so the tool doesn't reply "I have no access to Google Ads" when it does. The opposite failure is closed off too: missing data for a period produces a "no data" message, not an invitation to guess.
4. Work runs on rails, not ad hoc. The context carries a five-phase template: load context, match intent, execute along a defined path, quality gate, deliver and persist. That last phase is not decoration — it means the output lands in a service drawer inside the repository rather than on somebody's drive.
5. Data is fetched through the gateway on demand. Two gateways serve 27 sources: 17 for reading (Google Ads, Search Console, GA4, Meta Ads, Merchant Center, Bing Webmaster Tools, PageSpeed, call transcripts, the project CRM and others) and 10 for writing (Sheets, Drive, Forms, ClickUp, Firecrawl and others). Credentials stay server-side.
6. The output stays in the sandbox. The next person — or the next session — starts from what is already known rather than from nothing. Context accumulates instead of evaporating.

What standing up a project used to cost

Before the sandbox existed, setting up an AI environment for a single project was a project of its own. You had to obtain and configure credentials for each source separately, wire and test the connectors, write a brief describing the client and the rules, schedule recurring pulls of transcripts and data, hand out permissions, and finally check that the whole thing actually worked.

The zeros in the right-hand column do not mean the work vanished. They mean it is done once, centrally — credentials live in the gateway, the brief comes from a template, and after start-up the data refresh runs in the background and costs nobody any time.

Being straight about that figure: it is an estimate built from enumerated steps, not a stopwatch measurement. We did not capture a baseline before we started building, which is why we give a range rather than a single number.

Guardrails you never set up per project

The second saving is harder to express in minutes. Every sandbox runs ten automated checks that nobody configures when a project is created: a linter for client-facing copy, protection of the project brief against overwrite, a warning when a commit comes from the wrong identity, a guard that makes sure output lands in its proper place, a secret scan before every push, and a quality gate before publishing. On top of that sit two data gateways: the read one blocks writes globally, the write one runs an allowlist of permitted operations.

The practical consequence is that someone still learning to work with AI can start on day one — without being able to ship something they shouldn't. Without that layer, the only safeguard would be restricting access, which means slowing people down exactly when they most need the practice.

Two commitments sit outside the repository and are worth stating plainly. The model provider operates under a data processing agreement, and client contracts have been updated to cover it. Where AI takes part in producing client-facing material, the client is told and the material is labelled.

Propagation: one source of truth for 113 places

Sandboxes would be worthless if each drifted its own way. So everything that defines behaviour — rules, skills, hooks, templates, safeguards — lives in one parent repository and is pushed downstream.

In practice a fix written once reaches 113 places in a single pass rather than in 113 conversations. The price is discipline: you edit a skill in the canon, never in a copy, because the copy will be overwritten on the next propagation.

The same layer watches the things nobody wants to remember: whether a repository has its full onboarding set, whether secrets have been committed into it, whether its structure has drifted from the standard. These checks run automatically and report deviations.

From consumer to contributor

At the start, one person wrote the skills and the team used them. Today the canon holds 207 skills, 47 of them authored and signed by 18 different people. Among the authors are specialists in Google Ads, SEO, analytics, creative and sales — people who are not developers and were never meant to be.

Every skill — from the sandboxes, from single repositories and from The Forge platform — is visible in one catalogue with filters by area, author and source. Each skill carries an origin label, so you can see whether it is part of the mega-context or a local tool.

The catalogue today lists 250 skills across 13 areas, from 19 authors, spanning 127 repositories.

Suddenly it turns out you can take a piece of your brain and hand it to someone else, in the form of a skill. That wasn't possible before.

Results: numbers and caveats

Scale four months after the first commit (8 April 2026):

• 113 sandboxes — 95 project, 17 role, 1 template, across 8 agencies in the group
• growth from 78 repositories in June to 113 in August
• 207 skills in the canon, against ~95 in June; 47 authored by 18 people
• 27 data sources through two gateways (17 read, 10 write)
• 96 domains with a daily data snapshot
• 42 people working in the sandboxes since April (2,829 commits, automation excluded)
• ~28,800 characters of context loaded automatically at session start

A single sandbox today contains: a 1,112-line project brief, 194 skills, 10 hooks, 31 commands and 13 service drawers.

What these numbers do not tell you

Three caveats change how these numbers should be read.

Usage telemetry is too young to draw conclusions from. We have been collecting it since 5 August 2026. Over the last 30 days we recorded 270 invocations of 25 distinct skills — but 242 of those come from a single scheduled job. Genuine human use is roughly 28 invocations. That is too little to call it adoption and too early to show a trend.

Commit counts mislead, and git identities mislead more. A scan of the full history showed 43,700 commits and 63 "authors" — but the overwhelming majority of commits come from automation running under a single identity, and many of those "authors" are the same person committing from three different git configurations. After excluding automation and consolidating identities, what remains is 42 people and 2,829 commits. We quote the second figure, because the first one sounds better and means less.

The before-and-after is an estimate, not a stopwatch. The project set-up table above was built from enumerated steps and the team's experience, not from a measurement taken before the rollout — no baseline was captured before we started building. That is why we give a range of 3.5–7 h rather than a single number. What we still lack is a measurement of savings in day-to-day work after a project is running. The telemetry exists precisely for that, and should produce harder numbers within a few months.

What this rollout taught us

I spend half a day switching between these sessions. Seventy per cent of my day is in this panel. And do you know what the future looks like for every hands-on specialist? I suspect exactly like that.

Context needs an address. You can write the best project brief in the world — if it sits in someone's folder, it does not exist. A repository gives context an address, a history and permissions.

Uniformity is what makes one fix work in 113 places. An identical structure across every sandbox is the only reason a fix written once works everywhere. Every exception to the structure is a future failure nobody will remember causing.

Fetch data, don't copy it. A copy of data inside a repository starts ageing immediately and turns the repository into a place where credentials can leak. A gateway solves both problems at once.

Tell the tool what it does NOT have. The biggest source of bad answers is not missing data — it is not knowing that data is missing. An explicit list of connected sources and a hard "no data" response are worth more than another skill.

Enforce client separation with architecture, not policy. Separate repositories with separate permissions hold the boundary by themselves. A shared base requires discipline — and discipline fails at five o'clock on a Friday.

Switch the telemetry on before anyone asks for results. The biggest gap in this rollout was not technology; it was telemetry that wasn't switched on at the start. Without a baseline you are left with numbers about scale rather than about value.

Read the companion case study: The Forge