Skip to content
All posts

AI Workflow Orchestration: Beyond Agent Tool Calls

A customer-onboarding exception exposes the missing architecture between tool calls and accountable enterprise work.

Enterprise AI3 min read

An Agent With Five APIs Is Still Not a Business Process: conceptual architecture overview

An onboarding case stops halfway through. The customer has supplied identification, but beneficial-ownership information is incomplete. One system holds the customer record, another holds document evidence, compliance policy lives elsewhere, and a human analyst must make a judgment. Connecting an agent to five APIs does not make that work a business process.

A business process has state, deadlines, authorized decision-makers, exception paths, competing updates and an audit history. An agent tool call has inputs and outputs. Confusing the two works in demonstrations and breaks in production.

An Agent With Five APIs Is Still Not a Business Process — conceptual control architecture
Conceptual reference pattern; enterprise policies and integrations determine implementation.

Model the business state first

For a corporate onboarding exception, define states such as awaiting evidence, validating information, policy assessment, analyst review, decision recorded, and completed or rejected. Each transition needs a business precondition, an authorized actor and a durable event or record. The agent can help assemble evidence or recommend routing; the workflow determines what may happen next.

Assume a request to the document service times out after the service actually stores the file. A naïve agent retries and uploads it twice. Or an analyst approves a case while a parallel agent is still using the prior policy version. These are distributed systems problems: idempotency, optimistic concurrency, retries, timeouts and compensating actions. They do not disappear when the coordinator is an LLM.

Separate reasoning, control and execution

A workable design has three responsibilities. The workflow engine maintains the durable state, correlates events and enforces transitions. Agents interpret documents, collect contextual evidence and propose bounded actions. Enterprise services remain systems of record, applying their own authorization and transactional rules. Human approvals are first-class activities, not an informal 'please confirm' embedded in chat.

An orchestration control layer can route requests to specialized agents, manage available tools and present operational visibility. But the control layer should not become an unaccountable superuser spanning business domains. Use service identities, scoped credentials and policy checks appropriate to each action.

Events, exceptions and time

Some actions complete in seconds; regulatory or customer responses take days. Persist correlations between workflow instances, customer cases, agent tasks and domain events. Record when information was observed, which version was used, and whether a subsequent event invalidated it. An analyst's correction should reopen a specific assessment, not silently rewrite the historic record.

Event-driven integration is valuable where business state changes asynchronously, but events need schemas, ownership, replay handling and deduplication. A message that a document arrived is not proof that the document satisfies compliance policy.

What operators need to see

An operations view should answer: which case is blocked, why, which systems were consulted, what the agent proposed, who approved the action, what failed, and what the next safe retry is. Technical traces and business audit trails serve different purposes. A token-level trace alone will not explain why a customer waited nine days.

Track completion time distributions, rework, exception leakage, human override rates, incorrect actions caught before execution, cost per completed case and failure recovery time. Measure finished outcomes, not how many agents ran.

Why this changes the architecture conversation

The right question for a CIO is not 'how many tools can the agent call?' It is 'which business transitions are we prepared to let it influence, and under whose authority?' Archy is intended to coordinate agents, tools, enterprise knowledge and workflows; integrating that capability with existing business systems requires deliberate boundaries, not a new autonomous system of record.

For the related architecture decisions, see Enterprise AI Workflows: State, Approvals and Recovery; Enterprise RAG Security: Permissions and Tenant Isolation.

Further reading

OWASP Excessive Agency; NIST Generative AI Profile.

Explore Archy Platform.

Make your next piece count

Give good ideas a better way to ship.

Start with a brief. Keep the editorial decisions yours.

Part of the Archy AI Platform