Kaya AI - #1 AI-powered Supply Chain Platform in Construction

At this point, no one really needs another AI history lesson. When it comes to the popular discourse, it can basically be divided into two periods: BC (Before ChatGPT) and AD (After ‘Dat). In 2022, OpenAI released what they thought was going to be a toy chatbot application and all of the worst people you know haven’t been able to shut up about it since. The reality is, AI has been around since far before it was any good at helping kids cheat on their homework. Artificial Intelligence was already being used in an academic context in the 1950s. Admittedly, from the point of view of the general public, concrete advancements since then were pretty glacial. It’s only been over the past couple of years that the models have started to really take off, and they’ve done so in an exponential way.

Because the models have been improving so quickly, the frontier labs are under immense pressure to stay ahead of one another. One result is that many of the field’s strongest researchers are heads-down in those labs, working on the hard problems. Another is a crowded landscape of commentary, with plenty of voices trying to make sense of a field that is moving faster than anyone can genuinely keep up with (myself now included). Between the pace of model improvement and the sheer volume of noise, trends are being born and killed at staggering rates.

This has been apparent to no one more so than to software developers, who are being told to re-learn how to do their job every couple of months. It used to be that you would have to know the syntax of the coding language your company used, and if you had an issue with something you went to the official documentation or an online message board (RIP Stack Overflow). That changed to pasting the errors into ChatGPT instead, and then copying the code snippets it spit out into the chat. Then the conversation moved inside the IDE, and development with Cursor or Windsurf turned into accepting or rejecting line-level changes across files. Claude Code came next, and junior developers who once lived in fear of Vim were suddenly tossing their IDEs into the bin and embracing the next level of abstraction: no longer looking at the files at all. Development had become a conversation about the changes with no inspection of the line-by-line diffs. Still, it became clear there was more leverage to be extracted from this technology, and soon development had retreated even from file-level changes to discussing wholesale features with independently iterating agents. This is in many ways a simplification, but it illustrates the point I’m trying to make: developers are trailblazing the “real world” application of AI.

Because software developers are consistently getting hit the earliest by “the next big thing”™, it also means they get to decide what we call a lot of this crap. Which is how we finally get to the subject of this post: agents.

From agents to an agent

The concept of agents was relatively intuitive for developers. There was already a general groundwork of understanding around containerization, runtimes, objects, and inheritance. Additionally, developers had been exposed to the whole history of “agentic” development so far, which was really just adding a couple of structured LLM calls into a function here and there and maybe coordinating these into a graph structure. To some degree, though, this was a case where form was driving function. This was the shape developers were used to working in (and to some degree it was still needed by the model capabilities at the time), and it in turn drove how these systems were discussed.

Non-technical stakeholders embraced the framing as well, in part because they wanted to feel included in the new technological revolution, and also because it allowed individual features to be repackaged as if they were whole products (i.e. “agents”). Suddenly, there was an influx of platforms boasting about the size of their agent catalogues. However, this wasn’t destined to last.

The natural conclusion of AI isn’t a bunch of individual tools that can handle slightly more ambiguous input. It’s replicating human autonomy in the workplace, and that means a single point of interaction. If I ask a human intern to bring me a report we presented last quarter and do a coffee run, they wouldn’t do those tasks sequentially. The intern would probably call in the order, find the report in a database and queue it to print, then go get the coffee and pick up the report from the printer on the way back to my office. If I were to then ask them the next day to prepare a new report for this quarter, they would (probably) know to use the same template from the report they had just looked at the day before. Applications that treat “get past report”, “get coffee”, and “create new report” as three independent problems fail to benefit from all of the efficiencies that arise when solving them as a related system.

A mindset shift from creating agentic tools (agents) to creating an agent that calls those tools, along with continued model improvement at the frontier, is what has led to actually AI-native platforms in which LLM calls are integrated as a single, pervasive system. That’s not to say there isn’t value to graph-based model orchestration or multi-agent systems, but rather that there is a meaningful difference between a system designed to be a whole and one that was patched together. This marked a new wave of technical design focused on a unified harness. It started with applications like OpenClaw and Devin, and the trend has now cemented itself with the recent releases of Muse, Dots, and GrokBot. Kaya is proud to have been one of the early adopters of this philosophy, and it’s what guided the design and implementation of our proprietary agent harness for Amber.

Harness engineering is the new moat

Harness engineering is also where startups can continue to create differentiation in an age where the capabilities of frontier models are eating all other technical moats. It used to be the case that companies in more niche domains could still get an edge by training or fine-tuning their own models. However, as the big labs continue to invest heavily in data and RL environments, there is less and less data that is truly out of distribution for the newest generations of their models. The caveat here (for now) is truly distinct domains like biometric data, but the sentiment certainly holds true for pretty much any white-collar SaaS application. Enterprise clients are also becoming wise to the value of their data and increasingly look to restrict access to it for training. Combined, these factors paint a grim picture for most startups looking to peddle proprietary models. By shifting the focus to harness engineering, however, the gains of major model providers become a net benefit. Studies continue to show that the performance of even the best models depends on the harness, and that not all harnesses are equally effective.

What comes next

If the previous big wave was the unified agent harness, I’m predicting the next trend in development is going to be one focused on self-improving harnesses. That’s the bet the engineering team at Kaya is making.