Kenco's Agent K AI Automates 500 Labour Hours a Month at 99.96% Accuracy

Start with what the announcement actually establishes. Kenco Group built an agent layer called Agent K that watches somebody run a process once, absorbs the logic, and then plans, prioritises and performs daily work. The record says it automated 500 labour hours in one month, at 99.96 per cent accuracy, and that one consumer products site projects over $100,000 a year of savings in controllable cost. It covers three customers and five distribution centres. Went live November 2025. The live use case is wave planning: deciding which orders go into which wave, by ship date, by the labour actually available, and by whatever constraints the site carries. There is a Microsoft Teams hook for launching work remotely and receiving alerts. Alongside it at the same awards sat a Takt programme using employee incentives: 68 people, six teams, $1,500 of incentive money producing $6,500 of savings, a return of 337 per cent.

Now model it. Orders arrive. Arrival is bursty, because customers order when their own systems batch, not when it suits you. A release policy decides when a batch of them enters service. Service is picking, packing, staging and loading, performed by a finite set of servers: people, benches, dock doors, and critically the number of people who showed up on that shift. Deadlines come from outside, from the carrier, and missing one is not a small miss. Little's Law tells you the identity you need here: work in process equals throughput multiplied by cycle time. Anything that shortens cycle time without adding servers buys you something, and anything that adds work in process without adding servers costs you something, even though the latter looks like productivity for about two weeks.

So the first question is not whether Agent K works. The first question is where in that queue the bottleneck actually sits, because moving a queue is not the same as emptying one.

Take the 500 hours seriously and ask what can possibly be inside them. Assume 22 working days a month and an eight-hour day. Five hundred hours a month is 22.7 hours a day, which is close to 2.9 full-time-equivalent people's worth of work every single day, in a single building. Now picture what wave planning actually is in most operations: someone opens the order pool, groups orders by carrier cutoff and destination, checks who is on the floor tomorrow, builds maybe four to eight waves, and publishes them. In a messy site that takes an hour. In a clean site it takes twenty minutes with coffee. There is no version of plan-building that consumes 22.7 hours a day.

Which means the 500 hours are not the plan. They are the loop around the plan: watching the day unfold, noticing that wave three is behind, reassigning picker zones, chasing the two orders that are short a component, answering the supervisor who wants to know what to prioritise now that dock four has lost its driver, updating statuses, confirming completion, re-planning for the fact Tuesday's truck is half empty. That is the coordination tax, and it is invisible because nobody has ever had a line item for it. If you ever want to size this opportunity for your own building, do not time how long the wave plan takes to build. Time how many hours a shift your supervisors spend reacting to it.

Here is the piece of this that nobody puts in the press release, and it is the part I would photocopy for anyone about to build a business case. Put the two headline numbers against each other. Six thousand hours a year, if 500 hours a month repeats, and $100,000 a year of savings. Divide and the implied value of a released hour is $16.67. Now put a real number next to it. Assume a fully loaded cost of $35 an hour for a warehouse coordinator or supervisor — salary, burden, the whole thing, and if your site is union or coastal, adjust it upward. Six thousand hours at $35 is $210,000 a year, not $100,000. Run it at $45 loaded and it is $270,000. The projection sits at roughly half of the released hours.

Do the arithmetic in the other direction too, because this is how you build your own budget. At $35 loaded and a 45 per cent conversion assumption, reaching $100,000 a year requires approximately 529 released hours a month. They reported 500. That is consistent to within about six per cent, which is genuinely reassuring: the numbers were not invented, they were produced by someone assuming that roughly half of the released time converts into money and the other half converts into headroom. That single sentence is worth more to you than the accuracy claim, because it tells you the conversion reality. Software that releases a planner's day does not delete a planner's salary. You only get the cash if headcount falls, overtime falls, or temporary labour stops being booked. Everything else is absorbed as capacity, and capacity is worth real money only if you are going to grow into it.

Note also the word the CPG figure carries: controllable cost. That is a defined bucket. It is what the site manager controls — overtime, temporary labour, supplies, some freight — and it deliberately excludes rent, depreciation and corporate allocation. Fine, that is honest scoping. It also means the saving belongs in the operator's P and L, which raises the only question that matters to anyone reading this as an importer or exporter: if your third-party warehouse adopts this, do you see a dollar of it. Under an open-book or cost-plus arrangement, savings generally flow to you on the next true-up. Under a fixed rate per carton or per pallet, your unit price is frozen for the life of the agreement and the operator keeps every cent for two or three years. Same software, same 500 hours, completely different outcome, and it is decided entirely by a clause in a contract somebody signed years ago.

Now the 99.96 per cent, which is my favourite number in this whole announcement because the denominator is doing all the work. Accuracy can be measured per wave, per task, per allocation decision, per order line, or per keystroke. Watch what happens when you pick two plausible units.

Assume the unit is a wave. Assume the site releases twenty waves a day across twenty-two working days, which is 440 waves a month. Zero point zero four per cent of 440 is 0.176 defects a month. That is one mis-waved wave roughly every five and a half months, per site, or about ten or eleven a year across five sites. Very tolerable, assuming someone catches them.

Assume instead the unit is an order line. Assume the same site processes 40,000 order lines a month, which is unremarkable for consumer goods distribution. Zero point zero four per cent of 40,000 is 16 defective lines a month, per site. Across five sites that is 80 defective lines a month, getting on for a thousand a year.

Same accuracy figure, same system, two completely different operating realities. And the cost of an error here is not proportional to how many there are. A mis-allocated line that surfaces in picking costs you a picker's minute. A mis-waved order that surfaces at the dock at four in the afternoon, after the carrier has already left, costs you a recovery shipment, a reschedule, and possibly a customer who now has an opinion about your service level. The cheap errors and the expensive errors both get counted once in the accuracy metric, and both get paid for on the floor by people whose time nobody counted in the 500 hours.

So if you are the one signing the pilot agreement, ask for three things instead of one accuracy percentage. Ask for the unit, stated in writing. Ask for an error log with categories, because the difference between a mis-prioritised order and a missed cutoff is the difference between a nuisance and a freight bill. And ask for a named owner of the recovery cost. Currently, in most warehouse contracts I have seen, that owner is nobody, which means it is you.

The Microsoft Teams hook deserves the same treatment, because it is a governance change dressed up as a feature. Remote launch is genuinely useful; a supervisor at home on a Sunday adjusting tomorrow's priorities beats a supervisor driving in at eleven at night. Alerts arriving in a chat channel are also how good systems quietly stop working. Every exception that generates a toast notification competes with every other toast notification, and the quantified failure mode is boring and predictable: volume climbs, people mute the channel, and the one event that needed a human is ignored along with the ninety that did not. Set a threshold. Decide in advance what earns a push notification, cap channel volume at a number you can actually read in a shift, and measure acknowledgement time rather than delivery.

Why would wave planning specifically be the right place to put an agent, and when would it be the wrong place. Think about what the release policy actually controls. It controls how much work is in the system at any moment and when each order starts service. If your DC's real constraint is pick floor labour in a four-hour peak window, then a smarter plan cannot create pickers; the best it can do is stop putting work in front of them that cannot finish, which is worth something but not worth 22.7 hours a day. If your constraint is packing capacity or dock door count or staging square footage, an improved release policy pushes work into whichever of those is next-tightest, WIP grows, and you will see the evidence as a fuller aisles and a longer tail of orders sitting at ninety-eight per cent complete. Little's Law does not care which of your KPIs improved.

Where the money genuinely lives is variability, not headcount. Cycle time climbs non-linearly as server utilisation approaches one, and it is bursts — three hundred orders landing in fifteen minutes, a wave with wildly uneven labour content, one huge order sitting in front of forty small ones before a cutoff — that consume the overtime hours. A policy that levels waves against labour actually available attacks variance directly, and variance reduction shows up as fewer premium-hours and fewer expedites. My read of where that $100,000 comes from is overtime and recovery freight, not payroll reduction, and every number in the release is consistent with that read.

So let me size it for a mid-sized import DC with every assumption written down, so you can drop in your own. Assume one shift, 22 days a month, and that two supervisors plus one lead each spend six hours a day inside the coordination loop: 18 hours a day, 396 hours a month. Assume only two-thirds of that loop is reachable by software, because a third of it involves physically walking to aisle fourteen, inspecting something, or having a conversation that a machine cannot have for you. That leaves 264 addressable hours a month. At the $35 loaded rate used above, that is $9,240 a month gross, or $110,880 a year, and at the 45 per cent conversion that Kenco's own pair of numbers implies, about $50,000 a year actually cashed out. Getting to $100,000 requires doubling the addressable loop, paying a higher loaded rate, or actually removing someone from the payroll. That is the argument you should be having with a vendor, and it is built from your numbers rather than theirs.

If you want to test it in your own operation, do not ask the vendor for a productivity percentage. Ask for the change in weekly overtime hours and in expedited freight dollars.

The demonstration-based training deserves its own paragraph, because it is the most unusual claim and the one nobody has thought through. Learning a warehouse's logic from one walkthrough is excellent for deployment cost: no integration project, no months of configuration, no consultants billing for discovery. It also means the process definition lives, permanently, inside whichever person performed the demo. Two consequences follow. First, the system learns that person's actual practice, including every local workaround that should have died three reorganisations ago, and encodes it as policy. Second, when that person rotates, quits, or goes on parental leave, nobody can reproduce what was taught. Three customers and five sites means five separate sets of local knowledge held in five people's heads.

None of that is a reason to avoid it. All of it is a reason to make two requirements contractual before go-live: a written process definition exists and is version-controlled, and a second person can run the demonstration again from scratch. Then schedule a re-teaching drill every six months, the same way you test a disaster recovery plan, and treat it as seriously, because from the floor's point of view that is exactly what it is.

Compare it with the Takt programme that shared the stage, because the comparison teaches the discipline I am arguing for. Sixty-eight employees, six teams, $1,500 spent on incentives, $6,500 saved, a return of 337 per cent. That is twenty-two dollars per person. Their leverage did not come from replacing anybody, it came from harvesting approximately sixty-eight people's worth of local knowledge about where the waste sits, at twenty-two dollars a head. Note also that this project published the input as well as the output. We know the $1,500. We know the $6,500. We were even told the team count, which lets you sanity-check the per capita figure. The other project published output without input. Almost every automation announcement does this, and it is not malice, it is just that the input side of an automation business case is the uncomfortable side.

I would also flag, having seen a lot of incentive schemes, that their returns decay. Suggestion programmes deliver their best year early and then thin out, once the obvious ideas are harvested and the novelty wears off. A 337 per cent return realised in year one is not a run rate, and neither necessarily is 500 hours. Ask any vendor what happens in month eighteen.

Timing. Live since November 2025, with a proof point published roughly eleven months later. That is what a realistic ramp looks like, and it is the number to put in your own plan. Assume six to twelve months before a deployment reaches anything resembling steady state, and assume the first two months are net negative, because during them your people are doing their normal job and training something else at the same time. If you are budgeting this for the first quarter, write the milestones down in the agreement rather than in the slide deck: data access in week two, first wave planned by the system in week six, human review unattended by week twelve.

Now the boundary conditions, because every one of these can zero the return. If your volume profile is low-SKU and bulk-moving, there may be four waves a day and nothing to optimise; scheduling complexity scales with SKU count and due-date spread, not tonnage. If your demand is highly volatile with monthly swings above thirty per cent, a policy learned from one period of behaviour decays fast and you will be re-teaching constantly. If the site is shared by several clients with conflicting priorities, the agent is optimising a constraint set it did not learn cleanly, and the participant with the least voice absorbs the degradation. If your data is poor — inventory counts wrong, labour rosters stale, carrier schedules in someone's mailbox — then a genuinely well-learned policy is optimising against fiction.

Now the counterfactual, stated plainly. Suppose the bottleneck in your building is physical pick rate during peak and always has been. Then automating anything upstream of picking buys you exactly one thing: shorter decision latency. That is worth paying for if your plan currently locks sixteen hours before cutoff and reality keeps moving inside that window. It is worth almost nothing if your plan is rebuilt every two hours already. The return here is proportional to decision volume multiplied by decision latency, not to how advanced the software is. Quantify both before anyone quotes you a percentage.

Put it together and here is the plan I would hand a client. Kenco built something real, and 500 hours a month at one site is a serious result, not a marketing number. But the value to you is not the result; it is knowing which of your own numbers it maps onto. Quantify the coordination loop in your building over two weeks starting now. Write your own accuracy definition with the unit named and the error categories priced. Set your conversion assumption at roughly half the released hours unless you can point to the specific headcount line or overtime line that will actually fall. Then and only then decide whether the target worth attacking is the plan, or the variability the plan is failing to absorb. It is a queue. Find the bottleneck before you buy something to move it.

• Before any pilot is signed, require the vendor to state the denominator in writing — 500 hours measured at one site in one month, or across all five — target: written baseline definition in the contract before any Q1 budget approval.
• Run a two-week baseline of your own coordination loop starting the week of 6 October, measuring supervisor hours per shift spent planning, monitoring and chasing exceptions, target: one defensible hours-per-day figure before any vendor demo.
• Replace any accuracy percentage in pilot contracts with a stated per-unit denominator plus an error log split into categories priced by recovery cost, target: zero unattributed expedited freight dollars for the duration of the pilot.
• Budget the saving at roughly 45 per cent of released hours at your own fully loaded hourly cost, and book zero cash effect unless a named headcount line, overtime line or temp-labour line actually falls, target: forecast within 10 per cent of realised by month six.
• Require a written, version-controlled process definition and a second trained demonstrator before go-live, plus a re-teaching drill every six months, target: no single-person dependency on any deployed process.
• Ask your 3PL which fee lines are open-book or cost-plus and open a gain-share clause now, before deployment rather than after, target: amended contract language agreed before 31 December.