The New Application Layer

An agent needs a way to reach people and an environment in which to work. Malte Ubl opens with two projects from his own development stack that address those needs. Chat SDK connects agents to messaging applications such as Slack, Telegram, and WhatsApp. just-bash is a Bash interpreter written in TypeScript: a way to offer agents a sandbox-like working environment through a tool they already favor. These are small, concrete pieces of a larger shift—software increasingly built by agents, used by agents, and implemented as agents.

The community around that work has a history. Ubl helped run JSConf EU in Berlin, ending its ten-year run in summer 2019. The timing proved fortunate: COVID would have prevented the next edition anyway. But the pandemic also interrupted the hoped-for handover to another generation of organizers. More than half a decade later, the gathering at AI Engineer Europe represents a return, organized around a different discipline. Ubl sees AI engineering as web development’s successor as a mainstream field shaping the next decade. The disruption affects both how engineers build—with AI—and what they build—AI applications and agents.

That raises an immediate career question: is there still a place for engineers, especially the next generation? Ubl’s answer starts with a deliberately self-deprecating comparison. The introduction’s 25 years of engineering experience is, he says, a substantial understatement; none of that experience would make him good at creating TikTok videos. People who grow up inside a medium develop instincts that experienced outsiders may lack. Junior engineers formed in an AI-first working environment may similarly become better at the new discipline. His optimism for everyone else rests on a second idea: agents are a new kind of software, expanding the work that software can economically do.

Imagine a circle containing all the software that should exist. Traditional development fills only part of it. A useful automation might require someone to discover scattered business knowledge, work through exceptions, and encode the result in a growing collection of conditional statements. The benefit can be real while the implementation remains too expensive to justify. Agents make some of that previously uneconomic work affordable. Ubl pictures them filling the rest of the circle, while allowing that we will discover still more software worth creating. The important change is the expansion of feasible automation.

The same change affects the decision to make or buy software. Ubl observes more companies choosing to build what they previously would have purchased as SaaS. Silicon Valley’s talk of a SaaS apocalypse overstates his own conclusion—he expects SaaS companies to survive—but more companies making more software can mean more engineering work even when each task takes less time.

Cheaper software production tests how elastic demand for software really is. If lower costs unlock enough new projects, total engineering demand can grow alongside productivity. Ubl says he sees that growth happening. He acknowledges that the expansion could eventually follow an S-curve and level off, but sees no sign of that limit yet, especially while agent capabilities continue improving. This is an economic thesis about new demand, rather than a claim that existing jobs and tasks remain unchanged.

Building this application layer does not require starting with the most ambitious autonomous agent imaginable. Coding agents work so well that it is tempting to assume their success transfers directly to every other domain. Ubl cautions that it often does not. Meanwhile, simpler opportunities can fit existing operations without the long, failure-prone effort of changing an entire business process. Ubl suggests these opportunities could save companies millions or billions of dollars, without presenting a measured savings case here.

Customer support is an obvious starting point: a business already has support agents and can ask which portions of their work software agents can handle. Sierra and Decagon exemplify the emerging agent-as-a-service category. The more general opportunity is continuous availability. Look for a job where moving from nine-to-five coverage to round-the-clock service would change the value delivered. An agent’s ability to keep working while people sleep can matter even before it changes the underlying task.

A second archetype applies to a common business workflow:

1. A business event arrives.
2. Someone researches the relevant facts.
3. A human makes a decision.

An agent can take over the middle step while leaving the beginning and end intact. Ubl’s illustrative case reduces a task from 30 minutes to five minutes across 100,000 repetitions per year. The attraction is not just speed: the organization can retain its existing decision process. Ubl argues that keeping the human decision also preserves the risk profile. In implementation terms, that decision boundary must remain explicit; producing research should not itself authorize an action.

At Vercel, clicking Contact Sales starts this kind of workflow. Ubl reports hearing that approximately 75% of Contact Sales submissions actually need support and are handed to the support team. For a sales lead, the agent checks LinkedIn, searches for the company, investigates its size, and routes the result to the appropriate person. A human eventually checks that it makes sense. Ubl estimates that this preparation previously took a person perhaps 15 minutes per lead.

Abuse reports have the same structure, with a more consequential decision at the end. The agent investigates whether a website is abusive and what responses might be appropriate; the professional retains the final decision. A TypeScript interface can make that boundary visible by returning a review packet rather than performing enforcement:

type AbuseReport = {
  id: string;
  website: string;
  allegation: string;
};

type Findings = {
  evidence: Array<{ source: string; observation: string }>;
  possibleResponses: string[];
};

type ReviewPacket = {
  report: AbuseReport;
  findings: Findings;
  status: "pending-human-decision";
};

async function prepareAbuseReview(
  report: AbuseReport,
  investigate: (report: AbuseReport) => Promise<Findings>,
): Promise<ReviewPacket> {
  const findings = await investigate(report);
  return {
    report,
    findings,
    status: "pending-human-decision",
  };
}

The function preserves the original report, adds research, and leaves the outcome pending. It contains no website takedown or other enforcement operation. That separation captures the useful scope of this archetype: automate preparation without silently expanding into decision authority.

A company can possess information without being able to use it in practice. An issue tracker may be stale even though the relevant update appeared in Slack or in a Granola meeting recording. The missing work is collecting that evidence and putting it where people expect to find it. An agent can research those sources, help update the tracker, and prepare the status information a manager would otherwise have to request again.

These archetypes can overlap. Continuous operation determines when the work happens; research compression determines which part of a process becomes faster; surfacing information determines which existing evidence becomes useful.

An agent preparing status updates can do all three: watch for new information, collect it, and make it available before someone asks.

A direct way to find the next useful agent is to ask employees: “What do you hate most about your job?” Vercel’s in-house support agent provides Ubl’s example. Ubl reports a 90% deflection rate for Vercel’s support agent, meaning it helps users in real time without sending them onward. He supplies no reporting window or evaluation method for that figure.

The reported organizational benefit is a sharp improvement in support-team job satisfaction. Routine questions, such as a rejected credit card, no longer dominate the queue. Staff can spend more time investigating interesting cases and helping people who need deeper assistance. Ubl gives no numerical satisfaction measure, but the mechanism is clear: removing repetitive work changes the composition of the human job. Eliminating that toil is itself a worthwhile engineering goal.

Agents are also becoming the users of ordinary software. Developer tools are experiencing this transition early. Ubl reports that AI agents accounted for over 60% of page views on vercel.com during the preceding seven days. That observation is specific to Vercel’s site and that reporting window; he does not describe the traffic-classification method. Alongside it, he sees platform usage moving from dashboard clicks toward APIs and CLIs.

This changes feature review. A proposed screen is no longer enough: where is the CLI, how can the feature be automated, and how will an agent use it? As UI creation becomes cheaper, the programmatic interface becomes central to whether the product is usable by its growing machine audience. Automation access belongs in the feature’s design, not at the end of its implementation.

Agent-written software also changes what developers expect from infrastructure. Someone who did not write the code may have fewer preferences about how it runs in production. They still expect it to run, with an experience approaching the simplicity of prompting the agent to create it. Infrastructure providers therefore have to accommodate software mostly written by agents, while agent applications themselves need new execution facilities. Sandboxes are one response. Ubl returns to just-bash as an experiment in giving an agent a computer-like environment without giving it a full computer.

The security implications remind Ubl of 1999: an industry deploying powerful systems before it has learned how to secure them reliably. His concrete architectural objection is that many popular agent harnesses combine the environment running the harness with the environment executing the code it generates. Separate the harness from generated-code execution. The component coordinating an agent and the environment running its generated programs should be distinct.

Ubl points to an unnamed Anthropic agent product he had seen the previous day as an example that has this separation. The larger lesson is architectural openness: these problems are solvable, but today’s harness designs are not the final form. General agents using sandboxes already represent one paradigm shift. Further shifts will require engineers to reconsider assumptions about how agents run and what their infrastructure must isolate.

The application layer can persist while models trade places. One model may lead today and another tomorrow; engineers still need to build the stable software above them. That creates room for AI innovation outside model labs. Ubl makes a regional argument here: Europe can lead in AI engineering without needing to lead model development.

His examples start with Vercel’s AI SDK. Ubl reports that AI SDK receives over ten million downloads per week. He identifies Lars Grammel, working from Berlin, as its lead. He then points to Pi, the coding agent made in Austria, with Mario scheduled to speak the following day, and OpenClaw, with Peter due onstage an hour later. These projects illustrate his claim that consequential AI engineering can happen independently of where frontier models are developed. His expectation that Europe will not play a major role on the model side is a forecast; his central point is that it need not do so to contribute at the application layer.

There are two possible futures for that layer. In the first, a model lab wins decisively. AI remains expensive, the winning company captures the value of agent technology, and application engineers effectively become its forward-deployed workforce. Ubl names OpenAI, Anthropic, and Google as possible winners in that scenario.

He considers the other future more likely: competition commoditizes the model layer. He praises Claude and Codex, predicts Google will catch up, and assigns Google an important economic role. In his assessment, Google has the cheapest infrastructure; he expects that cost advantage to encourage lower prices and sustain pressure on competitors.

These are competing scenarios, not established outcomes. Ubl favors the second because inexpensive, competing models leave more opportunity for the applications built above them.

In that world, agents create the business value, and engineers retain the freedom to discover what comes next. OpenClaw is his example of an invention emerging from the application layer. The next paradigm of AI engineering can emerge there too: from people building useful agents, rather than only from the companies training their models.