Incentives to surface hidden AI use beat bans and surveillance, which push builders underground; the working structures are documented (a coordinating hub, a champions network, embedded coaches), and the one thing the evidence does not settle is whether the hub belongs at the centre or in the business units.

Two disclosures before the checklist. First, most of the case evidence here is 2022–2024 low-code and pre-agentic; it is the baseline agents inherit, not evidence about agents. Second, a large share of the widely-cited material (a book, an HBR article, an MIT SMR article and two trade write-ups) traces to the same two authors. That is one evidence base, not five, and repetition of it should not be read as corroboration.

The checklist

1. Run the lifecycle, and pick one naming. The 24-company study frames it as five Es (Evangelize, Enable, Educate, Encourage, Embed), with an “enabling intermediary” role sitting inside Enable. A competing sequence circulates with different verbs. Choose one and stop; the value is the sequence, not the mnemonic.

2. Pick a posture deliberately. The documented ladder runs Ignore, Police, Incent, Support, Collaborative Leadership, Transform. The research’s operative advice is help and guidance rather than policing and mandating, and the same page concedes that some applications and industries still need hard limits, with boundary-setting assigned to the support team early. For a regulated asset manager the second half is the operative one. Do not quote the facilitator half without it; the limits route through risk-tier assignment.

3. Stand up a hub, and accept that its placement is unsettled. The observed typology has three forms: hub in a business unit with IT oversight outside it; hub inside IT with technical oversight kept separate; and hub inside IT with technical sub-teams. The middle one was the modal placement across 24 companies, with migrations toward it. Hub size ran up to 25 members, mostly full-time: that is a ceiling across two dozen firms, not a staffing target, and nothing like it fits a 40-person fund.

Where the evidence genuinely splits: the low-code studies, a legacy AWS framework and MIT SMR all argue for a coordinating centre, while BCG argues the centre becomes a shared-service bottleneck that breeds shadow building and that federated business-unit ownership scales faster. No study in this corpus tests either against the other for agent work, which leaves it an open decision rather than a solved one.

4. Build the champions network, and select on standing. Choose ambassadors for combined technical and business knowledge plus genuine enthusiasm, identified before deployment rather than after. One firm’s CIO describes a two-tier version: ambassadors in every function surface use cases, champions assess and test them. The mechanism that makes a distributed network compound where a central help desk doesn’t is peer trust spillover: a colleague’s trust in AI predicts a teammate’s own, a published finding, and the popular summaries drop its condition. The spillover disappears when employees see those teammates as less trustworthy, so the champion’s credibility carries the whole effect.

5. Assign coaches and run office hours, because rollout without support fails by reversion. In one large firm’s account, roughly 200 people were onboarded every other week and adoption stayed patchy: people tried the tools, hit unexpected behaviour, and went back to their old methods. What fixed it was concrete: a coach assigned to every team for at least two sprints, “bring your code in” office hours, and a live chat community where champions answered fast. That is a consultant-reported client case with no measured baseline; the named failure mode is the valuable part.

6. Build on the manager channel rather than around it. In a US survey of 1,440 managers, two-thirds fielded AI questions at least weekly, 68% had recommended a generative AI tool in the past month, and 86% of those said it resolved the problem. Those are managers rating their own helpfulness, in large firms, so read the direction and not the level. The support model already runs through line managers whether a firm designs for it or not.

7. Cap dedicated expert support per project, and build the knowledge base on the 80/20. One or two experts per project rather than open access, paired with a mentorship buddy system. The reason matters: the documented drain on scarce expert time is duplicate requests, with citizen developers unwittingly raising near-identical questions and building near-identical apps. A Pareto knowledge base over recurring requests is the cheapest capacity a support team can add.

8. Reward disclosure, and admit that incentives are unsolved. Punitive responses to disclosed failures push building underground; that inference is ours, not any source’s. The authors with the most field data on citizen development concede outright that incentivizing citizen builders remains an unsolved organizational problem. Say that internally rather than presenting a recognition scheme as a control.

9. Let the community become first-line support as the program matures. In the more mature case firms, self-sustaining internal communities handled routine questions and the central team took only escalations. Note the direction of causation is unestablished: maturity may produce the community rather than the reverse.

Sizing, and one structural warning

The corpus contains exactly one direct signal that generative-AI support demand exceeds low-code support demand, and it is n=1 and self-reported: a large health system’s enablement function runs around 60 people with a platform, consulting, an education arm including a degree program, and an embedded lawyer for regulatory questions; its own head says it cannot meet generative-AI demand. Against that, a software vendor’s executive describes 2.5 full-time staff supporting roughly a thousand citizen-built apps, with a 24-hour triage asking three questions (does this already exist, is the data highly sensitive, is it too complex to build alone) plus dormancy check-ins. Take the triage questions and the 24-hour clock; that ratio is an unaudited claim by a company that sells citizen-development software, and it is no staffing model for a small fund.

The structural warning: one widely-cited support organization holds design sign-off authority alongside its enablement mandate. For a regulated firm that is a segregation-of-duties problem, and the source leaves it unaddressed. Keep approval authority out of the team whose job is adoption. See promotion gates.

How you’d know it’s working

The registered share of agent activity rises quarter over quarter. Shadow builds surfacing voluntarily is the single best signal that the support model is trusted; see agent inventory.

Builder experience is tracked alongside builder output. The sharpest warning in this material is a paradox: in a matched cohort of 95 professional engineers, 84% reported improved productivity at both measurement points, while the share reporting worse experience in at least one dimension nearly doubled, from 14% to 27%. Flow state declined for 35% and improved for 27%; cognitive load declined for 29%. Feedback loops improved on net, so a support model that only watches the negative dimensions will miss what the tooling genuinely fixed. The proposed mechanism is that evaluating each suggestion and verifying each generation builds interruption into the workflow itself. Self- reported, engineers rather than citizen builders, preprint: the transfer is an argument rather than a finding.

Builders have a say in how the program is designed. The organizational factor that holds up best across specifications in European workplace data is employee organizational influence: being consulted on objectives and able to shape how work is organized. Task-level discretion over order, method and pace correlates on its own but fails to survive joint estimation. The practical translation is our inference and not the paper’s prescription: put builders in program design decisions rather than merely granting them latitude.

What this doesn’t solve

A support model recruits and retains builders. Securing what they build is work for controls and gates.

It also does nothing about the wall citizen builders actually hit. In the low-code era that wall was data integration across sources, the point where the support model had to supply IT. For agents the analogous wall is tool and connector permissions, which is a claim about transposition rather than a finding.

And it cannot resolve the centre-versus-federated question from evidence, because that evidence is missing. The decision comes down to a firm’s own constraints, and for a 40-person fund there is only one option; the question is worth revisiting when someone publishes a comparison.

See also

• Shadow agents — the concern that surfacing incentives answer.
• Citizen developer roles — who the model supports and promotes.
• Training curriculum — the enablement arm of this model.
• Day 3 sequencing — when to stand which structure up.
• Oversight decay — the failure mode of support without accountability.
• Agent inventory and registry — where surfaced builds get recorded.
• Dimension 8: Training & enablement — the hub that places this model against formal training, and the maturity level each structure belongs to.