Why agents will eat the world

Agents are the new software and should be treated as such

Agents will eat the world.

15 years ago, Marc Andreessen famously predicted that software would eat the world. He posited that more and more businesses and industries would be run on software, that products and services would be delivered online, and that every industry would eventually be disrupted by a software company.

It’s easy to see the same story with AI and agents, a future where AI companies soon take over industries, replacing incumbent companies and their business models (SaaS-pocalypse anyone?).

Simply put, agents are the new software.

But what does that imply? And more importantly, what does that teach us?

Today, most teams aren’t yet treating agents like they treat software. Agents are running out of a Claude or GPT session, some skill files, and some basic scheduling. In software terms, it feels like a set of shared scripts that get passed around the organization.

Looking at agents from the lens of software, it tells us there’s so much room for growth.

As we graduate from one-off scripts, we start building functions and classes, which then become applications that can handle more coordinated and complex work. Practically speaking, this uplevels teams from an assortment of AI workflows (triage ticket, summarize standup, run support runbook) to a more coordinated agent or agent team that can handle meatier work.

This also requires us to apply software practices to agent development, like source control, ownership, monitoring and more.

It’s time for teams to consider a higher level of AI work and all the implications of what makes that happen.

Agents: ML + Software

It all starts with the model. An LLM is a reasoning engine unlike anything we’ve had. It works without you training a model of your own, and it works better with some tuning.

LLMs are effectively the most powerful ML model we’ve ever witnessed, one that can get us 50% of the way on the first shot, and 80% of the way with some basic tuning.

Then we layer on tools and state and memory, which takes an LLM and turns it into an agent.

An agent does things. It can produce meaningful pieces of work (code, briefs, research, operational workflows) by combining the reasoning of an LLM with the tools around it.

And now we have the harness, the software around the model: codifying the tools it can reach, the permissions it runs under, the workflow it follows, the memory it keeps, and the feedback that tells it how it did.

What this means is that we have the primitives for some of the most powerful applications we can dream of, all within our hands, especially with the advancements in 2026 in reasoning and harness engineering.

It also means we have the most complex piece of technology to manage, one that requires disciplines from both data science and classic product engineering.

Where agents are heading

Many teams start in the terminal, with a person driving the agent by hand and correcting it as it goes. It works because the person supplies most of the framework themselves. They pick the tools, hold the state in their head, approve each step, and judge whether the output was good.

The next move is designing agents like software. Someone decides, before the agent runs, what it is for, what it is allowed to touch, what it hands off, and what done looks like. The tools get codified instead of pasted in. The permissions get written down instead of assumed. The workflow becomes something the team can read, review, and change.

Then you deploy them. An agent that only runs with one human is still a script with a better vocabulary. An agent that runs on a schedule, against defined tools and workflows, for people who did not build it, is an application. That is where the meatier work lives: work that spans days and systems and teammates rather than one prompt.

And then you measure and tune. Engagement and performance are the two signals worth watching: who is using the agent, how well it does the job, and what the feedback says needs tuning next.

We have pretty much all the tools to make this a reality, so I’m predicting that we’re about to see a proliferation of agents deployed to handle real work in the next 6 months.

In order to get there, teams need a few things in place:

1. A harness and meta harness. One agent needs a harness: the tools, the permissions, the workflow, the memory, the feedback - which is generally what you get with your coding harness. Deployed agents need a meta harness: the layer teams use to build, orchestrate, and maintain multiple agents that coordinate together on a task. That layer is what separates running a couple of agents from running many, and it is the piece most teams still have to build.
   
   

2. A mindset shift. Agents are software applications, and they need the collaboration that software gets. Engineers and PMs have to sit together and define what problems an agent will solve, and what it won’t. Permissions, tools, agent design, measurement, feedback loops, and everything else that comes with product development need to start coming into play when you deploy agents like software.
   
   

3. Shipping is only the start. Most importantly, teams need to recognize that shipping an agent, just like shipping a software product, is only the beginning. The real work starts afterwards: tuning it, adjusting it on feedback, and finding the cases it handles badly. Shipping to production is a false finish line and teams need to be ready to work on agents even after they deploy.
   
   

What I’m seeing

As of today, I’ve noticed a pattern in most enterprises I’ve talked to:

• Most of the engineers are using a coding agent, usually Claude or Codex or Cursor

• They have shared skills and a decent development process

• They have 1 or 2 deployed agents handling simple workflows, either tucked into existing software systems or deployed within their coding agent

As these use cases grow, teams will need to consolidate their one off agentic workflows into more coordinated agent tasks that roll up into agent roles, that roll up into agent teams.

If I’m leading a well funded technology organization, I’m going to invest in building this platform right now - setting up a harness that lets me deploy, manage, and measure my agents.

Getting really good at building agents is the same as getting really good at building software - it’s necessary if you want your organization to thrive in this next era.

As your expertise and mastery grows, this gives you optionality to take on more of the stack. You can opt to start hosting your own inference, owning the intelligence layer and protecting your customer information.

The alternative is to purchase these agents as SaaS products - there’s a dozen vendors for each AI enterprise use case right now, from engineering to support to GTM to analytics.

Buying your agents as SaaS can help your team get some quick wins, but I would limit this to select wins to get off the ground. At scale, the cost will get unwieldy and the math just doesn’t make sense.

Why would you outsource your agents to a SaaS vendor who is just building a harness of their own and then charging a markup on tokens for the same model?

So what’s next?

Lots of teams have started moving up the agentic engineering curve, learning how to build with agents.

The clear next frontier is developing your organizational muscle of building agents.

Doing so requires a mindset shift back to a very familiar world.

After all, agents are the new software.