Techaisle Analyst Insights

Google's Gemini at Work announcements put one agent, called Gemini, behind every surface a company uses. The agent is meant to be given an outcome rather than instructions, and to return finished work, running across a company's tools and systems for hours or days when the job needs it. Google also separated the agent from the model running underneath, so Gemini can hand a step to Anthropic's Claude when Claude is better suited, with other private and open models to follow. Google is competing on identity, policy, memory, and cost control, and treating the model as a part it is prepared to source from a rival.

For firms with 1 to 10,000 employees, the market Techaisle tracks, model quality is rarely what holds agents back. The harder questions are whether agents stay affordable once usage scales, whether the CISO will let them run, and who will operate them, and Google's launch speaks to those more directly than its enterprise customer stories suggest.

Lock-in moves from the model to the context

Model leadership changes hands several times a year, and few customers want to rebuild their agents each time it does. Gemini's model choice addresses that risk: the agent picks the model for each step, today from Google's own Gemini family or Anthropic's Claude, with other models to follow. Google owns one of the best model families and still built Gemini so customers can choose another. That is a confident bet on the agent, and it works because the switching cost has moved to what the agent knows.

Google is connecting Gemini to its Knowledge Catalog, an existing Google Cloud service, so that every agent works from the company's own business definitions. The catalog holds one agreed definition for each business term and reads metrics from the systems where the company already maintains them. Gemini's memory runs from the task at hand to a record of how the organization does its work, and the agent writes some of its own skills as it goes. After a year of use, that body of definitions, history, and skills is far harder to move than a model is to swap.

On July 22, 2026, IBM told investors it is accelerating changes to its go-to-market model to expand sales coverage across thousands of additional clients where its portfolio is highly relevant and wallet share is available. It paired that with an investment in specialized technical and client-facing talent, including Forward Deployed Engineers. Arvind Krishna has been circling this idea for several quarters. He calls it the long tail. Read against firmographics, the long tail is the midmarket, with the upper band of small business attached to it.

Techaisle sizes worldwide IT spending by firms with 1 to 4,999 employees at US$1.667 trillion in 2026, with services taking the majority. This is the primary driver of commercial IT growth globally. It is also the market IBM has historically reached through partners, priced for enterprises, and packaged for buyers who employ platform teams.

Whether IBM wants this segment is settled. It has said so plainly and has now moved headcount and compensation to back it up. What remains open is which parts of a portfolio assembled across two decades of enterprise engineering can be consumed by a firm with 400 employees, 6 people in IT, and no platform team.

The Absorption Test

A product fits the long tail when it absorbs operating complexity instead of offloading it onto a team the buyer does not have.

IBM has made a version of this case itself. Rob Thomas, IBM's Chief Commercial Officer, has framed the central AI question as how you operate AI across everything you already have, and calls the approach an AI operating model. He is describing enterprises. The same logic binds harder one tier down, where there is no one to do the operating.

Most enterprise software fails this test in three ways. It needs a standing platform team to run, a configuration project before the buyer sees any value, and a procurement cycle longer than the payback window a midmarket CFO will tolerate. Any one of those is disqualifying. The configuration project is the quiet one, because it arrives as a budget line nobody planned for.

All three assume an IT organization with people to spare. The midmarket carries enterprise-shaped problems on a small-business-shaped bench. Techaisle’s SMB and Midmarket Datacenter Solutions Adoption Trends study, 2026, N=2,857, puts the execution constraint at 85% for talent and 65% for facilities, with 88% of firms reporting a partner expertise deficit. Techaisle’s GenAI adoption research finds 37% to 45% of midsized firms still inside Pilot Purgatory, funded and committed but unable to reach production. Midmarket organizations are allocating 17% of IT budgets to GenAI and planning a 27% increase, so the constraint is not money.

A customer stranded at a rental counter after a late flight calls for help and reaches a phone tree built to keep her away from a person for as long as it can. Press one. Press two. That system is not broken. It is working exactly as designed, because for 30 years the design goal of customer service was to reduce how often anyone reached a human, and the human was the expensive part. The same constraint shaped three other functions. Supply chain teams worked only the deviations they had hands for. Recruiters read only the resumes they had time for. Care teams followed up with only the patients they could reach. In each case the limit was the cost of a person, and in each case the work that did not get done was invisible to the company failing to do it.

The contact center is the only function in a company that measures itself on how often it avoids its own work. Deflection rate counts how often customers are kept out of a live conversation. Containment rate counts how often they are held inside a self-service loop. Both metrics were rational under the old cost structure. Amazon Connect Customer treats them as the wrong measures and replaces them with a single question: whether the customer’s problem was solved.

Depending on geography, between 7% and 12% of SMB and midmarket buyers use a cloud marketplace to discover software. The rest arrive at AWS Marketplace, or at any of its competitors, already decided. A partner or an ISV brings them, and they transact there for contract consolidation, committed-spend drawdown, and procurement governance rather than for anything resembling search.

Call it the Discovery Deficit. Cloud marketplaces have functioned as procurement rails, not demand engines. They close deals that were originated somewhere else, by someone else, usually a partner.

That gap is why the AWS Marketplace agentic procurement announcements matter, and it is also why most coverage is aimed at the wrong question. Whether AI improves marketplace search is not interesting. Whether a marketplace that has never originated demand in the smaller segments can begin to do so, once the buyer stops being a person typing keywords, is a different question entirely, with different consequences for everyone downstream.

Three changes, and what each one is actually buying

AWS Marketplace has made three structural changes that are easy to read as feature releases. Read against the Discovery Deficit, each is doing something more specific.

The first is the replacement of lexical search with conversational discovery. Agent Mode, launched at re:Invent 2025, lets a buyer describe a requirement in natural language, upload an RFP or a requirements document, and receive ranked recommendations with side-by-side comparisons. Conversational search converts better than keyword search, which is unsurprising. The more important change is in what the interface is for. A keyword catalog fulfills a decision the buyer already made, and works only for someone who knows what to type. A conversational one helps make the decision, and deciding is the step SMB and midmarket buyers have always outsourced, because they have no procurement function to run comparative analysis internally. That is also why so few of them discover software in a marketplace: a catalog that cannot help you decide is little use to someone who cannot decide alone.

The second is building for machines to read rather than people. Most web pages assemble themselves in the browser, so a crawler or an agent that arrives sees almost nothing. AWS builds Marketplace pages to arrive complete, which means an agent reading one gets the whole listing. It has also opened the catalog to direct queries through an MCP server, so a buyer's own AI assistant can ask it questions without visiting a page at all. Most platforms building AI discovery are building a destination and trying to keep the buyer inside it. AWS is doing close to the opposite, and that choice says more about the strategy than anything else in the set. Making the catalog legible to agents AWS does not own is a distribution choice rather than an experience choice, and it concedes that the buyer's first conversation about software will happen somewhere else. The competitive unit shifts accordingly, from whose marketplace interface is best to whose catalog is most readable by someone else's agent.

The third is the automation of the transaction, which arrives from two directions at once. Express Private Offers let a seller define rate cards, discount tiers, volume breaks, and qualification criteria in advance, so an offer can be generated and accepted without a human negotiating it, which lowers the cost of serving a small software deal. All of this aims at deals neither AWS nor its partners could previously work economically, which are the same deals where the Discovery Deficit lives.

Individually these read as product announcements; together they describe a platform trying to convert itself from a procurement rail into a demand engine, which is a considerably harder thing to be.

The Composed Shelf