FourKites Targets 70 Outcomes and 1bn Agent Work Hours Across 176 Countries

The Analysis

On 14 October FourKites said it would stop selling features and start selling the number a customer is judged on. Its Outcome-as-a-Service model begins with a metric such as on-time-in-full or cost to serve, then works backwards to the AI agents that move it. The company lists more than 70 outcomes, each mapped to executing agents. Underneath sits a graph it describes as more than 1,600 brands, more than 500,000 carriers and 3.6 million facilities across 176 countries, handling 3.2 million events a day. Founder Mathew Elenjickal's argument for why none of this can be copied is about context rather than code: a single company's own data cannot teach a model how half a million carriers behave.

Strip the packaging and what changed is the unit of sale. For twenty years visibility was sold as information: here is where your box is. Now it is sold as movement in a scorecard you are already being graded on. That is a genuinely different product, and a different risk, because information can be checked, while a movement cannot be checked without an agreed baseline.

And the party carrying that scorecard in cross-border trade is usually us. The exporter shipping into a retailer's compliance programme owns the on-time-in-full number. The importer whose distribution centre books appointments owns the other half of it. So before anyone looks at the agent, look at the meter: who defines the number, who computes it, and what happens when the two sides disagree.

The structure is easy to describe in control terms. The outcome is the objective function, the agents are the controller, and the graph is the state estimate. Anyone who has built a control loop asks the same two questions on seeing that picture: how good is the state estimate, and who owns the yardstick. What follows is those two questions, asked in operational language.

Why now, and why from a visibility company? Three pushes line up. Agent inference became cheap enough to run per event rather than per seat. Visibility itself became a commodity, so differentiation had to move one layer up, from telling you what happened to changing what happens next. And scorecards grew teeth: retail on-time-in-full programmes that levy a percentage of goods value turned a reporting metric into a cash line. A vendor selling outcomes is selling into that cash line, which is a far better place to sell than an IT budget.

Who this reaches is narrow and specific. If you ship into a consignee that measures delivery performance and charges you for the misses, every point of compliance has a price, and a product that moves that point is worth pricing. If you move bulk or breakbulk where the only metric that matters is whether the vessel berthed, none of this touches you. If you are the importer and your pain is demurrage and appointment compliance at your own distribution centre, the relevant outcome is not on-time-in-full at all, and you should establish which of the 70 outcomes maps to your actual cash leak before looking at any agent.

Let us do arithmetic on the largest number in the announcement, because it is the one everybody repeats and nobody checks. One billion agent work hours. The platform states 3.2 million events a day, which is 1.168 billion events a year. Divide one by the other and you get roughly 0.86 agent hours per event per year. Now attach a price: if an agent hour stands in for an analyst hour at an assumed 40 dollars fully loaded, that is about 34 dollars of machine effort per event per year. Compare it with what you spend today on the events that matter. Assume an exception takes 0.4 hours of human time, 16 dollars, and assume 15 percent of events become exceptions. Your own spend works out near 2.40 dollars per event per year. The claimed machine effort is roughly fourteen times that.

That ratio is not a criticism, it is a map. It says the agents are not spending their hours on the 15 percent of events a human already touches. They are spending it on the 85 percent nobody has ever opened: the dwell that never became an alert, the appointment that was moved twice without anyone noticing, the estimated arrival that drifted six hours while staying inside tolerance. That is where the value has to come from if the product is real. It also tells you what to ask for in a demo: not the exception dashboard you already own, but the list of events the agent acted on that no human would ever have opened.

Now the queue, because that is where this either works or does not. Events are arrivals. Exception handling is the service process. Historically the server was a person with an inbox. Under this model the server is a policy engine with a budget. The questions are the ones you ask of any service system: what is the arrival rate, what is the service rate, what is the utilisation, and what happens to the backlog when arrivals spike in peak season. A platform handling 3.2 million events a day is describing its own aggregate queue. It is not describing yours.

So measure yours. Assume 1,200 shipments a year, 100 a month, at 8 events each, which is 800 events a month. Assume 15 percent need a human, so 120 exceptions at 0.4 hours each, which is 48 human hours a month. Assume two people each spending a quarter of a 160-hour month on exceptions, giving 80 hours of capacity against 48 hours of demand. Your queue is not saturated. That carries an uncomfortable consequence: the labour you could actually remove is 48 hours a month, about 1,920 dollars at the same loaded rate, roughly 23,000 dollars a year. And it only becomes cash if you genuinely cut headcount, which most companies do not do, since they redeploy the people instead. The hard-dollar case for buying agents out of payroll is smaller than the pitch suggests.

The money is in the penalty rather than in the payroll. Assume you ship 1,200 consignments a year at 42,000 dollars of goods value each, which is 50.4 million dollars of goods value. Assume your measured compliance is 88 percent and your programme charges 3 percent of goods value on non-compliant deliveries; both are my assumptions, so fill in your own contract. Twelve percent non-compliant against 50.4 million at 3 percent is about 181,000 dollars a year at stake. Each point of compliance is worth 1 percent of 50.4 million times 3 percent, which is 15,120 dollars a year. That is the conversion rate you need before you can price anything at all.

But not every miss is reachable by a transport agent, and this is where business cases quietly inflate. Split your misses by cause. If the load was late because production slipped, because the container was stuffed late, or because a document sat on a desk, the shipment entered the network already late and nothing downstream can recover it. Only the in-transit share is addressable. Assume, and you must replace this with your own data, that 45 percent of your misses are in-transit and 55 percent are origin-caused. A promised five-point lift in compliance is then worth five times 45 percent, or 2.25 points, at 15,120 dollars a point: about 34,000 dollars a year. Under these numbers, that is the ceiling on what this product can be worth to you.

Build in a safety factor and you have a negotiating position. Attribution is uncertain, baselines get contested, and a five-point promise is still a promise. Discount the benefit by half to cover that and the defensible figure is around 17,000 dollars a year. Anything quoted above 34,000 dollars a year cannot pay back even if the vendor hits the number exactly. Anything above 17,000 dollars a year requires you to believe the attribution. Write both figures at the top of the proposal before the demo starts.

Here is the part I have not seen discussed, and it is the part that decides whether this is a good contract. When you buy an outcome, the invoiced quantity is a difference between two measurements, and a difference needs a baseline. Whoever defines the baseline and computes the difference owns the meter. In this arrangement, the meter, the underlying event data and the agent being paid for the movement are all the same supplier. Electricity meters are regulated, water meters are certified. There is no equivalent here, no standard for what counts as a valid baseline period, no rule for how seasonality is handled, and no answer for what happens when you change your carrier mix halfway through. You can be billed on a number you cannot reproduce.

The remedy is not complicated, and if the vendor is confident it costs them nothing. Require event-level export of the raw data at no extra charge. Require the baseline period, its length and its seasonal adjustment to be written into the contract before it starts. Require the right to recompute the outcome metric with your own code and to use your recomputed figure in any dispute. Require a consignee-side confirmation of the delivery timestamp, because on-time-in-full is ultimately measured by the receiver rather than by the platform. If the answer to any of those four is no, you are not buying an outcome, you are buying a number, and the number belongs to somebody else.

The second thing nobody says is more interesting and less comfortable. Seventy outcomes, each with an agent, all drawing on resources that are finite and shared: a carrier's truck, a dock slot, a driver's remaining hours, a warehouse appointment, a broker's attention. Multi-agent systems optimising separate objectives against shared constraints produce a well-known failure mode, where every agent does the right thing for its own principal while the system as a whole gets worse. And the shared resources here are shared with other shippers on the same graph, because the graph is the selling point: 500,000 carriers and 1,600 brands all feeding one state estimate.

Follow that through. If an agent books the last truck on a lane for you, another shipper's load waits for the following one. Their on-time-in-full falls by roughly what yours rises. Nobody has done anything wrong; the system has reallocated a scarce slot. But it means part of the improvement is a transfer rather than a creation, and it is not repeatable across the market. If every shipper on the graph buys the same product, aggregate performance does not move while everybody pays. That is a structural limit on the outcome model rather than a defect in this implementation, and I would put it to the vendor directly: when two customers' agents want the same asset, how do you arbitrate, and what happens to my outcome when a competitor's agent wins?

There is a smaller version of the same problem inside your own contract. On-time-in-full and cost to serve pull against each other, because you buy delivery performance with expedites, premium modes and buffer stock, all of which raise cost per unit. A vendor paid on both outcomes has two objectives and one budget, and the contract says nothing about which one wins. Make it say something. Name the primary outcome, cap the spend an agent may authorise without human approval, and require a log of every authorised expedite against the outcome it was bought for. Otherwise you will hit the delivery number and then discover what it cost.

Seventy outcomes sounds like breadth, but for a buyer it is a selection problem. Any vendor paid on a metric will steer you towards the metric it can move. On-time-in-full on a lane where the carrier is already reliable is easy to improve and worth far less to you than the two lanes where you are bleeding. Before signing, rank your own outcomes by cash at stake and refuse a contract that pays on anything outside your top three.

There is a precondition that every agent pitch skips, and it is boring enough to decide the whole outcome anyway. An agent is only as good as the identifiers it joins on. If your shipment references, purchase order numbers and container numbers do not reconcile across your own system, your forwarder's system and the carrier's, then the agent is resolving entities by probability rather than by key. Ask what the match rate is on your own shipments, and what happens to events that fail to match. A platform can be excellent at state estimation and still be reasoning about a shipment identity that is wrong, and an outcome billed on a mis-joined shipment is worse than no outcome at all, because it looks entirely correct on the dashboard.

The moat argument also deserves a test you can run yourself. The claim is that cross-company context cannot be reproduced by a single company's model, and on its face that is plausible. But you do not ship the global graph. You ship perhaps twenty lanes, with a handful of carriers and a fixed set of facilities. What matters is not the size of the graph but its completeness on your lanes: for each of your shipments, what fraction of the expected events actually arrived, and how fresh were they. Ask for a 30-day report of per-shipment event completeness on your own lanes. Below 90 percent, no outcome commitment is defensible, because an agent cannot act on a state estimate that is missing a tenth of itself.

Timing runs slower than the sales cycle suggests. An outcome contract signed in the fourth quarter of 2026 needs a baseline, and a baseline worth arguing about takes eight to thirteen weeks. On-time-in-full is computed monthly, so you need at least three monthly cycles before a movement is distinguishable from noise, and it only counts on lanes that had a clean baseline. Add the holiday distortion at both ends of the year and the first credible read lands in the second quarter of 2027. Plan the renewal around that rather than around the signing date. Note too where the agent's authority begins: it can act from the booking onwards. A load already late at handover is outside its reach, which is another reason to know your miss-cause split before signing.

What would make me wrong about all of this? Two conditions. If your misses are overwhelmingly in-transit and visible, say 60 percent or more, then the addressable share is large, the attribution is easy to defend and the product is worth a pilot at a real price. If your consignee's receiving operation is the actual failure, with appointment denials, dock congestion or a receiving window nobody can hit, then no transport agent can fix it, the outcome will not move, and you will spend a year arguing about why. The dividing line is a cause-of-miss report, and that report is yours to produce, not the vendor's. In-transit share above 40 percent, pilot it. Below 20 percent, put the money into production planning and booking discipline instead.

If you do pilot, design it so the argument about attribution never happens. Pick sixteen lanes with comparable volume and mix. Turn the product on for eight and hold eight back for thirteen weeks. Keep the carrier mix, the cut-off times and the SKU profile identical across both groups. Compute the outcome with your own data and the consignee's timestamps rather than the vendor dashboard. Doing it this way costs you a quarter of delay. Not doing it costs you a renewal conversation in which you cannot prove whether the number you were billed on moved at all.

One more asymmetry is worth naming. The moat is built from everybody's data, including yours. Every event you feed the graph improves the state estimate for the other 1,600 brands on it, some of whom compete with you for the same trucks. That is a reasonable trade if you are paid for it and a poor one if you are not. Ask what is pooled, what stays private, whether your identifiable data trains models served to competitors, and whether there is a price for opting out of pooling. The answer will tell you what the vendor thinks your data is worth, which is a useful input to your own negotiation.

The one billion hours also needs to be read carefully. It is a scale ambition across the customer base, not a commitment to you. Ask what is actually guaranteed: a named agent action per event class, a response-time bound, or only an aspiration. Convert whatever is promised into a service level with a remedy attached, because an aspiration has no remedy by construction.

Measure first, then optimise. The single number to go and get before any of this is your cause-of-miss split: of your last hundred late or short deliveries, how many were already late when they were handed to the carrier. If that share is small, the outcome model is aimed at the right problem and worth pricing. If it is large, the most expensive visibility product on the market will faithfully report a failure that happened inside your own factory, and then invoice you for it.

↑ Back to the key points

— By Ravi Chandran