Most failed AI automation projects do not begin with a bad model.
They begin with the wrong workflow.
A team notices repeated manual work, decides an AI agent should handle it, and starts comparing frameworks. But no one has clearly defined the trigger, required data, decision boundaries, exceptions, or human approval points.
The result is an agent that looks impressive in a demo but becomes unreliable in day-to-day operations.
Before choosing an agent framework, start with a more important question:
Is this process actually suitable for an AI agent?
TL;DR
A good AI-agent workflow usually has:
- A clear trigger
- Accessible context
- A visible process state
- Repeatable actions
- Defined decision boundaries
- Human approval for risky steps
- Known exception paths
- An audit trail
- A measurable outcome
If the workflow follows fixed rules with predictable inputs, traditional automation may be enough. Use an AI agent only when the process genuinely requires context, interpretation, or flexible decision support.
Rule-Based Automation or AI Agent?
Not every automated process needs AI.
Traditional business process automation works well when the workflow is deterministic:
When event X happens, perform action Y.
Examples include:
- Creating a task when a form is submitted
- Sending a standard reminder before a due date
- Moving a record when its status changes
- Copying approved data between systems
- Generating a fixed report on a schedule
These workflows have known inputs and predictable outputs.
An AI agent becomes more useful when the process includes unstructured information or variable context.
For example:
- Reading emails and identifying the required action
- Summarising a client conversation
- Comparing a document against internal rules
- Classifying an exception
- Selecting the next appropriate tool
- Preparing a contextual response
- Recommending an action for human approval
The distinction matters.
Adding an LLM to a fixed workflow can increase cost, latency, and uncertainty without creating meaningful value.
An Eight-Part Framework for Evaluating a Workflow
Before building an AI business process automation system, map these eight components.
1. Trigger
What starts the workflow?
A trigger should be specific enough for the system to detect reliably.
Examples:
- A proposal has received no response for three working days
- A vendor quote is overdue
- A client sends a revision request
- A payment milestone becomes due
- A support request enters a shared inbox
“Help the team follow up better” is not a trigger.
“A proposal remains in ‘sent’ status for three working days without a recorded response” is.
2. Context
What information does the agent need before acting?
This may include:
- CRM records
- Emails
- Proposal documents
- Project status
- Client history
- Pricing rules
- Previous approvals
- Internal policies
The quality of an agent’s output depends heavily on the quality and completeness of this context.
If the required information is scattered across personal inboxes, spreadsheets, and chat messages, the first project may be data connection—not agent development.
3. State
Where is the process currently?
An agent should not treat every record the same way.
A proposal may be:
- Drafting
- Under internal review
- Sent to the client
- Awaiting clarification
- Awaiting client approval
- Being revised
- Won
- Delayed
- Lost
State determines what actions are appropriate.
Without reliable state management, the agent may repeat an action, use outdated information, or contact someone at the wrong stage.
4. Decision
What judgment does the workflow require?
Some decisions are safe to automate. Others should remain recommendations.
An agent might safely determine that:
- A response is overdue
- A message contains a revision request
- A record is missing a next action
- A communication should be routed to a project owner
It should probably not independently decide:
- Whether to offer a discount
- Whether a scope change is included
- Whether a payment dispute is valid
- Whether a delivery date can be promised
- Whether a contract term should be accepted
Separate administrative decisions from commercial, legal, or relationship-sensitive judgment.
5. Action
What can the system actually do?
Possible actions include:
- Create a task
- Update a CRM record
- Prepare a draft
- Request missing information
- Notify the responsible person
- Generate a summary
- Route an exception
- Send an approved message
Start with narrow permissions.
An agent that prepares work for review is often safer and easier to deploy than one that can immediately send messages, modify financial records, or make external commitments.
6. Approval
Where must a human remain in control?
A practical human-in-the-loop model can use three levels.
Always require approval
Use this for actions involving:
- Pricing
- Contracts
- Payments
- Scope commitments
- Sensitive client communication
- Delivery promises
Require approval when confidence is low
Use this when the agent encounters:
- Ambiguous intent
- Conflicting data
- Missing context
- An unfamiliar exception
- A decision outside normal boundaries
Auto-execute and log
Reserve this for low-risk, reversible administrative actions, such as creating an internal reminder or updating a non-sensitive status field.
Human approval should be part of the workflow architecture, not added after something goes wrong.
7. Exception
What happens when the normal path fails?
Real workflows rarely follow a perfect sequence.
A client may ask for revised phasing. A vendor may submit a partial quote. A payment may be disputed. A document may be missing. Two systems may show different statuses.
Define what the agent should do when:
- Information is missing
- The process state is unclear
- A tool is unavailable
- A request falls outside policy
- Confidence falls below an agreed threshold
- A human rejects the recommended action
A reliable agent should know when to stop and escalate.
8. Log
Can every action be reviewed?
For each workflow run, record:
- What triggered it
- What context was used
- What the agent recommended
- Which tools it called
- Whether approval was requested
- Who approved or rejected it
- What action was completed
- Whether an exception occurred
Auditability is important for debugging, governance, and operational trust.
It also helps teams see whether automation is improving the process or merely moving the work around.
Worked Example: Proposal Follow-Up
Consider a commercial interior fit-out firm that sends several proposals each week.
The proposal may be created in a spreadsheet, sent through email, discussed over calls, and tracked informally by a founder or estimator.
A suitable agent workflow could look like this:
Trigger: A proposal has remained in “sent” status for three working days without a response.
Context: The agent retrieves the proposal, CRM notes, latest email thread, decision-makers, expected project start, and previous commitments.
State: The opportunity is awaiting client review.
Decision: The agent determines whether the next step should be a receipt confirmation, clarification request, proposal review invitation, or internal escalation.
Action: It prepares a contextual follow-up and suggests the next CRM status.
Approval: The opportunity owner reviews the draft, particularly anything involving scope, price, phasing, or delivery.
Exception: The client’s latest message indicates that a revised proposal is required. The agent routes the request to the estimator instead of preparing a generic reminder.
Log: The draft, approval decision, sent message, and resulting response are stored against the opportunity.
This solves more than a reminder problem.
It creates a visible proposal-tracking workflow and prevents qualified opportunities from depending on memory. A deeper breakdown of how missed proposal follow-ups create revenue leakage shows why ownership, state, and next actions matter as much as the message itself.
How to Measure Whether the Agent Works
Do not measure success by the number of actions the agent performs.
Measure whether the workflow improves.
Useful metrics include:
- Average processing time
- Number of overdue actions
- Percentage of records with a next step
- Human approval rate
- Agent correction rate
- Exception rate
- Workflow completion rate
- Response or conversion rate
- Time saved per workflow cycle
A high human-review rate is not automatically a failure. During early rollout, it may be exactly what helps the team understand edge cases and improve the workflow safely.
Start Narrow
The best first AI agent is rarely a general assistant with access to every system.
It is usually a narrow agent responsible for one measurable workflow:
- Following up on overdue proposals
- Collecting project updates
- Tracking vendor quotes
- Preparing invoice reminders
- Routing client approval requests
- Compiling handover documents
Start with one trigger, one process, limited permissions, and clear approval gates.
Once that works reliably, expand its tools and responsibilities.
For interior design, fit-out, and design-build teams, this practical framework for mapping the first workflow worth automating covers recurring processes such as proposals, approvals, procurement, project updates, and payment milestones.
The framework may be industry-specific, but the principle applies broadly:
Do not begin with the agent. Begin with a workflow whose trigger, state, boundaries, exceptions, and outcome you can clearly define.
Top comments (0)