Where Agentic Workflows Should Stop

I have been thinking about the phrase “make it agentic” while working through reporting and compliance workflows. Many of these processes are repetitive, document-heavy, and frustrating to navigate. An agent appears to offer a way through the friction: give it access to the relevant systems, describe the goal, and let it take care of the sequence.

But a workflow can be repetitive without being safe to improvise. I wrote a shorter version of this argument on LinkedIn, and the longer version is this: enterprise workflows should not all become agentic. Permissions, calculations, validations, state transitions, approvals, and audit records are often intentional guarantees. They exist because someone needs to be able to explain what happened, why it was allowed, and which rule was applied.

That gives me a useful division of labor. AI can interpret documents, retrieve context, identify inconsistencies, explain requirements, draft responses, and triage attention. Deterministic software should validate inputs, enforce permissions, apply business rules, record actions, and control state transitions. The model can prepare a decision. It should not redefine the decision or its authority.

Start with the shape of the work

I would consider an AI step when five conditions are present:

1. The work happens frequently enough that repeated attention is expensive.
2. A meaningful part of the effort is cognitive: reading, comparing, interpreting, or explaining.
3. The system can supply useful context without exposing more information than the task needs.
4. The organization can accept some model error because a wrong suggestion is recoverable.
5. A deterministic check can validate the result before it changes durable state.

The last condition is the one I most often see skipped. A language model can produce a convincing explanation of a reporting requirement. That does not mean it has calculated the right amount, checked the right period, or confirmed that the person asking has permission to submit it. Fluency is useful at the interpretation layer. It is not a substitute for a control.

A hypothetical reporting workflow

Consider a fictional monthly compliance report assembled from invoices, a policy document, a ledger export, and a submission portal. The employee still owns the report. They ask a system for help because the source material is spread across several places and the policy contains exceptions.

The AI step could extract the reporting period from each document, map invoice descriptions to policy categories, flag an apparent mismatch, retrieve the relevant policy section, and draft a note explaining the discrepancy. It could say which source it used for each interpretation, reducing search and giving the employee a precise place to start.

The AI step should return a bounded proposal rather than a command to submit. A simplified result might look like this:

{
  "period": "2026-08",
  "category_suggestion": "travel",
  "amount_suggestion": 1840.50,
  "evidence": [
    {"source": "invoice-1842.pdf", "location": "page 1"},
    {"source": "travel-policy.pdf", "location": "section 4.2"}
  ],
  "issues": ["Receipt date differs from ledger posting date"],
  "confidence": 0.78,
  "recommended_action": "request review"
}

The number 0.78 is a model output, not a measured probability that the suggestion is correct. Evidence references are useful only if the system can resolve them to exact source material. The recommended action is a recommendation. None of these fields should directly submit the report.

The deterministic layer then checks the contract. Is the period open? Does the ledger contain the same amount, in the required precision? Does the employee have permission to submit for this entity? Does the unresolved date mismatch require a second reviewer? Has this proposal already been submitted? The controller answers these questions with rules and authoritative system state.

Only after those checks pass can the workflow move from draft to ready_for_review. A separate human action could move it to approved, and a permitted submission could move it to submitted. Each transition records the actor, timestamp, source revision, validation results, and the model proposal that informed the work. The model participates in the record. It does not own the record.

1Interpretation

2Validation and authority

3Recorded action

The contract needs an abstention path

The most important output from the AI step may be “I cannot establish this.” If documents disagree, a source is missing, an instruction is ambiguous, or the requested action exceeds its scope, the system should abstain. Abstention is a valid result with a clear route to a person or separate check.

That route should preserve the uncertainty. A useful review queue says which field is unresolved, which sources conflict, what rule prevented the transition, and what evidence would resolve it. An overconfident action hides the work entirely.

The contract between the two layers can be stated plainly:

• The model may propose interpretations, classifications, explanations, and drafts.
• The model must attach evidence locations and identify uncertainty where possible.
• Deterministic software accepts only a defined schema and rejects missing or stale fields.
• Permissions and business rules come from authoritative systems, never from model text.
• A model recommendation cannot skip a required approval or audit event.
• Conflicting, unverifiable, or out-of-scope results become abstentions.

This contract also limits prompt injection. A document can contain text that looks like an instruction, but the workflow should treat it as source content. The controller decides which operations are available and what data may be written.

Measure the economics, not just the demo

The case for an AI step should be measurable in the workflow itself. I would track time spent locating and comparing source material, useful issues found, review time per item, abstention and correction rates, and the cost of false acceptance and false escalation.

Those measurements should be compared with a clear baseline: the existing process for the same class of work. A faster draft that creates more reconciliation work is not automatically an improvement. A high abstention rate may suit a high-consequence process, while a lower-risk triage queue may tolerate more suggestions. The right boundary depends on error cost and downstream validation strength.

This is why I am wary of broad claims that a workflow is now autonomous. “Autonomous” can hide several different questions: who is allowed to act, which facts were checked, which rules were applied, how exceptions are handled, and whether someone can reconstruct the decision later. Those questions belong in the design before an agent receives write access.

I still see a large role for AI in enterprise work. It can make scattered context legible, compare language across documents, surface a discrepancy earlier, and help a person understand what a requirement asks for. Those are meaningful gains. The boundary is not a rejection of AI. It is a way to give AI a useful job without weakening the guarantees that made the workflow trustworthy in the first place.

When I look at a candidate process now, I ask where interpretation ends and authority begins. Put the model where ambiguity and language create friction. Put deterministic controls where a wrong action changes money, permissions, records, or responsibility. Then give both layers an explicit contract, preserve the evidence, and make stopping part of the design.