AI agents expose weak workflows fast.

A human can look at a messy ticket and infer what probably happened. They read between the lines, remember the customer, know the unofficial approver, and understand that "pending" in this queue usually means nobody has triaged it. That is skill, but it is also compensation for a bad system.

An agent does not get that context unless the workflow gives it context. If the workflow says assigned, the agent may assume someone owns the next action. If the workflow says blocked, the agent may not know whether to escalate, wait, request information, or find a workaround. If the workflow says approved, the agent may not know what was approved or what risk was accepted.

Tool access is not workflow readiness.

Many companies will make this mistake. They will connect agents to ticketing systems, CRMs, support tools, documents, and chat. They will give instructions like "summarize open work," "follow up on stale tickets," "route requests," or "prepare approvals." Then they will discover the agent is operating on labels that humans never trusted in the first place.

AI workflow readiness starts with semantics.

The agent needs to know the objects. Is this a request, task, incident, project, approval, exception, dependency, or handoff? Each object has different allowed actions.

It needs state definitions. What does new, triaged, ready, active, waiting, blocked, review, approved, rejected, done, and reopened mean in this workflow? What state transitions are allowed? Which transitions require human approval?

It needs ownership rules. Who owns next-state movement? Who can reassign? When is transfer accepted? Who can override priority?

It needs action boundaries. Can the agent draft a response, update a field, create a task, request missing information, escalate to a human, approve low-risk items, close stale requests, or only recommend?

It needs source priority. If the ticket says one thing, the CRM says another, and the Slack thread says a third, which source wins? When should the agent stop and ask?

It needs escalation rules. Low confidence, policy exceptions, customer risk, legal risk, financial exposure, security issues, and ambiguous ownership should route to humans. The route should be explicit, not buried in the prompt.

It needs auditability. Every action should explain what state it observed, what rule it applied, what source it used, and what changed.

The point is not to make agents timid. The point is to make them reliable inside bounded workflows.

A good early use case is not "let the agent run the workflow." It is "let the agent find state drift." Ask it to identify tickets marked active with no update in seven days, approvals pending without required evidence, handoffs not accepted, blockers with no named unblocker, stale queue items, done items reopened repeatedly, and work assigned to people with no authority to move it.

That is useful because it improves the human system first.

If an agent cannot tell what state work is in, neither can the company. The agent is not the problem. It is the mirror.

AI workflow readiness is boring in the best way: clean definitions, clear owners, constrained actions, visible exceptions, and logs. Without that, agents become faster participants in the same ambiguous process.

This is part 9 of 10 in Workflow Ontology.