Where we're at.

Ahead on paper and on people. The gap is practice.

Mulago is further along than most foundations twice over: 7 of 14 people were using AI daily back in January, and the Feb guidance already makes the big organisational calls. What's left, and what these three months should ideally close, is the gap between what the guidance describes and how the team actually works day to day.

The baseline, in brief.

The team aligned on four things. Research is the use everyone rates. Data privacy was the top concern, raised by 6 of 14. People asked for organisational direction, on the record. And the heaviest builders and the most careful users wanted the same thing: one shared container instead of everyone working alone.

And split on three. Tool loyalty is personal and sticky. Writing help divides the room. And several daily tools ran on personal or free accounts, which sat awkwardly against the privacy consensus.

The full January read, with quotes, lives in the kickoff pre-read, kept as it was on Aug 3.

The concerns come from the heaviest users.

In their own words, all from people who use these tools every day:

"AI is making me dumber, not retaining as much."KENICHI · DAILY USER

"Writing is thinking."ALEX · DAILY USER

Worry that writing becomes "anodyne and dull."KEVIN · DAILY USER

"Authenticity and slop are hazards."CHRISTIAAN · DAILY USER

The guidance already makes the big calls.

I went through the Feb 11 AI Use Guidance line by line. My take: it's a genuinely strong document, and most of what January left open, it answers. Four calls it settles:

What it leaves open, by its own admission. Retention periods are all marked tbd. The bias work is named and scoped to 2026, and still to be built. The grantee transparency language is early examples, with the comprehensive version to come. And the seats-and-tooling question is flagged for discussion rather than decided. These four are the natural agenda for the guidance refresh on the shelf.

One more open item, surfaced on Aug 12. Stephanie named a risk the guidance doesn't yet cover: if a portfolio organisation shares an internal report with Mulago and it sits in a folder Claude can read, there is nothing today stopping that content surfacing in a conversation about a different organisation. The guidance is clear that humans make decisions, whereas it is silent on what one grantee's confidential material may be read alongside. Worth adding to the refresh agenda, ahead of the retention periods.

The gap between page and practice. The architecture the guidance specifies is partly live: the fellows team runs one Project per organisation with a standard operating procedure, whereas portfolio doesn't yet, and the back catalogue of organisations is still to be brought in. That migration is exactly what the architecture note takes on. The Projects convention is live and visible: fellows are named fellows - [org] and portfolio portfolio - [org], with the portfolio side yet to create theirs.

Two things I had wrong until this week, now corrected. First, the team is on Claude Team, not Enterprise. That doesn't change the guidance's intent, whereas it does change what admin controls and audit surfaces we actually have to work with, so it's worth being precise about. Second, the Box to Drive migration is decided but not started: none of it has moved yet, and Stephanie is targeting the start of next year, before the spring board meeting, with cleanup running ahead of the move itself.

On accounts, the January snapshot showed daily tools on personal and free tiers, which the guidance now rules out for Mulago data. My guess is practice has moved since then - worth a quick audit rather than an assumption.

None of this is unusual, for what it's worth. Guidance this good almost always runs ahead of practice for a while. The work is closing the distance, which is what the architecture note and the guidance refresh are for.

The current stack.

Assistants first: the whole team is on Claude Team, with Gemini inside Workspace, enterprise Fathom for meeting notes, admin ChatGPT and Perplexity accounts for the rest, and Town appearing as an email assistant on the fellows side. Drive, Calendar, Slack and Box are all approved as connectors. Fathom and Salesforce are deliberately held back, for reasons worth keeping on the record: Fathom because the team doesn't want meeting transcripts treated as source of truth and may change transcription vendor anyway, and Salesforce because it is the source of truth for funding and the instinct is to wait, even for read access. Alex set up the Claude design system with Mulago branding back in July, which is why the dashboards shown on Aug 11 came out on-brand.

One known limitation shaping behaviour: shared Claude Projects can't link Google Drive, so people copy files to their desktops to work, which is a driver of the siloing. We now have a candidate explanation. The team's Drive is not a shared drive: it is a folder owned by the Mulago admin account and shared out to everyone. Stephanie raised this herself as a possible cause. That is testable, and worth testing before the migration locks in a structure. The guidance already bars proprietary data from anything outside these tools.

One question from Wednesday, now answered. Ask Mulago, the org-wide search surface, is switched on but not yet set up, and Stephanie has been fielding requests from the team to configure it. The thing she wanted to know was what she would be approving on everyone's behalf. It is permission-aware. Enabling a source at the admin level makes it available, whereas each person still connects their own account, and results come back scoped to what that person can already see. Nobody inherits access to a colleague's mail, files or DMs by searching for them. Worth turning on.

Underneath the assistants sit the systems that hold Mulago's actual knowledge. The table below is the state of play for connecting AI tools to each one properly, through a live connection.

Two honest flags on this table. "Yes" means the vendor maintains an official connection, which matters because anything built in-house requires in-house maintenance. And reading is where nearly all the early value sits, so read-only is the sensible default for most of these, with sourcing now the deliberate exception.

The shared workshop already exists. Twice.

The architecture note has carried a "shared workshop" column marked as still to be stood up. After Aug 12 that is no longer accurate, and the correction is the most useful thing to come out of the three conversations.

Claire's sourcing interface is live and in use right now. She built it in Claude, moved it onto a hosted micro-site, and it reads and writes straight back to Airtable through Airtable's own API. Five people are using it through the current cycle. It shows a reviewer only the fields from this year's application, which is a real fix for a real problem: the sourcing base carries years of retired fields that can't be deleted without losing the history behind them. She also built a meeting view that pushes one filter to everyone at once, which is the one thing it does that a Claude artifact can't.

Worth being precise about what is AI here, because it isn't obvious. Claude wrote the code. What is running now is an ordinary web page talking to Airtable, with no model in it anywhere and no cost per use. That holds for almost everything shown on Aug 11: the dashboards used AI to get built and will use it again to get changed, whereas none of them runs any AI. Spotlight is the exception, and the only one of these that calls a model while it works. The three-way split, and what each type actually needs from us, is drawn out on the data architecture page.

The practical consequence: what these builds need is ordinary web infrastructure. Somewhere to live, somewhere safe to keep their credentials, a way to know who is using them, and someone able to pick one up if the person who made it moves on. That is a much more modest ask than "AI infrastructure", and it is the thing that's actually missing.

One of those four deserves saying out loud. When a page like this talks to Airtable, it needs an access token, and if that token sits in the page's own code then anyone who can open the page can read it out of the source and use it directly from anywhere. The token typically carries read and write across the whole base, so at that point the login on the front is decorative. This is not a criticism of anyone's build. It is the default outcome of the fastest way to make one of these work, and it is a contained fix. The right pattern is that the token lives on the server side and the browser never sees it. Worth checking on every build we already have, which is a job of minutes each, and worth settling as a standard before there are forty of these instead of four.

Avery is separately building on Cloudflare. Two people, independently, arrived at the same missing piece within weeks. Neither was asked to. That is the strongest evidence I have that the shared layer is worth building, and it comes from what the team already did rather than from a principle.

Claire built hers outside the Claude account partly because two people on the sourcing team weren't on it at the time. They are now. So part of the question is simply whether this belongs back inside, and part of it is the wider one: where should things like this live so that a colleague can find, run and improve them. We'll work through the access and hosting side together, and it's the first concrete design question the workshop has to answer.

Two constraints worth planning around.

Salesforce, until end of September. Rahila is running a full audit: structure, relationships, duplicates, gaps and automation opportunities. Her position is that you shouldn't build on a foundation you haven't checked, and I agree. Anything structural on the Salesforce side should ideally wait for that to land. Worth knowing too that there is currently no sandbox, so any test today runs against production. One will be created for the Flow migration.

Box to Drive, now with the assumption checked. Claire built an agent that reads the portfolio document submissions each morning and works out what belongs where. It reads fine, whereas it cannot file anything, because the Box connector has no permission to move files. I have since tested the same thing in a Google shared drive and it works. So the migration unblocks Claire's agent, and that is a concrete win to point at rather than a hope.

A living page.

This page updates as the picture changes: after the show-and-tell, after the deeper 1:1s, and after the architecture note lands. If anything here reads wrong or stale, shout: aggarwal.shabnam@gmail.com