When teams plan an AI agent that can use email, the argument is almost always about sending. Should it be allowed to reply on its own? To whom? With what checks? On 27 October 2026 Hostinger published fourteen weeks of usage data from its own product that suggests a different place to put the effort.
What the data covers
The numbers come from Agentic Mail, Hostinger's email service for AI agents, which it says "launched at the end of May 2026" and which lets "small businesses, developers, and individuals connect the AI agent of their choice to a mailbox". Hostinger analysed about 213 million agent actions over fourteen weeks, 13 July to 18 October 2026. An "action" is one API call: listing an inbox, searching, opening a message, sending one.
So this is one vendor's data about its own product and its own users, in general-purpose email. It's a useful look at how agents behave in one real setting, not a measurement of all AI agents everywhere.
What the agents actually did
- Sending was rare. "Only 2.5% of them were email sends." In the latest three weeks, sends were about 2% of actions.
- Reading dominated. Searching and reading messages were at least 45% of all actions. Counting every inbox listing as reading pushes that to 83%. Hostinger reports a range because some listings are agents repeatedly checking for new mail, and it can't yet separate those out. Even the conservative figure is about 18 information-gathering actions for every email sent.
- Destructive actions were rarer still. About 22,000 deletes against 5.4 million sends, which Hostinger puts at "roughly one delete for every 250 emails sent."
- Most agents still poll. Webhooks, which tell an agent when new mail arrives, were 0.15% of actions. Most agents keep checking instead.
One caution Hostinger adds itself: a single task, like replying to one person, "can involve a dozen or more actions." So 2.5% is a share of actions, not a measure of how useful the agents were. It says the work is read-heavy, not that agents rarely help.
What that means when you design an agent integration
The capability teams argue about most, sending, was the smallest slice of what these agents did. That has some practical consequences:
- Guarding the rare action is cheap. If sends are a few percent of activity, a confirmation step, a daily send limit or a separate send permission adds little friction. The same goes for delete: if it's that rare, consider making it a move to trash, or leaving it out.
- Reading is where the volume and the exposure are. An agent that reads every message can surface anything in that mailbox. Scope which folders and senders it can read, and log reads, not just sends.
- Plan capacity and cost for the read path. Rate limits, API quotas and model costs will be driven by the dozens of reads behind each task, not by the occasional send.
- Prefer push over polling where it's available. An agent that checks the inbox on a loop generates a lot of calls that do nothing. A webhook or similar notification avoids most of them.
- Audit at the task level. Because one request becomes many API calls, logs that group actions by the task that caused them are far easier to review than a flat list of calls.
None of this says sending doesn't matter. A single wrong email can do more damage than a thousand reads. The point is about proportion: put strong, cheap guards on the rare dangerous action, and put real engineering attention on the path that carries most of the traffic. That's a related but different point from the one in our earlier post, The Tools Got Brilliant, The Bugs Stayed Boring.
Source: Hostinger, "We analyzed 213 million AI email actions. Only 2.5% were sends" (published 27 October 2026, read 28 October 2026). Figures are Hostinger's, from its own product's telemetry, and rounded as published.