Agent-native software: what is it, and why should we care?

As the world sits on the precipise of agent driven work. We are seeing a fundamental shift in sentiment; the doomer viewpoint of "AI is going to take our jobs" is giving way to something more encouraging, grounded in Jevons Paradox:

As a technology makes a resource more efficient to use, total consumption of that resource tends to rise rather than fall.

The resource here is human capital.

If that holds, the measure of success for agentic AI is not how many humans are replaced by agents, but how much agents enable us to catalyse the benefits unique to human capital, at a much higher bandwidth. Those benefits are creativity, design, judgement and accountability. In a world where agents take on the majority of the execution load - people move up a level: they become the orchestrators of the work, the decision-makers and the accountable owners of the result.

As more organisations begin their agentic AI journey, here are a few practical reflections to consider.

Generic harnesses in deep domains

Most early adopters of agentic tools are using generic agent harnesses/wrappers - built for broad, loosely defined use cases on commonplace applications like MS Office. These experiments can produce impressive results, but turning them into a corporate strategy is a much harder problem.

Actuarial operating environments run on a stack of far more domain-specific software - tools that handle:

Data preparation, ETL and validation
Low-level model-point liability modelling
Results aggregation and IFRS 17 CSM / loss-component calculations
Analysis of surplus
Actuarial subledgers and results consolidation
Statistical investigations and analytics
Dashboarding and reporting

Which raises the first question worth asking: are generic agent harnesses actually suitable for the actuarial operating environment?

The reliability problem

The first hurdle will be whether your agentic system can produce reliable results. Let's start with a quick thought experiment. Suppose we want to automate a reserve valuation process which has six user interaction points per product and eight product lines - 48 individual human contact points to automate. If we optimise each agent interaction to 99% reliability, the probability of a clean end-to-end result (the compound product) is just 61.7%. That is nowhere near good enough for enterprise use.

So before anything else: if agents are going to carry the bulk of execution, we need to maximise reliability. In practice this means, reducing silent failures, raising the success rate at each interaction point, and reducing the number of interaction points altogether.

Agents are not human replacements

Agentic systems feel organic, almost 'quasi-human', in how they work - combining LLM reasoning, tool calls and user-supplied context to plan, execute, evaluate and adapt. That resemblance leads to the first mistake: assuming an agent is a good drop-in replacement for a human in an existing workflow.

It isn't. Agents have a fundamentally different profile of strengths and weaknesses from people, and traditional software is, necessarily, human-centric: designed around human strengths and weaknesses. Let's look at some of these differences:

Jagged capability boundary. LLM capability is unevenly distributed in surprising ways. An LLM can explain the competing approaches to graduating mortality rates, yet fail to count the number of R's in "strawberry." These gaps are usually closed by giving the agent the right tools (scripts and functions) rather than trusting it to reason its way through.
Memory. For humans, learning and retention are natural products of the work process. For agents, any knowledge retention has to be made explicit.
Silent failures. LLMs are prone to a particular kind of false positive, the hallucination. The agent fails silently and, worse, often reports success. That is especially dangerous in less programmatic tasks, where the output is hard to verify.
Speed. They read, write, reason, code and execute far faster than people.
Availability. They don't keep office hours.
Replication. They scale up and down with demand, giving a far more elastic workforce.
Cost. Agent attention is typically much cheaper than the human equivalent.

The point is not that agents are better or worse than people. It is that they are different, and software built for one will not serve the other well.

How agents should interact with the stack

Come back to the valuation example and the three levers: fewer silent failures, higher success per interaction point, fewer interaction points. Designing for those changes how agents should interact with the application layer:

Make interaction points fewer and denser. Agents work best with full, explicit context in and out. Humans usually need far less exchanged at each step.
Favour fewer, more scalable execution patterns. The more structured and consistent the patterns we hand an agent, the better. That often implies a higher level of abstraction than is ideal for humans, who tend to prefer many specialised processes that guard against misuse.
Design for first-pass success. Retries and downstream correction are exactly where silent failures multiply, so workflows should be shaped so the agent either gets it right the first time or fails loudly enough to be caught.
Build for agent-speed iteration. Existing applications are built for human speed. Once execution accelerates, new bottlenecks surface at the application layer.
Improve user-agent communication Closing the gap on terminology used between users, the agent tools and the application input/outputs will the agents interpretation of the user requests.