You are right, measuring AI maintenance burden without accounting for maintenance that had to be done regardless of AI deployment would not get you anywhere.

Interesting you are have Claude identifying opportunities to simplify/reuse/streamline, this could actually mean the per system maintenance burden will go down the more systems you connect. Pretty much the opposite of what I was thinking. Thank you.

Is the proposal to evaluate country prospects, or does it include also weighing these against further expansion in your existing countries?
With my admittedly very limited understanding of your work, it looks like the factors determining the success for your interventions can be quite local. India alone is huge with a significant variety of local conditions and your existing intervention is addressing a small subset of that diversity.

If this succeeds are you considering making the AI advisor the "allocation layer" for your human advisors? Human advisor attention is scarce so you programme has to be selective. What you currently rely on for this selection is probably mostly what's in the application. If you can augment this by the knowledge accumulated by the AI advisor, it could make the quality of allocating your human advisors' attention a lot better.

This is provided human advisors still retain some advantage over ai going forward.

Talent Commons is potentially very valuable, but  there is an important path-dependence problem to address in the design.

Once assessments from SPAR, MATS or hiring rounds become reusable signals across organizations, a judgement made for one particular selection process will start affecting someone's opportunities throughout the ecosystem. This will be especially consequential in an early-career talent pool, where the signal is noisy and people change quickly. Someone misclassified at 20 could end up being affected by that assessment much longer than they would today, while an initially positive assessment could create the opposite cumulative advantage.

I looked at SPAR's privacy notice and there is already quite serious thought going into transparency, correction and optional sharing. But I think the important question for Talent Commons is whether it can preserve the provenance and decision-specific meaning of assessments rather than gradually turning them into general reputation scores. Getting that right would also be necessary so that the system actually improves talent allocation rather than just making existing judgements more portable and longer lasting.

A lot of operational improvements look solid while the person who introduced them is still there, and then disappear when that person changes role or leaves. Given how much institutional knowledge you found sitting in founders’ heads and inboxes, staff turnover over the next year could be quite a revealing test.

If some of the organisations go through that kind of transition, whether the processes still work without the person who set them up seems like a stronger test of institutionalisation than another readiness score on its own.

Yes this is the hard part. AI can make it much cheaper for a donor to assess an unfamiliar organisation once there is enough evidence to work with, but it cannot manufacture information that is not visible in the first place. And there is probably a second-order problem here: once AI starts doing more of the assessment, organisations that are easier for machines to identify, document and compare may get an advantage simply because they are more legible to the system.

I have been thinking about this as a kind of “machine-legibility privilege.” It is one of the things I am trying to test with zooidfund: whether AI assessment can actually broaden the set of needs donors can consider outside their existing networks, without simply shifting the advantage toward whoever leaves the best digital trail.

The section on scale also made me think about what happens if more of the funding process becomes automated. AI could make it much cheaper to discover and assess large numbers of small organisations, which seems potentially very useful for exactly the kind of distributed funding being discussed here. But it also creates another version of the legibility problem: an automated system will need signals it can actually process, and those signals may favour organisations that can produce standardized evidence, reporting and data over organisations that are harder to describe but locally very effective.

So there may be a tension between making the funding infrastructure scalable and keeping the substantive judgment genuinely local. It seems possible to automate a lot of the boring infrastructure without requiring the organisations themselves to become more standardized, but I don't think that follows automatically.

Coming from a fairly traditional international organization, I think I can understand the asymmetry you describe. A lot of professional competence is difficult to teach because it is learned through repeated exposure to how institutions actually behave. You gradually get a feel for which proposals can survive internal processes, where formal authority differs from practical influence, and which ideas become much harder once they have to work across different departments of an organization, let alone different organizations.

Case discussions or “war stories” can work to surface this. Take for example a concrete AI policy proposal and ask people from different professional backgrounds to work through how they think it would fare inside a real institution. I suspect that would make some of this tacit knowledge much easier to see than trying to write it down as a set of principles.

Hi Roland, what are some of the big-if-true ideas you considered?

This was interesting to read, especially the point about the marginal cost of automating additional tasks falling as the underlying infrastructure gets better. One thing I was wondering about is how the maintenance side is developing as you add more automations.

At 11% you can probably still understand each automation fairly well, but if the aim is to automate a much larger share of program operations, some of the work presumably shifts from doing the task itself to keeping a growing set of automations working as forms, Drive structures, naming conventions, staff roles etc. change. I don't know if you are already measuring this, but something like human minutes per run or per program round, including review, exceptions and repairs, might be useful alongside the percentage of tasks automated. It could help distinguish automations that really reduce operational load from ones that mostly move that load somewhere less visible.