The most interesting question about enterprise AI is not simply what a model can answer. It is how that intelligence can be applied to business work with the right capabilities, context, and controls. That was my key takeaway after three days of advanced Infor Velocity Suite training in Singapore, including hands-on exercises building AI agents.
What impressed me was not one individual feature. It was the way the capabilities fit together: a structured approach to agent development, security access, an embedded user experience, and a broader combination of generative AI, robotic process automation, intelligent document processing, and process mining.
From a solution architecture perspective, I came away believing that Infor is taking a compelling approach to enterprise AI. The strength lies not only in the intelligence of the model, but also in the platform that makes that intelligence useful.
How important is it to define specific operations for Infor agents?
My experience exploring AI assistants and enterprise integration has highlighted an important distinction: generating a useful response is not the same as performing a business task appropriately.
For an enterprise agent, we need to answer more specific questions. Which operations should it perform? Which information should it use? How should it approach a task? What should happen when a request is ambiguous or requires approval?
The tool, skill, and agent model we explored during training provided a structured starting point for answering those questions.
Tools define specific operations. Skills bring tools together into broader business capabilities. Agents are associated with the tools, skills, and instructions relevant to their purpose.
That separation is valuable. Rather than giving an agent a broad objective and expecting it to work everything out, we can deliberately configure the capabilities available to it and test how it uses them. It also provides a foundation for reuse. A well-defined capability need not be treated as a one-off component built for a single conversation or use case.
This is not about retraining the underlying language model. It is about equipping, configuring and testing an agent for a defined business responsibility. For me, that is a meaningful shift: from asking what AI might be able to do to designing how it should work.
How important are governance and security when building enterprise agents?
Security was another important part of the experience. The platform’s approach brings access considerations into agent configuration, alongside the capabilities an agent is given. That makes governance part of the design conversation rather than a separate question raised after a demonstration.
The handling of user identity was particularly notable. In the embedded interaction we tested, the platform handled the signed-in user context without requiring us to build a separate authentication mechanism for that interaction. For anyone who has explored connecting an AI assistant to an enterprise application, the architectural significance is clear: there is less identity integration to construct around the business capability.
However, simplifying authentication does not remove the responsibility to design and validate authorization. Understanding who is making a request is different from determining what that person, and the agent acting on their behalf, may do.
The execution identity, downstream permissions, and approval requirements still need to be validated for each use case. The advantage I observed was not that security questions disappear. It was that the platform provides a foundation on which to address them.
What does an embedded experience change?
The user experience also stood out because it was embedded within the Infor platform. I found this richer than treating AI as a separate destination. It creates an opportunity to make assistance part of the environment in which users already perform their work.
That matters when designing the overall solution. A useful agent should not be considered only in terms of the answer it produces. We should also consider how a user encounters it, provides the necessary information, reviews its recommendations, and continues with the task.
Embedding the experience does not automatically guarantee adoption. But it offers a stronger starting point for designing AI around the user’s work, rather than asking the user to organize their work around another tool.
What does this look like in practice?
The wider combination of capabilities is what makes the platform story especially interesting. Alongside agents and generative AI, the training covered automation and document-processing capabilities. Process mining adds a complementary perspective: understanding how an organization’s business processes actually operate.
That suggests a more useful starting point for customer conversations.
Instead of beginning with “Where could we deploy an AI agent?”, we can ask: “Where does this process experience friction, and what is the most appropriate way to improve it?”
Consider an invoice-processing scenario. Delays might arise from manual data entry, missing information, exception investigation or approval hand-offs. Those are different problems and should not automatically receive the same technical solution. Document processing could help extract information from incoming invoices. Defined automation could handle repeatable steps. An agent could assist with investigating exceptions through configured tools. Actions requiring approval would need an appropriate control.
In practice, an implementation could follow these steps:
- Understand the process: Map how the process actually runs today, using process mining where it helps, and identify where the friction sits.
- Match the capability to the problem: Decide which parts suit document processing, which suits defined automation, which needs an agent, and which needs human approval.
- Define the use case: Agree on responsibilities, the controls, and the measures of success before building anything.
- Configure the agent: Define its tools, skills, and instructions, and set its access alongside them.
- Test with realistic scenarios: Include ambiguous requests and cases that require approval, and check how the agent uses the capabilities it has been given.
- Validate security and authorization: Verify that the configured execution identity, downstream permissions and approval requirements operate as intended, including during exception scenarios.
- Measure and refine: For invoice processing, that could mean tracking processing time, manual intervention, exception-resolution time and rework. Other processes will require different measures.
The point is not to make every step agentic. It is to apply the right capability to the right part of the process. Process understanding helps give the technology a purpose.
The essential question is whether the solution improves the work, not simply whether the agent can complete a demonstration. For a solution architect, this is where the opportunity becomes particularly interesting. The conversation moves beyond selecting an AI feature toward understanding the process, defining business capabilities, designing controls, and evaluating results.
What are the key takeaways and next steps?
My conclusion from the training is that Infor is taking a meaningful approach to the practical challenges of enterprise AI. The structured tool, skill and agent model, the handling of signed-in user context, the embedded experience, and the broader automation capabilities together offer a compelling architectural foundation.
For customers, a coherent platform is a foundation, not the final outcome. The next step is to translate it into a clearly defined use case: pick a process where friction is clear, agree on responsibilities and controls, and decide how success will be measured.
If you are looking to implement Infor Velocity Suite, talk to our consultants to define your use cases and map the road ahead.
