The AI-Native Org Chart
Decide what stays human before you automate anything.
The AI-native org chart separates judgment, relationships and exceptions from repeatable workflows. The result is a build-ready operating model with named accountability, written controls and unit economics: the artifact your CFO can model and a buyer can diligence.
- The illustrative model: a 30-person back-office function becomes 6 senior humans and 14 governed AI roles. It is a recognisable shape, not a promise about your function.
- Humans keep judgment, exceptions, relationships and escalations. Each of those has a reason, and the reason is on this page next to the category.
- A workflow becomes a governed AI role only if it has a defined boundary, benefits from durable context, has enough volume to justify the build, and can be audited.
- Seven production requirements gate every role: scope, owner, approval path, audit trail, cost ceiling, context architecture, and rollback with incident ownership.
- Five worked examples across RCM, finance, customer operations, compliance and pharmacovigilance. Each one states its assumptions, because the assumptions are what decide whether it transfers.
30 People to 6 Humans Plus 14 Governed AI Roles
A composite of redesigns we have run, not a case study and not a projection for your function. It is on the page because it is the shape people recognise, and recognising the shape is the fastest way into the argument.
Read this as illustrative. The role counts are a composite. Comparable throughput at lower headcount is the design target, and whether a specific redesign reaches it is measured against that function's own baseline during the engagement, not assumed here. Where a claim on this site is measured rather than modelled, it says so and names the basis.
| Before | After (illustrative) | |
|---|---|---|
| Senior leadership | 1 director | 1 director |
| Middle management | 2 managers, 5 team leads | 1 senior manager |
| Individual contributors | 22, mixed routine processing and exception handling | 4 senior ICs, exceptions and judgment only |
| Governed AI roles | None | 14, each scoped to one documented workflow |
| Where operating knowledge sits | In individuals, and it leaves when they do | In documented workflows and a defined memory store inside your entity |
| Cost shape | Headcount-linear. More volume means more people | Higher cost per human, lower total headcount, compute cost that scales with volume |
Four Categories, and Why Each One Stays
The categories are easy to list. The reason is what makes the design defensible when someone asks why you did not automate further.
Judgment
Decisions that need context the system does not hold, or where the cost of being wrong is high relative to the cost of a human reading it.
Why: Stays human because the input is incomplete by nature. A role that guesses well is worse than one that escalates.
Exceptions
The cases that do not fit the pattern. The AI role surfaces them with its working; the human resolves them.
Why: Stays human because the resolution is the new pattern. Handing exceptions to the system that could not handle them is how quiet errors compound.
Relationships
Provider, payer, auditor and internal stakeholder relationships. Senior hiring conversations. Anything where the work is the relationship.
Why: Stays human because the counterparty is choosing whether to trust a person. There is no version of this that a workflow owns.
Escalations
When an AI role flags uncertainty above its threshold, or a stakeholder requires a person in the loop, the work routes to a named human.
Why: Stays human because accountability cannot be delegated to software. Someone signs, and that is the point of the design.
Four Conditions, and Why Each One Matters
Work that meets all four is a candidate. Work that meets three stays human, and we say so rather than forcing the fit.
Defined workflow
Documented start, documented end, and a success test that can be evaluated without subjective interpretation.
Why: Moves because the boundary can be written down. If two people describe the workflow differently, it is not ready.
Durable context helps
The work gets better with accumulated context across many instances rather than being independent each time.
Why: Moves because memory is the advantage. Work that needs no history is usually better served by ordinary automation.
Enough volume
It happens often enough that the build cost and the compute cost are justified against the time it returns.
Why: Moves because the economics only work at frequency. Compute cost runs per task, so a monthly task rarely qualifies.
Auditability
The output can be logged, reviewed and audited, and for regulated workflows the trail survives the engagement.
Why: Moves only if the evidence exists. In a regulated function this is the gate, not a nice-to-have.
Seven Documented Elements per Governed AI Role
Without all seven it is a pilot, not a role on the org chart. The list is not optional and it is the same list we hold our own workflows to.
Scope
Exactly which workflow the role runs, what it does, what it does not do, and where the boundary sits. Written before anything is built.
Owner
A named human inside your company who owns the output. Not the vendor, not a committee, not a distribution list.
Approval path
For high-stakes workflows, every output gets human review before it leaves the function. For lower-stakes, sampling review at a defined and written rate.
Audit trail
Every input, model call, output and human-review decision logged where the audit team can query it directly, without asking us for an export.
Cost ceiling
A monthly compute budget per workflow with an alert threshold and a hard stop. A surprise compute bill is an unforced error and we have paid one.
Context architecture
Defined storage, defined retrieval logic, defined update rules, and a documented answer to what the role is allowed to remember. Not chat history.
Rollback and incident ownership
A tested path back to the previous process, a named person who can trigger it without escalation, and a written answer to who runs the incident when the role is wrong at scale.
With all seven in place, the role is a real line on the org chart. With six, it is a pilot that will not survive a regulator visit, a CFO question or a change of sponsor, and the seventh is usually rollback.
Five Functions, With Their Assumptions Stated
Each example is a composite of redesigns in that function. The assumptions block is the part that matters: it names the conditions the example depends on, so you can tell whether it transfers to your operation or not.
Revenue Cycle Management
Before
1 director, 2 managers, 5 team leads, 22 processors across eligibility, coding, billing, denials and reconciliation.
After (illustrative)
1 director, 1 senior manager, 4 senior ICs (denials, coding, payer relations, escalations) and 14 governed AI roles: claim eligibility, coding first pass, billing submission, denial triage, reconciliation, payer-portal navigation, audit-trail compilation, plus 7 routines specific to the highest-volume payers.
Humans keep
Ambiguous coding, high-dollar denials, payer-specific edge cases, regulatory interpretation, provider relationships.
Assumptions behind this example
Assumes claim volume above roughly 40,000 per month, denial reason codes available as structured data rather than only scanned letters, payer-portal access under a service identity your IT team issues, and coding output reviewed before submission for the first two quarters. Change any of those and the role count changes.
Finance Operations
Before
1 controller, 1 assistant controller, 3 managers (AP, AR, GL), 12 staff accountants and clerks.
After (illustrative)
1 controller, 1 senior accounting manager, 4 senior ICs (AP exceptions, AR exceptions, complex GL, intercompany) and 14 governed AI roles: invoice processing, three-way match, payment scheduling, AR aging, lockbox reconciliation, expense reports, GL coding proposals, accruals, intercompany prep, fixed-asset roll-forward, prepaid amortization, bank reconciliation prep, plus 2 routines for the specific GL system.
Humans keep
The close itself, external reporting, cash management, complex judgment calls, audit response.
Assumptions behind this example
Assumes a single primary ERP rather than three post-acquisition instances, purchase-order coverage above roughly 70 percent of AP volume, API write access to the GL scoped to specific document types, and no proposed journal entry posting without human approval. Multi-ERP environments need the integration work before the role work.
Customer Operations
Before
1 director, 3 team leads (tier 1, tier 2, escalations), 22 CSRs across two shifts.
After (illustrative)
1 director, 1 ops manager, 4 senior agents (escalations, retention, complex resolution, customer success) and 14 governed AI roles: tier 1 chat, password resets, account changes, billing inquiries, order status, returns, FAQ resolution, sentiment-flagged routing, post-contact summaries, ticket categorization, knowledge-base updates, post-resolution surveys, plus 2 routines for specific product lines.
Humans keep
Any contact that moves retention or revenue, complex case resolution, customer success conversations.
Assumptions behind this example
Assumes contact volume with a long routine tail, a knowledge base current enough to answer from, written escalation rules including a hard rule that anything touching cancellation reaches a person, and voice handled by humans in the first phase. A thin or stale knowledge base is the usual blocker here.
Compliance Operations
Before
1 compliance officer, 1 manager, 3 analysts, 8 reviewers.
After (illustrative)
1 compliance officer, 1 senior compliance manager, 2 senior analysts (regulatory interpretation, audit response) and 6 governed AI roles: policy-deviation detection, document classification, audit-trail compilation, regulatory-update monitoring, internal-policy adherence checks, plus 1 routine for the specific regulator.
Humans keep
Every determination and every regulatory interpretation. AI roles flag and assemble; they do not decide, and every output gates through documented human review before it leaves the function.
Assumptions behind this example
Assumes current written policy to test against, which is the most common thing missing. Deliberately lighter on AI roles than the other four functions because the regulatory stakes raise the review burden, and a review burden that exceeds the time saved is not a saving.
Pharmacovigilance
Before
1 PV head, 2 case managers, 10 PV officers, 4 medical reviewers.
After (illustrative)
1 PV head, 1 senior case manager, 4 senior PV officers (signal interpretation, regulatory submissions, compound-specific judgment, escalations) and 12 governed AI roles: case intake, MedDRA pre-coding, signal flagging, narrative drafting, query generation, discrepancy detection, coding QC, regulatory-intelligence flagging, plus 4 routines per therapeutic area.
Humans keep
Every clinical and regulatory judgment, every submission, every signal interpretation. Without exception.
Assumptions behind this example
Assumes case volume that justifies per-therapeutic-area routines, a validated safety database the roles read from rather than replace, qualified-person review on all coding and narrative output, and change control that treats each role as a validated system. Validation effort, not build effort, sets the timeline in this function.
The long-form version of the first example, including why retrofitting AI into the existing shape does not work, is in the 30 to 6 + 14 article.
The Artifacts, and What a Buyer Will Ask About Them
Three to five weeks, paid, and the deliverable stands on its own whether you continue with us or hand it to someone else.
Deliverables
Workflow teardown for the function, documented at a level someone outside the team could follow
Every workflow scored against the four conditions, with the reason it passed or failed
The org chart, before and after, with named accountability on every line
A specification per governed AI role: scope, owner, approval path, audit trail, context architecture, cost ceiling and rollback
Unit economics: compute cost range per role, fully loaded cost per remaining human, combined operating run rate
A sequenced implementation plan calibrated to your operating or transaction timeline
What a buyer can diligence
These are the questions a diligence team asks about an operating claim. A redesign worth the fee produces a documented yes to each one, and the deliverables above are organised around answering them.
- Is the workflow documented well enough that someone outside the team could follow it?
- Is there a named owner for every governed AI role, inside the company?
- Can the control evidence be produced on request, without a project to assemble it?
- Does the operating model transfer with the company, or does it depend on a contract with a third party?
- Are the unit economics modelled from observed volumes, or asserted?
- Is there a tested rollback for each automated workflow?
A worked sample of the deliverable
A redacted org-chart redesign with dummy data: the workflow teardown, the scoring, the before and after chart, one full role specification and the unit-economics sheet. Enough to judge the format before you commission one.
Request the sampleSent as a redacted worked example with dummy data, usually the same day. We ask who it is for so the example matches your function rather than a generic one.
One Function, or the Whole Operation
If you already know which function to redesign, the standalone design engagement is the shorter path. If you are deciding across an operation, or a transaction sets the timeline, the Blueprint scopes the org chart, the governed AI roles, the offshore plan and the economics together.