The final question is not whether a company should "use agents in the back office." That is too vague to guide action. The better question is which internal workflow is ready to become a governed loop. The answer should come from an audit, not a brainstorm.

Start with the workflow inventory. List recurring finance, procurement, legal, HR, compliance, IT admin, and executive admin requests. Ignore one-off strategic work for now. Look for volume, repetition, fragmented context, clear policies, known systems, expensive delays, and visible pain. The best first candidate is annoying enough to matter and bounded enough to control.

Score each workflow on seven dimensions: request volume, pain, evidence availability, policy clarity, system-of-record clarity, reversibility, and risk. High volume with low policy clarity is dangerous. Clear policy with missing systems may need data cleanup first. High risk with low reversibility should start as draft-only. Low risk with clear evidence may be ready for deeper delegation.

Then name the object. If the team cannot say what object moves through the loop, the workflow is not ready. Vendor request, invoice exception, contract matter, employee case, access review, policy acknowledgment, reimbursement, onboarding task, audit evidence request, or board packet are good examples. "Help with finance" is not.

Map the states. A real loop has more than open and closed: submitted, incomplete, enriched, policy-checked, waiting on requester, waiting on reviewer, approved, rejected, executed, reconciled, sampled, escalated, or archived. The exact states vary by function. The point is to make hidden progress visible.

Identify the source systems. Which system owns the object? Which systems provide context? Which system receives the final update? Where does approval live? Where does evidence live? Where does the audit trail live? If the answer is a spreadsheet nobody owns, fix that before adding autonomy.

Define the allowed actions. The agent may read documents, classify requests, ask for missing fields, summarize context, prepare decisions, draft system updates, route approvals, execute low-risk actions, or close the loop. Each action should have a permission boundary. Tool access is not workflow design.

Set the approval depth. For each action, choose preview, recommendation, pre-approval, post-review, sampling, threshold-based execution, or full delegation. Tie the choice to risk and reversibility. Make the reviewer explicit. Make the escalation path explicit. Make the kill switch explicit.

Design the evidence trail. The loop should preserve source documents, policy references, system data, decision rationale, approvals, tool calls, timestamps, and final state. Do not wait for a future audit to decide what should have been logged. If evidence matters later, capture it during the work.

Choose success metrics before launch. Queue age, incomplete request rate, missing evidence, reviewer load, rejection rate, rework, exception aging, and audit-readiness are better than vanity automation counts. The purpose is not to say an agent handled work. The purpose is to prove the work system improved.

Run the first loop in a conservative mode. Draft-only or recommendation mode is fine. Let operators see the prepared packets. Track what they change. If the agent repeatedly misses the same facts, fix the intake or source map. If humans mostly approve unchanged recommendations, consider deeper delegation for that narrow class.

After two or three cycles, decide whether to widen, deepen, or stop. Widen means adding adjacent workflow types. Deepen means allowing more action authority in the same workflow. Stop means the loop is too ambiguous, risky, political, or data-poor for now. Stopping is not failure. It is control.

The audit also helps leaders avoid scattered pilots. Ten disconnected AI experiments across finance, legal, HR, and procurement will create confusion. One well-designed loop with measurable control quality creates a pattern the company can reuse.

The mature version of agentic back office is a portfolio of loops. Finance has exception loops. Procurement has vendor loops. Legal has matter loops. People ops has case loops. Compliance has evidence loops. Admin has coordination loops. Each loop has its own risk model, but the same operating grammar: object, state, evidence, approval, action, audit trail, metric.

That is the practical endpoint of the series. Start narrow, govern hard, measure honestly, and only increase autonomy where the loop earns it.

The audit should end with one named owner. Agentic back-office loops cut across functions, which makes ownership easy to blur. Finance may own the policy, procurement may own vendor intake, security may own risk review, legal may own contract terms, and IT may own tooling. Someone still needs to own the loop's health.

That owner should review metrics on a cadence, watch exceptions, update rules, and decide when delegation depth changes. Without that operating owner, the pilot becomes a demo that slowly drifts away from reality.

The final artifact should be a short loop spec. It should fit on a page: object, states, source systems, allowed reads, allowed writes, evidence, approval gates, metrics, owner, and kill switch. If the team cannot write that clearly, the workflow is not ready for more autonomy.

This is why agentic back office is a good series to build now. It gives leaders a practical way to talk about AI inside internal operations without falling into hype or fear. The question becomes concrete: which loop, with which controls, earning which delegation?

Evidence note: ServiceNow and Atlassian provide public context for workflow and request-management baselines; NIST's AI RMF supports risk-based governance language using https://www.servicenow.com/workflows/creator-workflows/what-is-workflow-automation.html, https://www.atlassian.com/itsm/service-request-management, and https://www.nist.gov/itl/ai-risk-management-framework.

This is part 10 of 10 in Agentic Back Office.