Why standard software does not understand the fresh chain
A standard ERP is built on fixed prices, fixed units, and predictable lead times. In AGF, none of those three exist. A pallet of tomatoes has a daily price, a weight that differs from the order, and a delivery time that depends on the auction or the grower. Package logic works in pieces or boxes. Weight logic works differently: you invoice by kilogram, order by pallet, and receive by weight. Any standard package that does not have this at its core requires customisation. That customisation accumulates, becomes expensive to maintain, and turns every upgrade into a small project. The operation adapts to the system instead of the other way around. That is the root of the problem.
Which processes break down most often?
Conversations with AGF businesses consistently surface the same bottlenecks. Order entry is the first: customers call or email orders that are typed in manually while the stock position is already shifting. The second bottleneck lies in delivery notes and picking lists: these sometimes need to differ per customer, with specific display of weights, order units, and batch codes. A third pain point is the link between purchasing and sales. If a grower delivers less than expected, the salesperson needs to know immediately which orders to reschedule. In most systems, that link is not automatic. A staff member makes calls, adjusts manually, and hopes the invoice still balances later. That is not an exception. That is the daily routine.
What does a custom system solve that a standard package does not?
A system built for the fresh chain has weight and price variation as core logic, not as an add-on. That means an order is automatically recalculated when the actual receipt differs from the order. That picking lists are generated based on the logistical reality of that day, not based on a template set up at some point in the past. That purchasing and sales positions are linked in real time, so shortfalls are visible before they become a customer problem. Bonsai builds such systems as a Bonsai AI Digital Twin: the core system rebuilt from the ground up, with the company's own logic embedded, and with AI handling the groundwork. Not a report after the fact, but a system that runs alongside the operation.
When is an AI layer on top of the existing system the better choice?
Not every AGF business needs to replace its core system. If the basic logic of the package is reasonably sound but data entry and document processing consume too much manual effort, an AI layer on top is a more realistic first step. Bonsai AI Workers can then take over specific tasks: reading order emails and converting them into entries, generating picking lists based on customer specifications, or flagging discrepancies between ordered and received weight. That intervention is smaller, faster, and demands less of the organisation. The choice between the two routes depends on how deep the problem runs. If it lies in the system's logic, a layer on top will not provide a structural fix. If it lies in the manual actions on top of an otherwise functional system, a Worker is often enough.
What is a realistic starting point for an AGF business?
Start by mapping the three processes with the highest number of manual corrections. These are almost always order entry, picking list processing, and the reconciliation between purchasing and sales when deliveries deviate. Once those three processes are documented, it becomes possible to determine whether the root cause lies in the system's logic or in the entry and communication procedures surrounding it. Only then does the choice between custom development and an AI layer have a factual basis. Without that analysis, you are buying a solution to a problem you have not yet precisely defined. That is a common mistake, even among businesses that have known for years that the system is not good enough.