An assistant that explains a purchase order is useful. An assistant that prepares the next action can be more useful still: it might gather missing information, propose a supplier or draft a purchase request. The engineering challenge changes when its output can affect the ERP rather than merely appear in a conversation.
Consider a hypothetical maintenance company whose coordinators frequently reorder spare parts. An assistant could assemble a proposed order from the work request, stock position and approved catalogue. The business still needs to know which details were checked, who may approve the purchase and what happens if the request changes before execution.
Define a bounded task before choosing the agent tools
Describe the task in business terms, including its starting information, desired output and acceptable stopping points. “Prepare a replenishment request for review” is easier to assess than “automate procurement”. It also creates a clear distinction between drafting an action and being authorised to carry it out.
Identify the steps that are already deterministic. Looking up stock, validating a supplier and checking a spending limit may belong in ordinary application services. Use model reasoning where interpretation is useful, such as turning a maintenance description into a candidate list, while keeping established rules in code that the business can test.
Microsoft Agent Framework provides documented concepts for agents, tools and workflows, including human interaction and checkpointing. Evaluate the relevant capabilities against the task, without treating a framework feature as proof that the finished business process is safe or correct. Microsoft Agent Framework documentation.
Expose business operations with narrow contracts
Give the assistant operations that match the workflow. A tool that searches approved parts has a clearer purpose than unrestricted database access. A tool that creates a draft can validate required fields and return an understandable result without granting the ability to issue a final order.
Specify inputs, outputs and failure states. If a part is discontinued or the supplier cannot deliver to the selected location, return that condition explicitly. Avoid making the model infer operational status from an ambiguous message or treating any technically successful tool response as a successful business outcome.
Carry the user's identity and relevant organisation context through each operation. The server should enforce permissions independently of what the conversation says. A supplier email, uploaded document or retrieved note is task data; it should not acquire authority to change the assistant's allowed actions or bypass the application's controls.
Make approval refer to a specific proposal
Present the proposed action in a reviewable form: supplier, items, quantities, location and other material details. Include the information the reviewer needs to assess uncertainty, such as an unresolved substitution. A vague “Continue?” button does not tell the person what responsibility they are accepting.
Bind approval to the version of the proposal that was reviewed. If quantities or the destination change afterwards, decide which changes require another review. The system should not treat approval of one request as continuing permission for materially different actions assembled later in the conversation.
Validate again at execution time. Stock, spending authority and supplier status can change while a draft waits. Explain any resulting refusal or request for renewed approval. This makes the workflow consistent with the ERP's ordinary transaction rules instead of creating an alternative route that happens to originate from an AI interface.
Plan partial completion and uncertain outcomes
Suppose the ERP accepts an order but the response to the assistant is lost. Repeating the operation without a stable request identity could create a second order. Define how execution is tracked and how the application checks the outcome before deciding whether another attempt is appropriate.
Keep proposed, approved, executing, completed and unresolved states distinct. An assistant should be able to say that an outcome is still being checked. Inventing a confident success message is worse than presenting a clear pending state with a reference that support can investigate.
Consider multi-step actions separately. Reserving stock and notifying a supplier may fail at different points. Decide which effects can be reversed, which need an explicit compensating operation and which require a person to resolve the exception. Document those choices in the business workflow rather than relying on the model to improvise recovery.
Evaluate whole tasks using representative cases
Build a small evaluation set from realistic, appropriately protected scenarios. Include missing part numbers, ambiguous descriptions, unusual quantities and requests that the current user cannot approve. Mark the expected behaviour: a correct draft, a clarification question, a refusal to act or a route to human review.
Measure more than whether the assistant produces fluent text. Inspect selected records, permission handling, proposal accuracy and the final application state. Keep track of how much correction the reviewer needs to make. An apparently automated process can consume substantial human effort if every draft requires reconstruction.
Repeat relevant evaluations when the model, tool contract, prompt or catalogue changes. A system can regress without an application-code change if its inputs or behaviour shift. Maintain a route to ordinary manual processing so the business can continue when the assistant is unavailable or its results fall below the agreed standard.
Roll out with accountable ownership
Start with one bounded workflow and a small group who understand the underlying process. Give them a way to report a problematic proposal with enough context to investigate it. Record approved actions and outcomes while limiting unnecessary retention of sensitive conversational content.
Assign ownership of the tool interfaces, evaluation cases and operational support. Business owners should define acceptable outcomes, and developers should make those outcomes observable and enforceable. Neither responsibility disappears because the system uses a model rather than a conventional form.
Worktechlabs can help design AI integrations that connect useful assistance to explicit business authority. Combine this approach with AI in existing applications and reliable integration handling so the first production feature has a clear boundary, a measurable purpose and a dependable route for exceptions.
Official sources and further reading
- Microsoft: Agent Framework documentation — agents, tools, workflows and human interaction.
- Microsoft: Semantic Kernel to Agent Framework migration examples — official migration material for existing integrations.
