Skip to main content

Design AI Workflows Around the Handoff, Not the Response

Updated 7 min readMarkdown

An AI model generates a response. The application displays it, and everything appears to work.

But what happens next?

Does the response need to update a database, create a CRM activity, prepare an invoice entry, trigger an approval, or simply provide information to an employee?

This is where building AI-powered applications becomes more involved than connecting an AI model to a chat interface.

A model response is often only one part of a larger process. The application still needs to check the information, apply relevant business rules, and determine what should happen next.

For developers working on AI-powered business applications, the important engineering challenge is designing this handoff.

1. Treat AI Output as a Suggestion, Not an Approved Action

Consider an ERP assistant that helps employees understand customer order information. An employee asks about an order, and the AI assistant returns its status along with a suggested next step.

The response may be useful, but it should not automatically become an authorised change to the order record.

The application needs to distinguish between generating information and performing an operation.

A sensible workflow involves receiving the request, retrieving relevant information, generating a response, checking that response, and determining whether any further action is authorised.

For example, an assistant might suggest creating a customer follow-up activity. If the application allows the AI assistant to request actions through APIs or application functions, those requests should pass through the same validation, permission, and business-rule checks as other application operations.

The application should check the relevant customer and order records, verify the user's permissions, and follow any required approval process before creating the activity.

This separation helps keep important business operations under the control of the application rather than relying entirely on a model-generated response.

2. Give AI Relevant and Permission-Aware Context

An AI application often needs more information than the user includes in a question.

For example, if an employee asks about a company's leave policy, the assistant may need to retrieve the relevant internal policy document before preparing an answer.

One approach is called retrieval-augmented generation (RAG). It allows an application to find relevant information from documents or other connected sources and provide that information to an AI model as context for its response.

However, retrieving information does not guarantee that the answer will be accurate. The source material may be incomplete, outdated, or unrelated to part of the question.

Access permissions also matter. Imagine an employee asking an ERP assistant about a customer's order history. The assistant should only retrieve records that the employee is authorised to access.

Developers should consider:

  • Whether retrieved information is relevant to the question.
  • Whether source documents and records are up to date.
  • Whether user and record permissions are respected.
  • Whether confidential information is handled appropriately.
  • Whether responses can be checked against their supporting sources.

Permissions should be enforced by the application's authorisation and retrieval controls before restricted information enters the model's context. Instructions in an AI prompt are not a replacement for application-level access controls.

This is particularly important when multiple employees have different access rights within the same business system.

3. Check the Response Before Using It in the Application

A natural-language response may be suitable for a conversation, but business applications often need information in a predictable format.

For example, an application preparing a sales follow-up activity may need the customer reference, related order, proposed action, and follow-up date.

Developers can use structured output to ask an AI model to return information in an expected format. This makes it easier for the application to process the response.

However, receiving information in the correct format does not mean the information itself is correct.

The application should check that required fields are present, values are in the expected format, and referenced records actually exist. It should also apply the relevant business rules before using the information.

For example, a customer reference may be correctly formatted but still refer to a record the user cannot access.

This is why format validation, data validation, and permission checks should be treated as separate responsibilities.

4. Keep Business Rules and Approval Decisions in the Application

Not every AI-assisted task requires human approval. Summarising a document is different from changing a financial record or confirming a customer commitment.

Developers should decide which operations can happen automatically and which require confirmation.

An AI assistant might summarise an order for an employee without needing additional approval. Preparing a customer follow-up could create a draft for review. A proposed financial or inventory change may need an authorised employee to approve it before the application proceeds.

Approval should be tied to the specific operation being requested, including the relevant record and proposed changes. If those details change, the application may need to request approval again.

These decisions should be enforced through the application's existing permissions, business rules, and approval processes.

The AI model can help interpret information or suggest an action, but it should not independently decide whether a user is authorised to perform that action.

5. Make AI Workflows Easier to Investigate

When an AI-assisted operation produces an unexpected result, developers need to understand where the problem occurred.

Was the wrong information retrieved? Did the model misunderstand the context? Did the response fail validation? Was the user missing permission? Did the application operation fail?

Monitoring only whether the AI API returned a response may not answer these questions.

A useful approach is to examine each stage separately:

  • Retrieval: Was the relevant information found?
  • Generation: Did the model produce a usable response?
  • Validation: Did the response meet the application's requirements?
  • Authorisation: Was the requested operation permitted?
  • Execution: Did the application complete the operation successfully?

Where appropriate, maintain request identifiers, validation outcomes, application errors, and execution status. Model and prompt version information can also help when investigating changes in behaviour.

Where a result influences a business transaction, retain relevant source references and approval records so that the decision can be reviewed later.

Diagnostic information should be protected through suitable access controls, data minimisation, and retention policies. Sensitive prompts and business records should not be collected unnecessarily.

This makes it easier to distinguish an AI response problem from a retrieval, permission, or application-integration problem.

Connecting AI With Existing Business Applications

These considerations become particularly important when AI moves beyond standalone chat interfaces and starts working with existing business systems.

For example, an ERP-integrated knowledge assistant can help employees retrieve relevant process documentation, onboarding material, or organisational information within their existing ERP environment.

This is knowledge retrieval, not automatically a transactional capability. Retrieving an explanation of an inventory process, for instance, does not mean the assistant can or should change inventory records.

The usefulness of a knowledge assistant depends on the quality of its knowledge sources, access permissions, retrieval behaviour, and how employees use the responses.

This is one reason AI implementation should consider the complete business workflow rather than focusing only on model selection or API integration.

For a broader business perspective on selecting use cases, preparing employees, establishing usage policies, and introducing generative AI across departments, see BizzAppDev's guide to rolling out generative AI tools across teams at work.

BizzAppDev works across AI adoption, custom AI applications, and business-system integrations, with experience in Odoo ERP. Its engineering focus includes connecting AI capabilities with the applications and workflows businesses already use.

Final Thought

Building an AI-powered feature is not just about getting a model to return an expected response.

Developers also need to consider what information the model receives, how its output is checked, who can approve an action, and how the application handles the result.

The model generates the response. The application is responsible for deciding what happens next.

About the author

  • Passionate about crafting meaningful content that bridges the gap between business needs and tech solutions. At BizzAppDev, Saurabh specializes in communicating the power of Odoo through storytelling, strategy, and clear messaging. When he's not writing or optimizing content, he's diving deep into the latest Odoo features and ERP trends.

No comments yet. Be the first to comment.