What Is a Digital Employee?

A Job You Can Describe

A digital employee might answer customer questions about an order or follow up on a sales inquiry. The business gives it a defined role, along with the information and tools to carry out that work.

The term is used loosely. For the AI agents discussed here, the useful questions are practical: what work can it finish, which systems can it use, and when does it need a person? A name and a chat window tell you very little about that.

A Customer Emails About a Late Order

Imagine you give a support agent access to order status and your delivery policies. A customer asks where a package is. The agent reads the email, looks up the order, and drafts an answer using the latest tracking information. Your application can require a person to approve that draft before the reply is sent.

Now suppose the customer wants a refund. If the agent has no permission to issue one, it should pass the request to your support team. You build and test that handoff. The same applies when tracking is missing or the customer's question doesn't match the records.

This is an example of a workflow you could build. Its reliability depends on the information, permissions, and exception handling you put around the agent.

See the customer-support example

How Is That Different From a Chatbot?

The categories overlap. A chatbot describes a way to have a conversation; some chatbots can also look up records and take actions. Digital employee describes the role you give the software in your business.

Look past the label. Can it check an order, prepare a reply, and route an exception to the right person? Does it have to wait for approval? Those details matter more than whether a vendor calls it a chatbot, an assistant, or an employee.

Why Digital Employees Need Identities

A customer needs an address to reply to. A supplier needs a number to call back. Your team needs to know which agent handled a conversation. Once an agent works outside a chat window, those details become part of the setup.

An agent's identity has several parts. An internal ID identifies a record in your software. Permissions determine what the agent can access. A communication identity gives it an email address and phone number. These serve different purposes; an address alone does not grant access to business systems.

Mailrun's Agent Identities provide that communication identity. The address and number stay with the identity in Mailrun when you replace the agent behind them. Your team still has to reconnect its tools, move any context it needs, and test the new setup.

Learn how agent identities work

What Mailrun Provides

Bring the AI agent you want to use. Mailrun provides the agent's email and phone channels through an HTTP API for your application or Model Context Protocol (MCP) tools for compatible agent software. Your team supplies the agent's instructions, business knowledge, and access to systems such as your help desk or calendar.

After your integration confirms that the mailbox is ready, it can send email and read incoming mail. A message accepted for sending has not necessarily been delivered. Answering incoming calls requires a voice agent you host. Mailrun does not supply a ready-made employee or automatically connect it to your customer records.

Read the agent mail guide

Start With One Task

Choose a task where you can check the result. Give the agent only the access it needs, try it with messages you control, and review what it does when information is missing. Decide who receives an exception before customers start relying on it.

Set a daily sending cap for each identity to limit email volume. That cap does not tell you whether an answer is correct. Keep a person responsible for the workflow and expand it only after you've seen it handle the cases that matter to your business.

Access to Agent Identities is coming soon. Request Access and tell us what you want your agent to do. The form goes to our team; it does not create an account or start a subscription.

See how to connect an agent to Mailrun