Introducing TekMail: Email Infrastructure for AI Agents

AI agents are beginning to do work that leaves the chat window. They research vendors, coordinate schedules, follow up on open questions, prepare reports, and communicate with customers and partners.

Sooner or later, that work reaches email.

The obvious shortcut is to connect an agent to a person’s Gmail or Outlook account. That can be useful when the software is assisting that person inside an existing mailbox. It is a poor foundation when the software itself needs an identity.

That is why we built TekMail: email infrastructure that gives every AI agent a real inbox while keeping enforceable policy and human oversight at the mail boundary.

An agent needs an identity, not borrowed credentials

A machine-owned mailbox should be treated differently from a human inbox.

The agent needs an address that belongs to its role, credentials scoped only to that identity, and a durable history that remains intact when the model or client changes. A research agent should not inherit access to the support agent’s conversations. Replacing one runtime with another should not mean recreating the mailbox, rules, and audit trail.

TekMail provisions each agent independently. The agent can send and receive through a REST API or hosted MCP connection, while the organization retains control of the identity and its operating rules.

This distinction sounds small. Operationally, it changes everything.

The safety boundary belongs outside the model

We believe prompts are useful instructions, not security controls.

You can ask a model not to email unknown recipients. You can tell it never to send confidential information. You can instruct it to stop when a message looks suspicious. Those instructions matter, but they are still interpreted by the same probabilistic system doing the work.

The durable boundary needs to live somewhere the model cannot negotiate with it.

TekMail puts permissions, rate limits, allowlists, approval rules, content policies, suppression checks, and quarantine decisions in the mail layer. The agent can draft a message, but the infrastructure decides whether that message is allowed to leave.

That separation lets teams grant useful autonomy without pretending every action carries the same risk.

Human review should be deliberate, not universal

Requiring approval for every message is safe, but it can also turn automation into another inbox people have to babysit.

TekMail supports different operating modes because different messages carry different consequences. A low-risk internal notification may be allowed to send immediately. A customer-facing message may need a short undo window. A new recipient, unusual content, or elevated risk signal may require explicit approval. Suspicious inbound mail may be flagged or quarantined before an agent ever sees it.

The goal is not to put a person in front of every action. The goal is to put a person at the decisions where judgment matters.

What we actually had to build

The visible approval queue is only one surface. The less visible work is what makes the product trustworthy enough to operate:

• isolated identities and scoped, revocable API keys
• authenticated sending domains and custom-domain verification
• reliable inbound processing, threading, attachments, and search
• idempotent delivery and durable background jobs
• suppression, bounce, complaint, and rate-limit handling
• organization-level policy with per-agent exceptions
• audit history across sent, received, queued, blocked, and failed mail
• billing and entitlement enforcement that cannot be bypassed by the client

This is the part of product development that rarely fits in a launch screenshot. It is also the difference between a polished prototype and infrastructure another system can depend on.

One inbox across agent runtimes

Agent tools will keep changing. The identity should not have to.

A TekMail agent can connect from Codex, Claude Code, an automation platform, or a custom runtime through hosted MCP or the REST API. Changing the client does not replace the inbox. The address, permissions, history, and organization policy remain with the agent.

That gives the organization a stable control plane while the intelligence on the other side continues to evolve.

Where TekMail is today

TekMail is deployed and in launch-candidate hardening. We are using this period to test the operational edges: deliverability, policy behavior, abuse controls, billing, recovery, and the failure paths that do not show up in a happy-path demo.

We are being deliberate about that language. Email infrastructure is not finished when the interface looks good. It is ready when the system behaves predictably under real conditions, including the conditions we would rather never see.

You can see the product at TekMail.app and read the deeper TekMail build story.

What comes next

The immediate job is simple to describe: give software a trustworthy way to communicate without giving up human control.

The longer-term opportunity is broader. Humans and agents increasingly share the same workflows. They need communication infrastructure that understands both kinds of participants, gives each the right permissions, and keeps the organization—not a model or a mailbox provider—in charge of the boundary.

That is the system we are building.

Related

• TekMail case study — the product architecture, approval model, and screens in context.
• AI Agents Need Context, Not Hype — why useful agent systems start with permissions, context, and review.
• AI Workflow Automation — how HiTek approaches governed AI inside real business workflows.