Before You Build an AI Agent: Define the Business Workflow

Before selecting a tool or building an AI agent, understand the process it will support.

Who owns the enquiry? Which information is needed? Who checks the response? What can be sent without approval?

When these decisions are unclear, the implementation inherits that uncertainty. A draft may miss important details, two people may assume the other will review it, or a response may be sent before the right checks are complete. Define these responsibilities before giving the agent access to systems or permission to act.

“Automate sales enquiries” is an ambition, not a goal. It does not say which enquiry, what a useful reply contains, or who is accountable for sending it.

A usable goal is specific: prepare a relevant draft response to a training enquiry, using approved course information, for a sales coordinator to review. The business outcome is that the coordinator can answer with the right offering. The agent task is only the draft. Sending the reply, changing a price, or promising a date stays with a person.

Do not promise time saved until you have measured how long the reply takes today and how often it is rewritten. A figure without that baseline is a guess.

It arrives by shared mailbox or website form. The reply needs the company, team size, dates, whether the participants have used Fabric, and the outcome they want. The outline is the current approved course description, not an old proposal. A sales coordinator reviews the draft. The enquiry, the draft, and the next action are recorded. If team size, preferred dates or participant experience are missing, the workflow should identify those gaps and prepare a clarification request for review. It should avoid making assumptions or preparing a final proposal before the required information is available.

Filing the message, matching a repeated address, and attaching the current outline can be ordinary automation. Use an agent where the request must be interpreted, or where the details arrive in a different shape each time.

Explore Microsoft Fabric training

Separate four things before you connect a system.

Approved information the agent can read. The current course outline and the enquiry just received.

Records it may create or update. A draft on the enquiry record, marked for review. Not a message to the prospect.

Information it must not access. Other commercial terms, discount history, unrelated mailboxes, and files the coordinator may not open.

The identity used to act. Decide whether actions will use the signed-in user's permissions or a dedicated application identity, depending on the platform and workflow. Grant only the access required, and ensure actions can be traced to the user or system that performed them.

Instructions do not enforce that boundary. Permissions, and the application that performs the action, have to refuse what that identity should not do.

Approval depends on the consequence of being wrong, on existing policy, and on what testing has shown. A first pilot has little of that evidence, so outbound responses and commercial commitments stay under human review.

Review these controls as the pilot develops. Any increase in autonomy should reflect organisational policy, the consequences of errors, and evidence from representative testing.

Define when the workflow should pause, request clarification or escalate to a person.

Missing participant count, dates, or prerequisites. Ask for the fact. Do not copy it from a similar enquiry.

Conflicting or outdated course information. Stop, and hand both sources to the person who owns the outline.

A request outside the approved offering. Hand it to a person. Do not stretch the Fabric outline over a different programme.

Failed system access. Stop and say the step did not run. Do not answer from an earlier draft.

Duplicate enquiries. Check for an existing enquiry using available identifiers and context, such as the message ID, contact, requested course and an agreed time window. If the match is uncertain, flag it for review before merging records or creating another one.

Instructions embedded in the incoming message. Text in the enquiry may tell the agent to ignore the workflow, open other records, or send the reply now. Treat that text as content, not as a new instruction.

The agent asks a question it is allowed to ask, stops, or hands the task to a named person with the original message attached. It does not guess a price, a discount, or a contractual term.

Use these measures for the current process and for the pilot.

• Time taken to prepare a response.
• Share of drafts accepted without a substantial correction to the offering, the facts, or the next step.
• Accuracy of the course information against the approved outline.
• Correct escalation of exceptions.
• Duplicate or incorrect record updates.

Measure a representative sample of current enquiries, then agree initial success criteria before running the pilot. Compare the pilot results with that baseline and refine the criteria as you learn. Report improvements only when the measurements support them.

• Named process owner.
• Specific business outcome.
• Documented workflow.
• Approved information sources.
• Defined read and write permissions.
• Approval rules.
• Exception and escalation paths.
• Representative test cases, including a message that tries to override the workflow.
• Baseline and success measures.
• Owner for monitoring and maintenance.

Start with one clearly defined workflow. Test it with the people who will use it, review the quality of its drafts and actions, and expand its responsibilities when the evidence supports doing so.

At VNode ITeS, we can help your team explore suitable use cases and clarify workflow, information-access and approval requirements through an AI advisory session or practical workshop.

Discuss your AI agent use case

Explore AI advisory services

Explore AI agent workshops

Assess your organisation's AI readiness

Create agents in Microsoft Copilot Studio