In 2026, the AI monetization conversation has shifted quickly from one concern to the next. Early in the year, fears that AI agents would erode software seats helped trigger a selloff of software stocks dubbed the “SaaSpocalypse.” Since then, attention has turned to a different disruption, as AI leaders including Anthropic, OpenAI, and GitHub lean heavily on usage-based pricing to better align revenue with the cost of delivering AI.

It would be easy to conclude that software monetization is shifting wholesale from seats and subscriptions to tokens, credits, and consumption. But look across a broader cross-section of the software industry, and a different picture emerges.

Most software companies aren’t AI-native businesses designing pricing from scratch. They have existing products, customers, contracts, and pricing structures. They’re adding AI to portfolios that may already span dozens of products and multiple monetization models. And they have to balance the economics of AI with something customers still value enormously: predictability.

That tension came through clearly in our new Revenera Monetization Monitor: Software and AI Pricing Models and Strategies 2027 report of 415 product and technology leaders at established software producers and intelligent device manufacturers.

Nearly all are adding AI capabilities to at least some products. The way they’re monetizing those capabilities, though, is considerably more pragmatic than the headlines might suggest.

AI features are widespread, but adoption is lagging

AI capabilities have gone mainstream. The share of software producers incorporating AI into their products jumped from 80% last year to 96% today. Getting AI into the product, however, is only the first step.

The widespread use of chatbots can create the impression that everyone is using AI. That isn’t yet true inside established software products. Almost half of respondents say that adoption of their AI features is limited or low.

For many vendors, that makes the next phase less about launching more AI and more about learning from the AI they have already launched.

Seat loss is limited so far, but pricing pressure is real

One of the biggest fears surrounding AI agents is that companies will need fewer software subscriptions, or “seats,” as agents take over work previously done by people. So far, the impact appears relatively small. Only 7% of respondents say they’re experiencing seat loss due to AI.

That doesn’t mean AI isn’t affecting software pricing. Nearly half of software producers report downward pricing pressure related to AI. Some buyers are using the possibility of building their own AI-powered alternatives as leverage in negotiations. At the same time, growing AI budgets are forcing customers to scrutinize what they spend elsewhere in their software portfolios.

The near-term challenge may not be that AI eliminates the seat. It may be that AI changes what customers are willing to pay for it.

Demand for predictable costs is influencing AI pricing

Over the past year, stories of AI bill shock have become increasingly common. Consumption-based pricing may closely reflect underlying AI costs, but customers don’t necessarily want a bill that changes dramatically from month to month.

That trade-off shows up clearly in the research. Software producers are almost three times more likely to prioritize cost predictability for customers than maximizing near-term revenue. And that preference is reflected in how companies are pricing AI today.

The three most common approaches are putting AI in a higher-priced subscription tier, including it at no additional charge, and using hybrid models that combine a subscription with some form of usage-based or outcome-based models.

What’s striking is that established software companies aren’t rushing toward pure consumption pricing. Over the next 18 months, they expect predictability-oriented approaches to grow faster than pure usage-based models.

AI revenue isn’t automatically translating into AI profit

The economics of AI have become almost as important as the capabilities themselves. For AI-native companies, much of the discussion has centered on the enormous infrastructure costs required to train and run models. Established software vendors face a somewhat different challenge: they are adding those new costs to businesses that already have existing products, architectures, and margin expectations.

Our research includes companies delivering software across SaaS, on-premises, embedded, edge, and other environments. Many are seeing revenue growth from AI, and more than half report improved profitability.

That doesn’t mean the economics are easy. Increased AI delivery costs and cloud costs rank among the biggest barriers to growing annual recurring revenue. So does the inability to implement new monetization models quickly enough.

This is an important distinction. AI can generate incremental revenue and still create margin pressure at the same time.

For product and business leaders, the question is no longer simply, “Can we charge for AI?” It is increasingly, “Can we charge for AI in a way that supports sustainable economics?”

Source: Revenera

Limited usage data is making AI pricing harder

There’s another problem that gets less attention: many companies still don’t have the data they need to make good pricing decisions. A large share of organizations either lack clear visibility into how customers use AI features or rely on manual analysis and engineering work to get that information.

That creates a fundamental problem. If you don’t know who is using a feature, how often they use it, or which capabilities drive value, it’s very difficult to know what metric to price against. It’s also harder to distinguish between an AI feature that customers don’t value and one that simply hasn’t been packaged or introduced effectively.

Usage data isn’t just a billing requirement for consumption pricing. It’s increasingly an input into product strategy, packaging, and monetization.

Source: Revenera

2027 outlook: AI monetization will be evolutionary, not revolutionary

There is no single right way to price AI. The approaches taken by AI-native companies have understandably dominated the conversation in 2026. Established software companies, though, are operating under very different constraints. They aren’t replacing their businesses with a new AI pricing model. They are figuring out how AI fits into products and commercial models that already exist.

In practice, I think many companies will move through this process in stages. They may begin by including AI at no additional charge while they build adoption and learn how customers use it. As value becomes clearer, they can move capabilities into higher-priced tiers, often with usage limits that protect against runaway costs. Once usage patterns become more predictable, some will adopt hybrid models that combine a recurring subscription with bundled consumption and transparent pricing for additional usage.

Not every product will move through those stages at the same pace. A mature AI capability in one product may already be ready for usage-based pricing while a newly launched feature somewhere else in the portfolio is still focused entirely on adoption.

That is why I don’t think the winners in AI monetization will be the companies that pick the “right” pricing model today. The advantage will come from being able to keep changing it.

This advantage starts with better visibility into how customers use software, where they find value, and which capabilities actually drive engagement. Companies that can turn those insights into changes in pricing, packaging, and product strategy will be in a much better position to adapt as both AI technology and customer expectations continue to evolve.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

The original Antigravity was an IDE with native integration for Google’s generative AI models. With Antigravity 2, Google offers a refashioned version of the product that it describes as a “standalone desktop command center” for agents.

Antigravity 2 is closer to projects like LM Studio than a full-blown IDE. It provides a streamlined, chat-centric interface for working with models and agents, uncluttered by a code editor, debugging tools, and other trappings of an integrated development environment. For those who want an IDE and agent orchestration together, Google still offers the Antigravity IDE (read our hands-on look). But for those who want a chat-centric desktop app experience, or who want to keep their hands-on development separate from their vibe coding, Google has elected to also offer this IDE-less version of Antigravity.

When you launch the Antigravity app and start a new task, you have a few choices about how to manage your work. If you just want to have a quick conversation and don’t need to create a whole project to go with it, you can select “No Project” and just start prompting. If you do create a project, you can either configure the details yourself — what directory to use, what to call it — or have Antigravity set a randomly generated name and empty directory for starters.

Projects and worktrees

Earlier versions of Antigravity had the concept of workspaces, which were confined to a single directory and lacked granular permissions or customizations. With Antigravity 2.0, workspaces are replaced by projects, which may span multiple directories (that you define explicitly) and have their own isolated settings and permissions. This new scheme better accommodates how many software projects work, especially those with shared components living in different places.

Another new option is local mode vs. worktree mode, which controls how agents interact with your project’s directories. It’s another example of how the Antigravity app lets you choose between the quick-and-dirty or slow-but-correct way of doing things. Local mode has the agent working directly on local folders or Git checkouts, for convenience and speed. The new worktree mode creates a new Git worktree for each conversation, so that the active working folder won’t be affected and work done by any subagents running in parallel won’t conflict.

Agent commands

By default agents come with several common control commands, prefixed with a slash:

• /btw lets you interject with a quick question that makes use of the current context, but without derailing the workflow.
• /grill-me has the agent prompt you with a few specific, focused questions about the project to better guide its responses. For instance, during a conversation about creating a templating system for a blogging engine, /grill-me produced questions like “What is the primary goal you want to achieve with your program?” and presented several different options, along with a fill-in-the-blank option.

One thing to be wary of with these command operations is API timeouts. When I was using /grill-me, the API for the service timed out and the context for the grilling vanished and couldn’t be recovered.

Build with Google bundles

The Antigravity app also includes bundles of agent skills and capabilities for building with various Google services and technology stacks. For instance, the modern web guidance bundle provides agent skills and guidelines for building web apps with best practices and broad browser compatibility. The Android CLI bundle gives agents tools and guidelines for building Android apps, or refreshing older Android apps or their components. Most intriguing of the bunch, if maybe also the most esoteric, is the Google DeepMind science skills collection for doing scientific research with Antigravity.

There is growing interest in speeding up agentic development through parallelism — for instance, by having multiple agents analyze different aspects of a project in parallel and report their results independently. Antigravity gives you a couple of complementary ways to do this. One is subagents, which are spawned by the main agent and work on a specific task in their own isolated workspace. Another is to run agents or subagents asynchronously as a background process, so you and the main agent can continue working without waiting for them to complete.

The biggest limitation of Antigravity, which I’m betting is by design, is that it doesn’t let you use any models besides versions of Gemini, Claude, and GPT. There is no mechanism for connecting Antigravity to a self-hosted model with an industry-standard interface. For that you will want a product like LM Studio.

This series lays out a practical framework for taking generative AI (GenAI) from pilots to dependable production systems in the enterprise. It focuses on four disciplines that determine long-term success: engineering for scale and reliability, designing agentic systems with clear constraints, embedding governance directly into build and runtime controls, and measuring ROI at the workflow level with full cost and outcome visibility. The throughline is operational discipline—treating GenAI as a service with contracts, evaluation, ownership, and measurable business impact.

Post 1: Enterprise GenAI at scale

The first article in the series, “How to run enterprise generative AI like a production service,” focuses on operations. It explains why reliability, retrieval quality, latency control, cost routing, observability, and evaluation harnesses determine success at scale. The article lays out a practical architecture and operational checklist so teams can move from promising demos to stable, supportable systems.

Post 2: Agentic AI in the enterprise

The second article, “Agentic AI in the enterprise: How to balance autonomy with constraints,” defines what an agentic system is and how to operate one safely. It introduces the agent loop (plan, act, verify, commit), tool contracts, policy enforcement, durable state, and verification gates. The emphasis is on constrained autonomy, traceability, and operational ownership so agents can execute real workflows under enterprise controls.

Post 3: Governance by design

The third article, “Governance by design: Turning AI policy into executable controls,” treats AI governance as engineering work. It describes how to translate policy into executable controls in continuous integration pipelines and runtime enforcement layers. Topics include threat modeling, policy-as-code, lineage, audit evidence, and feedback loops. The goal is steady delivery under measurable guardrails.

Post 4: AI ROI beyond pilots

The final article, “AI ROI beyond pilots: Measuring outcomes in production,” addresses how to measure real business value from GenAI. It defines ROI at the workflow level, accounts for full life-cycle costs, and connects usage metrics to operational outcomes. It provides a metrics stack, cost equation, cohort rollout strategy, and a 90-day plan to produce credible, production-grade ROI signals.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Most teams building AI agents are pouring effort into better memory, longer context windows, conversation summaries, retrieval systems that pull up anything the agent has ever seen. These are useful tools. But they do not solve the problem of knowing whether an action actually completed. Memory tells an agent what happened. It doesn’t tell the agent what’s true right now. And for any agent that takes real action — refunding money, changing an order, updating an account — that distinction is the whole ballgame.

Memory can remember a request without knowing the outcome

Picture a customer service agent that approves a refund. The refund actually goes through, but the confirmation response times out before the agent hears back. From the agent’s point of view, all it has is a record of a request it made, not proof of what happened next. If the agent trusts its own memory, it sees an unfinished task and tries again. The reasoning is sound. The second refund is still wrong.

More conversation history doesn’t fix this. What the agent needs is a record it can trust: the request ID, the current status, the confirmed outcome. Memory can tell you what the customer asked for. It can’t tell you what another system actually did. This isn’t a new problem; recommendation systems ran into a version of it years before agents existed.

A prediction is not the same as current intent

I spent several years building recommendation and personalization systems, and one thing became clear fast: more history doesn’t automatically mean a better decision. A recommender looks at what someone bought, browsed, or listened to, finds a pattern and predicts what they’ll want next. These are all informed guesses rather than facts. I saw this play out around election season. A customer buys several books about a candidate or a political topic and the system, correctly, learns that as an interest. Weeks later, the election is over and the customer has moved on, but their purchase history hasn’t changed. The purchase history is still accurate. It just no longer reflects the customer’s current intent. So, customer data changes with each interaction, so recommendations need to respond to new information.

Freshness in a large-scale personalization system

Early in a real-time personalization platform I worked on, one of the hardest problems wasn’t traffic volume; it was freshness. A customer’s inferred interests could lag well behind their actual recent behavior, so the system would keep confidently recommending things that no longer matched what the person wanted. We rebuilt the pipeline so that signal updates reflected recent behavior almost immediately instead of with a long delay. That gap between what the system knows and what’s currently true is small when you’re recommending a book. It’s a much bigger problem once you move from recommending content to an agent that’s authorized to act on someone’s behalf. Consider a customer who has just started a trial and is eligible for a $0 first-item offer. Personalization should show that available benefit instead of another invitation to start a trial. A fresh eligibility signal lets it change the next offer. Unlike inferred interests, trial eligibility is a recorded fact.

Stale data can produce a bad recommendation. Stale data acted on by an autonomous agent can produce a real-world mistake. Agents need more than memory; they need a reliable state.

Reliable state tells the agent what’s true right now

Reliable state is a verified record of a specific operational fact. In the refund example, the conversation records what the customer requested. The payment system records whether the refund happened. The order system records the order’s status, while current policy and permission records determine whether the action is allowed. Each fact has its own authoritative source. State can itself become stale, so the agent must check the relevant source rather than rely on its memory of an earlier answer.

This matters even after the “yes/no” check passes. A customer might withdraw permission mid-process. An order might fall outside the window where changes are allowed. And even when every check passes, the action itself can still fail partway through, so the agent also needs a safe way to retry without duplicating the damage. The action system must enforce current permissions and other preconditions when it executes, because they can change after an earlier check.

Designing a privacy-request architecture

In privacy and compliance architecture work I’ve done, a single customer request, like asking to delete their data, can trigger a long chain of downstream effects across many internal systems. The challenge wasn’t any one system doing its job correctly; it was making sure there was one authoritative, centralized place that recorded whether the overall request had actually been completed, rather than each system independently assuming it had. That’s the same principle an agent needs: a system of record it defers to, rather than trusting its own memory of what it asked for.

A few categories of tooling exist specifically to solve different slices of this “what’s true right now” problem:

• Business state/workflow databases, Postgres, DynamoDB, Spanner, Cosmos DB.
• Workflow orchestration, Temporal, AWS Step Functions, Azure Durable Functions.
• Agent state, tools like LangGraph checkpoints.
• Session/cache state, Redis, Memcached.
• Event history, Kafka and similar streaming systems.
• Permission state, Open Policy Agent, Amazon Verified Permissions.

None of these replace the others. A production agent usually needs several of them working together, which raises the next question: what happens when an action only partly succeeds?

Safe actions need a receipt and a recovery plan

Every important action an agent takes should carry a unique identifier, like a receipt number. If the response gets lost, the agent must reuse that ID for the same intended operation. The receiving system must recognize the ID and prevent the operation from being applied twice, within its supported deduplication window. This is how an idempotent API makes retries safe; attaching an ID alone is not enough. A preliminary status check cannot prevent two concurrent requests from executing the same action. The AWS Builders’ Library explains this design in Making retries safe with idempotent APIs.

Teams also need reconciliation, regularly comparing what the agent believes happened against what the system of record actually shows, the same way you’d check a receipt against a bank statement. When they disagree, someone needs a clear next step: recheck, reverse the action, or escalate to a human. None of this works without clear ownership.

Reconciliation at high transaction volume

In large-scale commerce infrastructure work, we treated “did this transaction actually complete” as something that could never be answered from memory or assumption, at high volume, even a small rate of unconfirmed or duplicated actions adds up to real customer impact. We built reconciliation directly into the system so that what one part of the pipeline believed had happened was continuously checked against what was actually recorded, with idempotency built in to prevent retries from creating duplicate transactions. The lesson generalizes directly to agents: never let an action retry blindly without checking a source of truth first.

Before you give an agent more autonomy, decide who owns each critical fact and who’s responsible for cleanup when something breaks, because something eventually will.

Monitor the decision, not just the model

All of this changes what a team should actually be watching. Latency, cost and model accuracy matter, but none of those metrics will tell you that an agent acted on a stale permission or announced a refund that never happened. For each consequential decision, trace the information used, its freshness, the rules checked, the attempted action and the confirmed result. What you actually want to be able to trace is:

• what information the agent used
• when that information was last updated
• which rules were checked before acting
• what action was actually attempted
• what result was recorded afterward

As a leader, the job isn’t just watching model quality; it’s making sure every piece of information an agent acts on has a clear source and a way to verify it’s current. Agents are genuinely good at interpreting messy, ambiguous situations and deciding what to do. But they shouldn’t be the record of truth themselves. That job still belongs to the systems built to hold it.

Memory tells an agent what happened. Reliable state tells it what’s true now, and whether it’s safe to act.