Discover how AI agents are fundamentally changing software design, enterprise systems, and business operations. Learn what companies need to know about build...
AI Agents Revolution: How Businesses Must Redesign Software for the Future
Key Takeaways
- AI agents are becoming the primary users of software, with companies now designing interfaces and systems for autonomous agents rather than just humans
- The agent interface paradigm is shifting from code-based integration to API-driven and computer-use approaches, creating new operational challenges
- Enterprise security and governance present major hurdles, requiring new frameworks for access control, agent oversight, and data protection
- Business model transformation is underway, with SaaS vendors facing pressure to expose data APIs and rethink their entire monetization strategy
- A massive capability gap exists between startups (moving fast with AI agents) and enterprises (moving slowly due to legacy systems and risk concerns)
- New business economics are emerging around microservices, on-demand agent labor, and the monetization of previously underutilized data and software
- Computing infrastructure costs will reshape engineering budgets, with token consumption becoming as critical as traditional engineering expenses
Understanding the AI Agent Paradigm Shift
We are at an inflection point in how organizations build and deploy software. The fundamental assumption that applications exist primarily for human users is rapidly becoming obsolete. Companies like Box, Anthropic, and OpenAI are architecting a new generation of tools designed first and foremost for AI agents—with human interfaces becoming secondary considerations.
This represents a seismic shift in software design philosophy. Historically, engineers spent the majority of their time optimizing user experience, interface design, and human workflows. Today, product teams allocate equal or greater resources to agent-friendly interfaces: APIs, command-line interfaces (CLIs), and structured data layers. The reasoning is straightforward but profound: if there will be hundreds or thousands of times more agents than people interacting with systems, software architecture must fundamentally invert to serve this new primary audience.
The implications are staggering. When an organization gives a coding agent access to a Software-as-a-Service (SaaS) tool, combined with knowledge workflows and contextual information, it grants that agent a "superpower." The agent can now do far more than passively consume data—it can actively write code, orchestrate multiple systems, and accomplish complex tasks autonomously. This capability compounds rapidly as more tools adopt agent-friendly interfaces.
The technical implementation is evolving along a clear trajectory. Initially, the focus was on agents writing code directly against systems. Then came API-driven approaches. Now, the cutting edge is "computer use"—where agents interact with systems much like humans do, navigating UIs and leveraging existing interfaces without requiring custom integrations. This evolution matters because it democratizes agent deployment: organizations don't need to wait for every vendor to build perfect APIs before deploying agents. The agents can work with what exists.
Yet despite this excitement, there's a critical reality check. Most people in professional roles struggle with algorithmic thinking. The majority cannot produce a detailed flowchart of their own job functions, let alone articulate the precise, repeatable steps needed to instruct an agent. This cognitive barrier is often underestimated in discussions about agent deployment. Simply placing advanced tools in front of employees and expecting them to build agent-driven workflows runs into hard limits—the average person simply cannot effectively articulate "what to do" in the structured way an agent requires.
Historically, organizations have solved this problem through specialization. Skilled system thinkers and architects build abstraction layers—small "toolsets" designed for specific tasks. Some employees can stitch these together creatively; many cannot. The Anthropic growth marketer who automated tasks previously requiring multiple siloed roles represents the exception, not the rule. That individual was a systems thinker who understood how to decompose complex marketing workflows into discrete, automatable steps.
The Enterprise Integration Challenge: When Agents Meet Legacy Systems
As organizations begin deploying coding agents with access to command-line interfaces and multiple SaaS platforms, they're discovering a entirely new class of problems that previous generations of IT leaders never had to contemplate.
Consider a practical scenario: a company with 5,000 employees gives everyone access to a shared repository—say, engineering documentation and marketing assets. Now, every employee has Claude Code running with Box CLI access. Suddenly, the system is being hit 10,000 times per hour, not necessarily from a performance perspective, but from a coordination and data integrity standpoint. What happens when one agent moves a file from folder A to folder B while another agent is attempting a write operation in folder B, and a third agent is trying to delete something? The result is chaos—a coordination problem fundamentally different from managing human workflows.
This scenario highlights why enterprise organizations are approaching agent deployment with extreme caution. The default instinct—treat agents like human employees—breaks down immediately under scrutiny. With human employees, you cannot (and should not) monitor their Slack channels, log in as them, or maintain complete oversight of their daily actions. Humans have accountability, privacy rights, and behavioral norms shaped by centuries of organizational culture.
Agents have none of these constraints. An organization deploying an autonomous agent faces a stark reality: you have complete liability for everything the agent does. You need complete oversight capability, including the ability to log in as the agent and undo its actions. Yet if you can log in as an agent at any moment, how can that agent genuinely operate independently in the real world while maintaining confidentiality and security with collaborators?
This paradox leads to an uncomfortable truth: agents must function as extensions of their deploying organization's identity and authority. They cannot operate with the autonomy and privacy protections humans expect. The implications are profound. If an agent has access to an M&A data room and someone emails it with a carefully crafted prompt injection, the agent—unlike a trained human employee—may be susceptible to inadvertently leaking confidential information. Humans have been conditioned to resist social engineering and maintain confidentiality; agents lack this cultural conditioning.
The security implications multiply across systems. Most agents deployed today are essentially "sloppy computers." They cannot reliably keep information in a context window secret. If you tell an agent "do not reveal X thing," but then that agent accesses a resource where X appears, you should assume, from a security standpoint, that X can be prompt-injected out of the context window. There is currently no robust technical solution to this problem.
This reality is why enterprise CFOs and CIOs looked skeptical when presented with agent automation scenarios. Their concern isn't theoretical—it's grounded in decades of experience managing security risks at scale. When an organization permits agents to create new integrations between systems on the fly (what's sometimes called "integration on demand"), it's essentially asking employees to create new API connections between systems 27 and 38 without pre-approval or vetting. In a read-only consumption layer, this might be acceptable. But when agents can write data, create new workflows, and potentially expose systems of record, the risk profile becomes untenable.
What we're witnessing is a necessary conservative response from large organizations. They are, sensibly, closing off agent access until some framework for sanity emerges. Meanwhile, a massive capability gap is opening between enterprise organizations (moving cautiously) and startups (moving at speed). Startups have no legacy systems to protect, no consolidated data repositories to secure, and no institutional inertia. A startup's agent going rogue and deleting files has minimal consequences because the startup has minimal assets to lose. An enterprise facing the same scenario faces catastrophic risk.
The SaaS Vendor Dilemma: Data Access vs. Business Model
The agent revolution creates a fundamental tension within the SaaS industry, and it's one that the current market leaders are not well-positioned to navigate.
For decades, SaaS vendors have built their business models on a simple premise: they own and control access to both the software interface and the underlying data. A company using Salesforce, Workday, or SAP pays for the privilege of accessing that vendor's software stack and the domain expertise baked into it. The vendor's economic model depends on extracting value from restricted data access. Every additional API call, every new user, every data export—these were carefully controlled monetization points.
Now agents want something fundamentally different. They want unlimited data access. An agent building a report doesn't care about licensing costs or per-API-call pricing—it wants to ingest all relevant data and process it autonomously. From the vendor's perspective, this represents a threat to their entire historical business model.
The tension is real and substantial. Major SaaS vendors like Workday and SAP have spent years debating how much API access to expose precisely because they recognize the threat. Salesforce famously underwent three massive platform redesigns as it grappled with questions about API-first architecture. The question underlying all of this: if agents get full data access, what exactly is the vendor selling?
The honest answer is uncomfortable for many vendors: they're primarily selling the software interface and the domain expertise embedded in that interface—not the data itself. An SAP system contains 25 years of accumulated domain knowledge about how complex supply chains, financial systems, and human resources interact. You cannot simply "vibe code your way" to SAP. The system's value isn't just in its data layer—it's embedded in the business logic, the middle-tier processing, the workflows built into the UI, and the institutional knowledge about how to use the system effectively.
Yet if agents gain full access to that data, the vendor's monetization model shifts dramatically. Instead of charging for seats, they might charge per data record accessed, per API call, or per integration. This is not the $2-3 billion annual SaaS revenue model the industry is accustomed to. It represents either constraint (fewer total agents using the system) or a fundamental re-architecture of how these vendors monetize their offerings.
This creates a peculiar scenario. Vendors have no incentive to enable broad agent access because doing so potentially reduces their total addressable revenue. Yet if they don't enable broad access, agents will choose competitor systems that do. Over time—and across enough iterations of agent deployment—the agents themselves effectively become the deciding factor in which systems organizations adopt. The meritocracy of technology selection may finally emerge: organizations will use tools that agents find most useful, rather than tools selected by procurement departments or enterprise architects.
The wildcard is whether vendors can develop new monetization models fast enough. Some might charge per agent. Others might shift to pure consumption-based pricing. The key insight is that the revenue itself may increase even if per-unit economics shrink, because agents will accomplish so much more with the same data. If an organization previously had 50 people working with a SaaS system, and now it has 50 humans plus 50 agents using the same system, the total value extracted might be 10x higher—making the vendor's economics work even with lower per-unit pricing.
But getting there requires vendors to make a leap of faith that most incumbent software companies struggle with: trusting that total revenue will grow if they open their platforms more aggressively, even if per-transaction revenue shrinks.
Architectural Layers vs. Collapsing Stacks: The Competing Visions
Within the AI and software architecture communities, two competing visions are emerging about how systems will evolve in response to agents.
The first vision, sometimes associated with figures like Elon Musk and others in the "first principles" camp, suggests that existing architectural layers will collapse. This view holds that once you can prompt a system and receive compiled machine code as output, why would you need all the intermediate layers? The middleware, the APIs, the data warehouses, the business logic layer—all of it becomes redundant if you can simply issue a prompt and get directly to execution.
The competing vision draws from the history of computing itself: architectural layers never truly disappear. They compound and accumulate. The reason is partly technical (compatibility requirements) but largely organizational. Layers exist because of organizational boundaries, business requirements, regulatory constraints, and institutional knowledge. They persist not despite being inefficient, but because they encode real organizational decisions that matter.
The second view appears to be more grounded in historical precedent. The cloud didn't eliminate on-premise infrastructure—it added new layers of abstraction on top. Web services didn't replace mainframes; organizations added web services as new layers accessing mainframe data. The PC era didn't collapse all computing down to the device level; we layered networks, servers, and services on top.
The architectural reality is that most complex organizations will adopt a hybrid approach. Some workflows will indeed benefit from simplified, first-principles redesigns. A new startup, unconstrained by legacy systems, might architect everything from scratch for agent-first operations. But existing organizations with significant investments in systems of record—whether SAP, Oracle, or custom-built platforms—will not wholesale replace those systems. Instead, they will layer new agent-friendly interfaces, APIs, and abstractions on top.
This creates an interesting middle ground: agents will eventually force vendors to make systems more agent-friendly, but they won't eliminate the existing systems entirely. The trajectory is more likely to be incremental modernization than revolutionary replacement.
One example illustrates this well: Box's recent rollout of an official command-line interface combined with Claude Code creates a powerful agent-friendly surface. Yet it doesn't eliminate Box's existing web UI or API—it adds to the ecosystem. The agents using the CLI are powerful, but Box still maintains its human-facing interface, its business logic, its access controls, and its architectural layers. The layers compound rather than collapse.
The Economics of Agent Labor: Micropayments, Monetization, and Market Creation
Underlying the entire agent revolution is a fundamental economic shift: for the first time in history, machines can perform discrete units of valuable work at near-zero marginal cost.
This creates a bizarre market dynamic. Throughout computing history, humans have assumed that certain classes of work should command premium pricing because they require expertise, effort, or scarce resources. Medical research papers cost money to access. Financial databases cost thousands of dollars annually. Specialized software tools cost hundreds per month.
Yet there is vastly more valuable information and software in the world than humans will ever consume at current pricing levels. A researcher might want access to 10,000 medical papers to find the five most relevant, but at $25 per paper, the cost is prohibitive. A data analyst might want to query a specialized database 1,000 times to find the perfect dataset, but at standard pricing, that's financially irrational.
Enter agents. Give an agent a budget and a protocol for making micropauses, and suddenly that researcher can afford to access all 10,000 papers. That analyst can afford 1,000 database queries. The economics of previously underutilized information invert: instead of restricting access through high pricing, vendors can enable unlimited access through low per-unit pricing, capturing value through aggregate volume.
This represents a potential 100x expansion in the addressable market for certain categories of information and services. There is so much latent economic value in information that is essentially worthless at human-relevant price points but enormously valuable if made available at machine-relevant price points.
The challenge is that financial markets and Wall Street analysts struggle with this economic model. They're trained to view markets as essentially fixed in size: if the CRM market is worth $2 billion, then moving CRM to the cloud doesn't change the total market size—it just shifts where that $2 billion is spent. This was the wrong intuition with cloud, and it's wrong again with agents.
When Salesforce launched, the CRM market was approximately $2 billion annually. That $2 billion reflected the economics of deploying CRM systems: massive upfront licensing costs, years of consulting-driven implementation, expensive server infrastructure, ongoing Oracle licensing fees. When Salesforce moved to SaaS and per-seat pricing, skeptics thought the same $2 billion pie was simply being redistributed. Instead, the total market grew by 10x because the friction of CRM deployment essentially vanished.
The same pattern will repeat with agents and AI infrastructure. Wall Street models treat the software licensing market as fixed. They don't consider what happens when software becomes so cheap and frictionless that organizations stop thinking about "implementing a tool" and simply set agents loose with unlimited access. The total consumption of infrastructure, services, and information explodes.
This is precisely what happened in the PC era. Business people in the 1980s viewed PCs as a finite market because they calculated based on consumption of MIPS (million instructions per second). IBM calculated that the world would need X billion MIPS, and then they could estimate the number of computers needed. What they missed entirely: when MIPS became cheap and ubiquitous, demand didn't stay fixed—it expanded 1,000x. Every desktop got a computer, not because demand for computing was infinite, but because supply became cheap enough that the previously incalculable became calculable.
Today, AI infrastructure companies are experiencing precisely this dynamic. Infrastructure providers report that their usage is "asymptotic"—growing exponentially—not because they've suddenly acquired more enterprise customers, but because existing customers are now using infrastructure 10-100x more heavily. The shift from CapEx to OpEx, from constrained computing to elastic computing, unleashes massive new demand that was previously latent.
This will continue until supply constraints ease (more GPUs, better algorithms, on-device compute) and pricing reaches an equilibrium point where wasteful consumption becomes uneconomical. But we're not at that equilibrium yet. We're in the expansion phase where, for the first time, it makes economic sense to ask an AI agent to accomplish tasks that would have been unthinkable just two years ago.
The Split Between Startups and Enterprises: The Pace of Adoption
Perhaps the most interesting dynamic unfolding is the vast capability gap opening between startups and enterprises in agent adoption.
A startup, particularly one in a services category—marketing agencies, engineering consulting, legal services, construction design—can architect its entire operation from first principles for agents. If you're building a new marketing agency and you can give your agent complete context access to all client information, competitor research, marketing assets, and budget data without information barriers, your agency operates completely differently than a traditional firm. Your agents can write software on the fly for specific client needs. They can cross-reference information that would normally be siloed by department. They can move at a pace that's simply impossible with human organizational structures.
This agency might do the work of 50 traditional employees with 10 humans and 10 agents. The ROI is extraordinary, and the cost structure is fundamentally better than incumbents can achieve.
A large enterprise like JPMorgan, meanwhile, faces the exact opposite problem. JPMorgan has 300,000+ employees, legacy systems spanning decades, regulatory requirements that span multiple jurisdictions, and systems of record that encode 30+ years of institutional knowledge. Deploying agents with unconstrained access to JPMorgan's systems is, from a risk perspective, essentially suicidal. The enterprise must move slowly, deliberately, and with extreme caution.
This creates a widening delta. The startups pull further ahead with each passing month, building institutional knowledge about effective agent deployment, developing new business models, and optimizing their cost structures around agent-first operations. The enterprises fall further behind, not because of incompetence, but because the constraints they're operating under are genuinely real.
The irony is that even startups will eventually run into the same problems that constrain enterprises. A young startup might operate in chaos initially, with agents creating new integrations and overwriting data at will, because the startup has nothing important to lose. But as the startup grows and accumulates real assets, real customer data, real financial implications—suddenly, all the security and governance concerns that plagued large enterprises become critical. The startup that moved fast and broke things now has to rebuild governance structures that incumbents have spent decades optimizing.
The gap will persist for years, however. During that time, the startups will capture disproportionate value, build dominant market positions, and establish new norms around what effective agent-driven organizations look like. When enterprises finally develop frameworks to safely deploy agents at scale, they'll find themselves playing catch-up against better-funded, better-optimized, more agent-native competitors.
The Computing Budget Reckoning: Engineering Spend on Tokens and Compute
A quiet crisis is developing in engineering organizations: nobody knows how to budget for AI compute.
Five years ago, engineering budgets were straightforward. You calculated the size of your engineering team and allocated infrastructure budget accordingly. The infrastructure budget was a percentage of total engineering spend, relatively predictable and stable. Today, that model is breaking down.
For the first time in computing history, individual engineers now have the ability to spin up essentially unlimited compute resources on behalf of organizational tasks. An engineer might instruct an agent to run 10 parallel experiments, knowing that 90% of the token consumption will be "wasted" (used by experiments that don't produce winners), but accepting that waste as the cost of faster iteration. Alternatively, an engineer might tell a team to optimize aggressively before launching agents, minimizing token waste but slowing iteration.
These are fundamentally new trade-offs that engineering organizations haven't encountered before, and there are no established norms around how to handle them.
The Wall Street pressure is intensifying the problem. CFOs are being asked to project how much of their annual budget will be consumed by AI tokens. Different analysts give wildly different answers: some suggest 1% of engineering spend should go to tokens, others suggest as high as 100%. The reality is that nobody actually knows. This becomes a make-or-break question for CFO credibility because Wall Street will, eventually, demand an answer and hold management accountable to it.
The implications are staggering for public technology companies. R&D spending is typically between 14-30% of annual revenue for mature tech companies. If AI compute becomes 2x the cost of your entire engineering team, your EPS craters. Alternatively, if you discover that AI compute is only 3% of engineering spend, your profitability improves materially. The difference between these scenarios is the difference between a stock trading at 20x revenue versus 60x revenue.
This mirrors the pattern we've seen with every previous computing technology. When cloud computing first emerged, companies were terrified that OpEx would spiral out of control. Companies had executives literally saying, "We're an agricultural company; we only understand CapEx." Others embraced cloud and shifted everything to OpEx, deliberately, as a strategic move. Eventually, a new normal emerged: some workloads stayed on-premise, some moved to cloud, and the CFO office developed frameworks for making those decisions.
The same evolution will happen with AI compute budgeting. For now, we're in the chaos phase where:
- Startups burn through capital without worrying about token budgets, treating compute as free (which it is, if you're venture-backed)
- Large enterprises freeze because they're terrified of uncontrolled spending
- Mid-market companies make calculated bets, deciding to lead in specific application spaces where they can tolerate higher compute spend to gain competitive advantage
Eventually, the market will discover that agents are efficient enough at particular tasks that the per-unit economics actually work out. Some specific application categories will emerge where the value from agent automation is so high that token budgets become immaterial—like a salesperson paying $3 for research that directly leads to a $100,000 deal. In that case, the agent-driven compute is a trivial cost of goods sold.
Conclusion: The Inevitable Transition to Agent-First Systems
We are in the early stages of a technological shift as fundamental as the transition from mainframes to PCs or from on-premise software to cloud. The indicators are everywhere: product teams allocating equal resources to agent and human interfaces, vendors scrambling to expose APIs, enterprises cautiously deploying pilots, startups moving at revolutionary pace.
The key insight that ties everything together is this: if agents outnumber humans by orders of magnitude, then software architecture must fundamentally invert to serve agents as the primary user. This is not a future state that might occur—it's a logical inevitability given the trajectory of AI capabilities.
The winners in this transition will be those who move thoughtfully but decisively. Startups will dominate the agent-native space initially, but enterprises will eventually develop governance frameworks that allow large-scale agent deployment. Vendors who can reimagine their business models around unlimited agent access will thrive; those clinging to restricted API access will become commoditized. Engineering organizations that develop mature frameworks for budgeting AI compute will extract maximum value from agents without spiraling into chaos.
For individual technologists and business leaders, the moment to act is now. Understand your systems' agent compatibility. Develop governance frameworks before you need them. Experiment with agents in low-risk contexts. Build organizational muscle memory for agent-driven workflows. The organizations that treat agent adoption as a distant future consideration will find themselves surprised by the pace of transition—and paying the price of arriving late to a transformative shift.
The technical capabilities are accelerating. The economic incentives are aligning. The infrastructure is being built. Agent-first software is no longer a theoretical exercise—it's the emerging paradigm that will define the next decade of computing.
Original source: The Era of AI Agents | Aaron Levie on The a16z Show
powered by osmu.app