1. Working in a PoC does not mean it is ready to operate
The first thing to validate was clear.
Can an agent carry out, in place of a person, a sequence of work that was handled repetitively?
In the PoC we turned the procedure into a scenario, connected the data and actions it needed, and checked whether the agent could carry out the real task.
Once you have seen it work, though, the concerns change.
Whether it stays stable as volume grows, whether several users can run it at once, whether the processing time is usable in practice.
That is why the purpose of a PoC and of a production system have to be kept apart.
A PoC confirms feasibility. The build secures stability and operability.
So rather than trying to complete every operational requirement at the PoC stage, it is more practical to confirm real applicability first, then work out the infrastructure and architecture from the expected users, volume, and execution frequency.
2. In retail operations, the 'connection' can be harder than the agent
Work at a food and retail company rarely ends inside a single system.
Product, order, partner, and settlement systems are connected to one another, and external systems are often in the mix.
For an AI agent to carry out real work, it has to pull the data it needs from that environment and write results back into the business systems.
How it connects differs by system too.
An API may fit; using the existing web screen may be the realistic route. Depending on the task, a batch or event-driven approach may be needed.
So adopting agents in an enterprise means examining not only model performance but how it will connect to the existing working environment from the earliest stage.
The realistic task is not replacing every existing system and then adopting AI, but keeping the systems currently in use as far as possible and letting AI work in between them.
3. Does a developer have to build every agent?
The question arises naturally once you think past the PoC to real adoption.
A food and retail company has separate organisations for product, marketing, sales, purchasing, logistics, and corporate support.
If the development organisation has to build each agent as those teams need them, the pace of adoption runs into a limit.
Meanwhile, the people who best understand the actual rules and the exceptions are the business teams.
So the roles can be split: trained business owners compose the relatively simple tasks themselves, and specialists support the areas that need complex logic or system integration.
Business owners — define the work and compose simple agents
Specialist team — support complex logic and system integration
Platform — permissions, validation, deployment, and operations
Dividing roles this way uses the business team's domain expertise while holding the level of control the company requires.
4. Not every task needs the same AI model
Even inside one retail company, the work AI performs varies.
Understanding documents, analysing data, retrieving information, and tasks that call for judgement and reasoning all differ in difficulty.
So rather than applying one model to every agent, you need a structure that lets you choose an appropriate model for the task.
In an enterprise setting in particular, performance alone cannot decide the model.
Performance / cost / security / response time / operating environment
all have to be weighed together.
If the company already uses or is evaluating an AI model internally, whether that can be used becomes another condition.
In the end, the criterion is closer to "which model fits this task" than "which model is best".
5. If you have built the first agent, the second should be faster
In a PoC, what matters is that one agent works well.
At company level, what comes after matters more.
If the business logic, tools, knowledge, and integration built for the first agent can be used by the next one, you do not start from scratch each time you automate a new task.
Commonly used agents can be shared across organisations, with only the parts that differ configured per team.
Then the PoC result remains as a company AI asset rather than a one-off demo.
PoC → agents and tools as assets → reuse → applied to more tasks → adoption across teams
This is also why agents should be managed on a platform.
As the number of agents grows, the ability to share, reuse, deploy, and manage matters as much as the ability to build.
6. For the first task, pick one whose effect you can measure — not the most impressive one
If you are adopting AI agents for the first time, there is no need to pick a large, complex task at the outset.
A task that repeats often, follows a reasonably clear procedure, and produces measurable results may suit the first attempt better.
Starting small lets you confirm not only the technical feasibility but how business teams use it, how it connects to existing systems, what operating procedures are needed, and what training it requires.
From that experience, you can widen to more complex work.
Validate on a small task → apply in the business → confirm the effect → settle the operating model → extend to harder work
Rather than completing a company-wide agent framework from the start, making it work in one real task first reduces trial and error.
Field Report
What this PoC confirmed was not only whether one specific task could be automated.
In an environment like food and retail — many products and partners, several business systems running together — an agent has to meet a number of conditions before it can enter real work.
How it connects to existing systems, how much the business teams compose themselves, which model is used, and how a built agent is reused elsewhere all have to be designed together.
So the question to answer in a first PoC needs to shift slightly too.
Not only "does this agent work?"
but "can this approach extend to the second and third task?"
When the first agent becomes a foundation for changing the next task faster, rather than ending as a single automation, the experience of a PoC accumulates as company AI capability.
