The Missing Role in Your Enterprise AI Strategy: The Citizen Developer

That bottleneck isn't a tooling problem. It's a role problem. Your AI organization is missing a position on the depth chart.

We call that position the Citizen Developer — and it's a first-class role inside actAVA's KORA platform. The term "Agent Supervisor" is also gaining traction for the same concept.

The Hospital Analogy

Think about how a teaching hospital staffs a busy service line. You don't have one role — you have a gradient of roles, each with explicit privileges and explicit guardrails.

What's a Citizen Developer, Exactly?

A citizen developer is a domain expert who can design, build, and test AI agents — without needing a software engineering background or going through an IT broker for every change. They are the resident on the service line.

In actAVA, the citizen developer holds a specific organizational role called dev. It sits between the everyday user (who runs agents that already exist) and the admin (who deploys agents to production and governs the org's AI footprint). Three roles, one ladder, clear handoffs.

Role Matrix — Permissions by Level

The dev vs user distinction is enforced at the platform layer, not just hidden in the UI. It's a gate, not a suggestion.

Why This Role Was Missing — and Why It Matters Now

McKinsey estimates 70–80% of enterprise work can be agentified. MIT reports that 95% of AI pilots fail. Both numbers are true at the same time, and the reconciliation is uncomfortable: most of the opportunity is in workflows that the people building agents have never personally run.

When the only people allowed near agent creation are central IT or a vendor's professional services team, you end up with a small number of high-cost, slow-to-ship agents that solve generic problems generically. Meanwhile, the prior-auth specialist who could spec a ten-step denial-recovery agent in an afternoon has no path to build it.

"Wait — my team can do this? Can we own our own roadmap?"

A C-suite leader at an international hospital system said the same in different words: he wanted his teams to "own as much of the agent development lifecycle as possible" — but with one ask before flipping the switch: make sure everyone builds the same way, in any problem area. He wanted velocity without chaos. That's what the role boundary buys you.

How It Works in actAVA

The citizen developer lifecycle is a literal, enforceable workflow , not a slide in a deck. Here's the path an agent takes from idea to production in actAVA KORA.

1. Build. A citizen developer opens Agent Studio and can start from a blank agent or fork one from the Agent Library — a catalog of pre-built workflows for HR, RCM, prior auth, value-based care, and more. They configure identity, mission, guidelines, knowledge scopes, and tools, then connect to EHR, CRM, scheduling, or claims via the MCP Store. Every change creates a new draft version. Drafts are private to the dev — nothing they do here can affect a single live conversation, call, or workflow elsewhere in the organization.
2. Test. Before the agent goes anywhere near a real user, it goes through evaluation. Citizen developers can run the agent against a benchmark dataset, A/B test prompts and model choices side-by-side, replay de-identified traces, and inspect each tool call. This is where the role boundary earns its keep. Citizen developers are expected to break their own agents. The platform makes it cheap. What they cannot do is push a half-tested agent on patients.
3. Assign for Internal Pilot. Once satisfied, the dev can assign the agent to specific users or groups for internal use — with a limited blast radius, full observability, and still gated from broad production traffic. The resident running cases under direct supervision.
4. Approve & Promote. To take an agent LIVE, an admin must explicitly promote the version. This is a deliberate, named action. The promoted version is locked. Subsequent edits create a new draft, which must go through the same gate. No silent regressions. For workflows needing richer review (i.e., clinical sign-off on an outbound message script, compliance review on a coverage-determination agent), admins can route approval through a configured HITL Approver group. The agent execution pauses until the approver acts.
5. Watch the Tape. After deployment, every run is observable. Citizen developers can see how their agent is performing in production, where it's failing, what it's costing, and what users are saying. They draft the next version. The cycle repeats — and the people pushing the flywheel are the people who actually own the workflow.

A Concrete Example

A revenue-cycle director at a multi-specialty group has been losing sleep over a specific denial pattern from one large payer. She knows the four-step appeal that works because she's done it 200 times. Today, getting that codified into an agent means six weeks of back-and-forth with IT, two discovery sessions, and a v1 that gets two of the four steps wrong. Here's the same week with a citizen developer license:

The Same Week — With a Citizen Developer License

That's the difference between AI as a long-running consulting engagement and AI as something your operators actually operate.

The Compliance Conversation

The first question every healthcare CIO asks is some variant of: "You're letting non-engineers build AI in our environment — how is that safe?"

The honest answer: it's safer than the alternative. The alternative concentrates risk in a small ops team that's chronically backlogged, frequently working from incomplete context, shipping to production on a quarterly cadence. The citizen developer model distributes building, but centralizes promotion. The number of people who can put something live actually goes down, not up.

You're not handing the keys to the patient record to anyone. You're handing the keys to the agent design environment to the people who already understand the workflow — and keeping the keys to the production door right where they were.

Who Should Be a Citizen Developer?

Not everyone. The role is a privilege and a responsibility. The citizen developer profile that succeeds has three traits: