The agentic enterprise: rebuilding the back office with agents

Part three of a series — the vision paper. Part one, "Shipping a Production Stack with AI Coding Agents", described the five skills. Part two, "From five skills to a hardened system", is the full technical story of how they became a hardened system. This paper is the argument for where it leads: the same primitives rebuild most of the back office, and reshape the org chart with them. The skills are open-source — github.com/amurthygithub/Sharevalue_claude_skills.

The argument

The first two papers were about code. This one isn't — or rather, it's about code only as the test case for something more general.

We built a workflow that lets a tiny team ship a production system: a set of slash-command verbs the human invokes, a multi-agent review on every push, a hard-coded list of irreversible actions the agents will not take without a present-tense human "yes," and a coordination layer that keeps a dozen parallel agents from colliding. Part two is the full technical account. The claim of this paper is that almost none of that is specific to code.

The same primitives — tool starvation, an independent re-scan before any irreversible step, sharded per-case audit, per-resource locks, a triage council over machine-generated findings, a WARN→BLOCK policy ratchet — rebuild not just code review but most of the back-office work that humans currently do in queues. Accounts payable. Refunds. Support triage. Month-end close. Hiring screens. We'll argue the mapping is structural, not aspirational, and we'll be honest in §6 about what doesn't transfer and how expensive the transition is.

Same warning as before: this is not a ten-figure narrative about agents replacing knowledge workers. It's a structural argument about a specific shape of work, and a sober account of what changes for the org chart when that shape gets automated. If you came for the hype, this isn't it.

1. Why code work was the test case

The reason the workflow works for code is that code work has four properties. They're worth naming precisely, because the whole argument turns on which other kinds of work share them.

A workflow like ours pays off exactly where all four hold: bounded work, an irreversible step worth gating, an auditable record, and enough repetition to justify the verb. Where any one is missing, it doesn't fit — and §6 is honest about those cases.

The interesting observation is how many non-code processes have all four.

2. Every back-office process is a skill catalog waiting to happen

Almost every back-office function inside almost every company has the same shape: a queue of similar requests, each needing a few minutes of human judgment plus a write to a system of record.

A few worked examples to make the mapping concrete. In each, the authoring step (drafting, summarizing) is fine to delegate; the irreversible step sits behind an independent gate that does not trust the model.

• Accounts payable. A vendor invoice is a discrete unit; paying it is irreversible; the ERP is the system of record; invoices recur thousands of times a quarter. /process-invoice opens the case, acquires a per-vendor lock (so two AP agents don't both process it), drafts the GL coding, runs a three-lens review (in budget? matches the PO? duplicate or fraud-shaped?), passes an independent threshold gate (amounts over a limit require a human), commits to the ERP, writes an audit shard.
• Customer refunds. Same shape, different record. /refund acquires a per-order lock, drafts from policy + history, runs the three-lens review, passes an independent threshold gate (small amounts auto; large amounts and ToS-violating refunds escalate regardless of amount), commits to the payment processor, writes audit. The most important gate is the threshold one — it does not trust the model's opinion on whether the refund is appropriate.
• Support triage. /triage-ticket fetches the customer's history, drafts a response or a routing decision, runs a three-lens classifier (severity / category / urgency — the same council shape from part two, retargeted), commits the routing, writes audit. Human-required tickets escalate; the rest route.
• Month-end close. A /promote-shaped meta-process: two-step human confirmation, a soak-window advisory (any journal entries in the last 24 hours?), a danger-zone scan (does the change in retained earnings cross materiality?), audit at every step.
• Hiring screens. Mostly about the danger-zone list: the agent must not send a rejection or extend an offer without an explicit human "yes." Drafting the screen summary is fine to delegate; the irreversible step is not.

The pattern is identical in all five because the structural properties are identical. Marketing-asset approvals don't fit — no clean system of record. Strategy decisions don't — not discrete. The closer a process is to "a queue of similar requests, each a few minutes of judgment plus a database write," the better the fit.

3. The seven invariants

Compress everything in the first two papers to the load-bearing rules and you land on seven. Each has a code form (what part two shipped) and a back-office form (what it looks like in AP or refunds or hiring). The code forms are detailed in part two; here we state each at the level the vision needs.

1. Tool starvation. An agent's authority is its tool list, not its prompt. The AP review agent can read the invoice, the PO, the vendor history — it cannot post to the GL, trigger a wire, or email the vendor. Even if the invoice carried a prompt-injection payload, the worst it could do is influence the text of its verdict. An agent you don't trust to write the database is an agent that does not have a database-write tool.

2. Independent re-scan. Any time an agent's verdict triggers an irreversible action, a second gate that doesn't share inputs with the agent must re-check it. Every wire over a limit hits a bank-allowlist check that never sees the agent's reasoning; every large refund hits a fraud check that never sees it. The threshold gate is bypass-resistant by construction.

3. Stop-and-ask. An explicit list of irreversible commitments the agent never performs without a present-tense human "yes": sending a rejection, terminating an employee, signing a contract, cancelling a policy, initiating a chargeback. Past authorization does not carry forward; each instance gets its own "yes."

4. Sharded audit. One append-only shard per case — per refund, per invoice, per hiring case. The audit trail is the set of shards: queryable, never contended. When the question "why did we refund this customer?" arrives three months later, the shard exists and the timeline is recoverable.

5. Per-resource locks. One lock per invoice, per order, per record. Two agents cannot both process the same case; the lock auto-expires when the owning session is gone or after a TTL.

6. Triage council. When the review surfaces exceptions (missing PO, amount mismatch, duplicate), a separate read-only classifier decides per-exception: auto-fix, defer, false-positive, or human-required. It classifies; it does not mutate the case. The cost of one extra classification step is lower than the cost of blindly fixing or blindly ignoring.

7. WARN → BLOCK policy lifecycle. New policy rules — a new threshold, a new approval requirement, a new compliance check — ship in shadow mode first: the rule fires, the audit records what it would have done, the actual decision is unchanged. After a soak, if its catches outnumber its false positives, it's promoted to enforced. Policy is versioned, rolled out, and rolled back like code.

These don't depend on the tool, the model, or the industry. They depend on the structural properties of the work: irreversible steps, delegated authority, accreting policy. Any workflow with those properties benefits from the same seven.

4. AgentOps: the new discipline

Once an organization runs more than two or three agentic workflows in parallel, a coordination function emerges whether you name it or not. By analogy with DevOps and MLOps — though the analogy is loose — we've been calling it AgentOps. It's a small team, not a tool.

Five roles, each with a clear charter:

• Skills librarian — owns the verb catalog. Reviews new skill proposals, refactors common patterns into shared primitives, deprecates verbs that aren't earning their keep. The person you ask "is there already a skill for X?" before writing your own.
• Danger-zone registrar — owns the NEVER list. Adjudicates what's irreversible enough to warrant a stop-and-ask gate versus what can be delegated. The person you talk to when a workflow needs to do something almost on the list.
• Audit pipeline — owns the shard store, the query layer, the alerts. Makes sure "why did we do X two months ago?" has a findable answer. Also where SLI declarations and post-incident reviews land.
• Memory steward — curates the promotion path from session memory → lessons → canonical policy → enforced rule. Reviews stale entries, demotes lessons that turned out wrong, keeps the memory store from sprawling into a graveyard.
• Primitives team — owns the shared coordination infrastructure: the locks, the queues, the hooks, the shared playbooks. Where shared infrastructure lives when two workflows need it.

The team is not large — on a fifty-person org, two or three people, mostly part-time. The leverage isn't headcount; it's that one person looking after the catalog prevents twenty people from each maintaining an incompatible variant. The function exists before you name it; without explicit ownership the roles get dropped under deadline pressure and the workflow degrades. Naming it is what makes it durable.

In our experience AgentOps is much more about humans coordinating policy than humans coordinating agents. The agents are the easy part — they do what their tools and prompts allow. The hard part is keeping the policy coherent as the catalog grows.

5. What companies have to restructure

Take the argument seriously and the implications for org structure are uncomfortable. Five concrete changes, ordered roughly by reversibility.

(a) Process docs become executable. Today most ops processes live in wiki pages written for humans, read by humans, rotted by humans not reading them. In an agentic workflow the process doc is the skill file. When the AP team updates its procedure, it updates the markdown the verb reads on its next run. There's no gap between "the policy" and "what the agent does" — and documentation owners become process owners.

(b) Approvals become bypass-resistant gates, not Slack threads. Today most approvals are "DM your manager," and the bypass is "send another DM." In an agentic workflow the approval is a stop-and-ask gate the agent won't bypass; the human's "yes" is a session-scoped explicit consent, not an inferred "Sarah always approves these." More rigid by design — fewer accidental approvals, more deliberate ones.

(c) Audit replaces oversight. Today managers oversee by reading status reports and attending standups. With per-case shards, oversight becomes a query: "is the team on track" is answered by a count, not a weekly check-in. Some find this liberating; some find it unsettling. The role of "the person who knows what's going on" doesn't disappear — it changes from attending meetings to querying the audit.

(d) Coordination via locks and shards instead of meetings. When two ops teams need to coordinate today, they meet. In an agentic workflow the lock + the shard + the skill-level handoff replace most routine coordination: an agent collides on a case, the lock refuses the second, the override is requested via a shard the other skill picks up on its next pass. This does not eliminate meetings for strategy or hard exceptions — it eliminates the weekly sync where six people read each other their queue.

(e) Memory promotion replaces tribal knowledge. Today most ops teams have one or two long-tenured people who "know how things work," and when they leave the knowledge walks out the door. With the promotion path — session memory → lessons → docs → encoded rules — the knowledge lives in files, rules, and skill steps. New hires onboard by reading the catalog and the audit, not by sitting next to the veteran for three months. Biggest change, longest payoff, and the one most likely to fail: memory only accretes if someone (the steward) is responsible for promoting it.

What doesn't transfer

Three honest caveats:

• Creative and open-ended work doesn't restructure this way. A marketing campaign, a brand direction, a product surface — these lack the discrete-units-plus-irreversible-commit-plus-system-of-record shape. The workflow fits where work is already process-shaped, not where it's intrinsically open-ended.
• The reorganization is expensive. Moving from queue-shaped ops to verb-shaped ops takes 6–12 months of restructuring, retraining, and rebuilding tooling — start with one process (AP or support triage) as a pilot before generalizing. Be skeptical of any "transformation in 90 days" claim.
• The role changes are real. A function that employed twelve people pushing tickets through queues will not employ twelve after the restructure. Some become skill librarians, memory stewards, exception handlers. Others don't. We're not going to write the "how to manage this humanely" section, because we haven't done it ourselves at scale and pretending otherwise would be dishonest.

6. If you're starting today

A five-step adoption ladder for an ops team, mirroring part one's structure, retargeted. None of it requires buying a tool you don't already have.

1. Write the NEVER list first. For your process, list the actions that must require an explicit present-tense human "yes." Be specific: not "approvals" but "any refund over $500, any chargeback, any termination, any contract signing." Fifteen minutes for a first pass; you'll add to it.
2. Pick one verb and one system of record. AP and support triage are the easiest starts — both have the four properties cleanly and an existing system of record. Write one skill that opens the case, acquires the lock, drafts, and stops. Let a human commit manually for two weeks.
3. Add the independent threshold gate. Then, and only then, add the auto-action behind a threshold gate that does not trust the model. Small amounts auto-commit; a middle band gets a second review; large amounts require a human. This is the single most important defense and the cheapest to implement. Do not skip it.
4. Run the triage council on exceptions. Let a three-lens classifier sort the exceptions; humans review the classification, not every raw exception. This is where most of the leverage is — it turns "twenty people manually triaging" into "twenty people reviewing a classified report."
5. Add audit shards + memory promotion. One shard per case, append-only, queryable. Name who owns memory promotion. If the team is large enough, name the AgentOps function explicitly — two part-time roles is enough to start.

What you can skip: the full AgentOps team if you're three people or fewer (the roles collapse into one person); the memory-promotion system if oral tradition still fills the gap (add it when knowledge starts walking out the door); a rule registry until you have at least three rules.

7. Closing

What this paper deliberately does not claim:

• Not that agents make back-office staff redundant. It changes what they do. Some roles shrink, some grow, some appear. The honest framing is structural change, not a headcount cut. Anyone selling "agents replace ops" is overselling.
• Not that the transition is fast. A small team with no legacy ops org moved quickly; a company with hundreds of ops staff and a decade of existing systems will take 6–12 months to pilot one process and years to restructure broadly.
• Not that the principles are novel. Tool starvation is least-privilege; the independent re-scan is defense-in-depth; sharded audits are partitioned logs; per-resource locks are mutual exclusion; the WARN→BLOCK ratchet is a feature flag. The contribution is that they compose into a coherent operating discipline — and that the discipline, proven on code in part two, generalizes.
• Not that this is the only way. Plenty of companies will keep running back-office work in the queue-of-humans shape and do fine. The argument is narrower: companies that do restructure this way will run their back office at a fraction of the cost and a multiple of the accuracy — and the gap will be visible within a few years.

The implementation that makes all of this concrete is part two — the actual skills, gates, and primitives, shipped and hardened on a real production codebase. The open-source template is at github.com/amurthygithub/Sharevalue_claude_skills; the _lib/ playbooks (danger-zone scan, finding council, the rule registry) are written generically enough to retarget — the ticket-tracker references swap for your ERP or ticketing system without changing the structure.

The whole thing is still unglamorous. Mostly bash and markdown. The bet of this paper is that the unglamorous shape — discrete work, an irreversible commit behind an independent gate, a queryable audit, a policy that ratchets in slowly — is the shape most of the back office will be rebuilt in, and that the companies who learn to write the verbs and hold the danger zone will be the ones who run it.