Enterprise Agents Need Hidden-Workflow Maps

Take the property portal from the opening. Moving a tenant from “pending” to “active” looks like a single decision. It isn’t — the leasing manager’s click was the last step of four screens, and in one implementation we traced, the backend touched a dozen-plus persistence and integration points: lease terms, deposit ledger, unit availability, billing cycle initiation, access control provisioning, and a few more nobody thinks about until something breaks. None of that surfaced on the button. It didn’t need to, because the human clicking it carried years of institutional memory about what “activate” actually implies.

We ran into the same shape building a clinic queue system: a doctor clicks “Consult Complete,” and that single click routes a prescription to the pharmacy, generates a bill line, and deducts stock from medical inventory. Three side systems, one button, zero visible causality.

An agent that calls update_status(tenant_id, "active") without knowing about the other tables isn’t automating the leasing manager’s job — it’s corrupting the data model, and doing it with the full confidence of something that thinks it just succeeded. The endpoint name tells you nothing about blast radius. Only the transition graph underneath it does.

Why Read-Only Discovery Must Precede Action

Humans navigating these systems accumulate years of tribal knowledge, cryptic error messages, and a colleague down the hall who says “don’t do that on a Friday.” Agents get none of that unless we build it in deliberately. An LLM’s latent sense of “how ERPs typically work” is a statistical average pulled from public documentation — it is not a description of your instance’s custom workflow rules, which some systems integrator configured five years ago and never fully wrote down.

This is exactly why tool-call wrappers built for stateless APIs fall apart here. They treat every endpoint as an independent function — call it, get a response, move on. But in an ERP, endpoints are edges in a directed graph with strict preconditions. Call one out of sequence and it rarely errors cleanly. More often it succeeds, quietly, and leaves the record in an inconsistent state that surfaces as a bug three weeks later, long after anyone remembers which agent ran which call. Read-only discovery has to come first, every time: query current state, enumerate the valid next transitions, and only then even consider a write.

The Machine-Readable Workflow Graph

Our fix is to stop asking the system prompt to say “be careful” and instead build an explicit, versioned state transition matrix — enforced by middleware sitting between the agent and the legacy API, not buried inside the agent’s own reasoning.

transition_name: PENDING_TO_ACTIVE
preconditions:
  contract_signed: true
  deposit_paid: true
postconditions:
  status: "ACTIVE"
side_effect_triggers:
  - update_billing_ledger
  - grant_door_access

Before the agent’s HTTP request ever reaches the backend, the interceptor checks the current record state against this matrix. If deposit_paid is false, the request gets hard-rejected locally, and what comes back to the agent’s context is a schema error — not a vague nudge to retry. The legacy system never even sees an invalid call. It’s the same discipline as input validation at any system boundary: don’t trust the caller, even when the caller is your own agent.

The Agent Onboarding Artifact

This map isn’t a paragraph buried somewhere in a system prompt. It’s a file — erp_tenant_state_machine.yaml — checked into the same repository as the agent code, reviewed in pull requests like any other change to business logic. CI validates the workflow file against the backend’s OpenAPI spec, and contract tests exercise the live activation path before the agent ships to production. The spec check catches declared interface changes; the contract test catches backend drift when someone quietly adds a required field and forgets to update the agent path.

Treat workflow rules as version-controlled code instead of assumptions injected into a context window, and you get an agent that structurally cannot attempt an invalid transition — not one that merely hallucinates less often. The state machine doesn’t get more persuasive with a better prompt. It gets safer with a stricter schema.

Read-Only Is the Prerequisite to Write Access

Here’s the unglamorous part: better agent performance in enterprise systems has a lot less to do with model quality than with whether someone actually bothered to document the tables behind the green button. We keep building better guessers when what these systems need is better maps.

Before an agent gets write access to anything resembling an ERP, it should have already queried, in full, what it’s allowed to touch and what breaks if it doesn’t. Ship the map before you ship the write permission. Everything else is just a system prompt asking the machine to be careful — and that’s not a control. That’s a hope.