Email Integration

Email your runner like a colleague — the reply comes back in the same thread.

Give a runner its own email address, then email it — or forward it a thread — and its answer arrives as a reply on the same thread. It is the lowest-friction way to reach a runner from anywhere, including from a phone.

Set it up

1. Turn email on

An owner or admin enables email for the team and picks a default runner. Everyone on the team then sees the same enabled state, the same default runner, and each runner's address. A non-admin sees that email isn't enabled yet and is not shown a control to enable it.

Email also depends on a one-time, server-side mail routing step for your deployment. If that isn't in place, Evident says plainly that email isn't configured on the server, and shows no switch — because it can't be turned on from the product.

2. Add a named connector

Addresses come from named connectors, which you add on the runner's own page. Type just a suffix — support, say — and Evident composes the address; your team's prefix is fixed and shown next to the input: 

agent+{proxy_slug}+{org_mini_id}-support@evident.run

You can copy it straight from the runner's page. Each connector can use its own OpenCode agent and model, so support and oncall can behave quite differently on the same runner. A slug may use lowercase letters, digits and hyphens, must be unique on that runner, and is fixed once created — the name, agent and model stay editable, but the address never changes under you.

There is no default inbox. A runner's plain address with no connector tag does not route anywhere — no conversation is started, and no reply is sent. You need at least one named connector before email reaches your runner.

3. Decide who may write to it

An email reaches the runner only if the sender is one of:

  • Someone on the runner's team, emailing from the address on their Evident account.
  • An address an admin allowlisted on that connector. Their conversations are attributed to that email address, without impersonating an Evident user.

Allowlists are per connector, not per runner or per team: an address allowed on support cannot trigger oncall. Non-admins can see how many addresses may trigger each connector, but not change them.

Who gets ignored, and how

  • An unrecognised sender is dropped, and told once how to use the address with their Evident account. The runner never receives the message.
  • A message that fails sender authentication is dropped with no reply at all — replying would send mail to whoever's address was forged. Allowlisting does not override this: an allowlisted address that fails authentication is still dropped.
  • An unknown or disabled connector, and an address with no runner behind it, do nothing — silently, with no "set up a runner" bounce.

Working over email

  • The reply lands in the same thread and keeps your original subject, so it threads properly in your mail client. It carries a small "View in Evident" link to open the conversation in the chat.
  • Replying continues the conversation rather than starting a new one. A brand-new email starts fresh, and never carries context over from your other threads.
  • Forwarding works. Forward a thread and ask for a summary; the forwarded content comes through as context.
  • Formatting survives. Bold text, links, lists and tables render as formatted email, not raw markup.
  • Failures are emailed, not swallowed. If a turn fails you get a reply saying so, with a link to open the conversation.

Attachments

Images are passed to the runner when its model can accept them. Anything left out is always explained in the reply — whether the model can't take images, the image couldn't be stored, or there were too many or unsupported attachments. Nothing is dropped silently.

Questions and permissions

If the runner has a question, or needs permission, you get an email linking to the conversation — but you answer in the runner's chat, not by email. There are no answer choices inside the email. While it waits, no "done" email is sent; the turn finishes once you have answered. Repeated requests for the same input send one notice.

Keeping an eye on it

Each connector lists its recent emails on the runner's page, newest first, showing who each was from, when it was processed, and whether it was handled, dropped or failed — with the reason when it wasn't handled. You can open the session that handled an email to see exactly what the runner did with it.

Turning the integration off makes the runner go quiet over email until you turn it back on. If your runner is offline when an email arrives, the request is held and answered when it reconnects.

Next steps