Why does EdgeX11 use email and Slack instead of a chat interface?

Because delegating work is a different act from operating a tool. Email and Slack threads are asynchronous, addressable, multi-party and permanently recorded, which is exactly what assigning work to an employee requires. A chat window assumes one person is present and watching, and it leaves no record your compliance team already governs.

Isn't chat a better interface for AI?

For a coding assistant, yes. When you are in the editor iterating on code with the AI, a tight synchronous loop is ideal because you are the reviewer in real time. That advantage disappears the moment the work takes an hour, involves other people, or needs an approval before it ships.

How does email give you governance that chat does not?

Your organization already applies retention policies, legal hold, e-discovery, data-loss prevention and archiving to email. Every message has a sender, recipients, a timestamp and a thread. When an AI employee works through email, its instructions and decisions inherit that governance automatically rather than living in a product-specific log nobody has policy for.

Do I need to learn a new tool to use EdgeX11?

No. You assign work by emailing your team address, or by messaging in Slack or Microsoft Teams. Employees reply in the same thread with what they did and what they learned. The console exists for oversight — memory, audit logs and approvals — but the day-to-day interface is the inbox you already use.

How do approvals work over email?

The employee prepares the change and asks in the thread. Because the thread is multi-party, the right person can approve, someone else can be copied in, and the decision is recorded next to the request. Production deployments, security-sensitive changes, infrastructure changes and customer-facing messages always wait for that explicit human approval.

Will an AI employee ever contact our customers directly?

Not today. Customer-facing messages require explicit human approval at EdgeX11. Longer term the goal is graduated trust: because each employee accumulates a measurable record of the work it has handled reliably, autonomy can be widened for a documented reason rather than on faith, in the same way a strong new hire eventually earns the right to answer customers directly.

Why AI Employees Use Email, Not a Chat Box

Q: Does our security team get visibility into what AI employees do?

Yes, and it is a deliberate benefit of using governed channels. Email, Slack and Microsoft Teams already sit inside the company security perimeter and under InfoSec review, with monitoring, retention and acceptable-use policy. An AI employee working through those channels inherits that scrutiny automatically, so its instructions and decisions land where your security team already monitors and investigates rather than in a separate product log requiring new policy.

Almost every AI product today is a chat window. For a coding assistant, that's exactly right. For delegating real work to a digital colleague, it quietly throws away everything an enterprise needs.

Key takeaways

Chat is the right interface when you're present and iterating — which is why coding assistants live there.
Delegating work is a different act: it's asynchronous, involves other people, and needs a decision recorded.
Email and Slack threads already carry addressability, multiple parties, approvals and a durable record.
Your compliance team already governs email. A vendor's chat log is a policy gap nobody has written yet.
Those channels are already inside InfoSec's review, so AI employees inherit the same scrutiny humans get.
A visible track record is what makes graduated trust possible — including, eventually, customer contact.
The interface encodes the relationship: a chat box is a tool you operate, an inbox is a colleague you delegate to.

Chat earned its place — in the editor

It's worth being fair to chat, because it won its position honestly. When you're writing code with an AI assistant, a synchronous conversation is genuinely the best possible interface. You type a request, you get a diff, you judge it, you correct it. The loop is seconds long.

That works because of an assumption hiding inside it: you are present, and you are the reviewer. Nothing needs to be recorded, because you saw it happen. Nothing needs to be routed, because you're the only participant. Nothing needs approval, because you're already approving each step by reading it.

Every one of those assumptions breaks the moment the work is bigger than a diff.

Chat optimises for a conversation. Enterprise work needs a record.

Delegation is not a conversation

Think about how you actually hand work to a colleague. You describe the outcome, you leave, and you get on with your day. Hours later something comes back. Along the way someone else gets looped in. Before it ships, a specific person signs off. Weeks later, somebody asks why it was done that way — and there's a thread to point at.

That is a fundamentally different shape from a chat session. It's asynchronous, it's multi-party, and it's on the record. If you try to squeeze it into a chat window, you don't just lose convenience. You lose the properties that made it safe to delegate in the first place.

What a thread gives you that a chat box doesn't

This isn't nostalgia for email. It's that a threaded, addressed message happens to carry five properties that delegated work requires — and a chat session structurally cannot.

The same task, in two different interfaces
What the work needs	Chat window	Email / Slack thread
Assign it and walk away	Assumes you're present and watching	Asynchronous by design — it finds you later
Reach a specific person	You're talking to "the AI"	Employees have addresses; you pick who does it
Loop in a colleague	Mostly one human, one session	CC, forward, reply-all — multi-party natively
Get an approval before shipping	No notion of a second signer	The approver answers in the thread; the decision sits beside the request
Explain it six months later	A scrollback, if it still exists	A retained thread with sender, recipients and timestamps
Satisfy your compliance team	A vendor log with no existing policy	Already covered by retention, legal hold, e-discovery and DLP

Scroll the table sideways on a narrow screen.

The governance part matters more than it sounds

That last row is the one enterprise buyers care about, and it's the least discussed.

Your organisation has spent years building policy around email and chat. Retention schedules. Legal hold. E-discovery. Data-loss prevention. Archiving. Access via SSO. When an AI employee receives its instructions by email and reports back in the same thread, all of that governance applies automatically — not because we built it, but because the message is an ordinary message in a system your company already controls.

Now consider the alternative. An engineer opens a vendor's chat window, describes a production change in the prompt, and the AI does it. Where does that instruction live? Who retains it? Is it discoverable? Does your DLP see it? For most companies the honest answer is: nobody has written that policy yet, because the tool arrived faster than the governance did.

The safest place for an AI's instructions to live is the same place your humans' instructions already live.

The same InfoSec net that watches humans

Here's the consequence that makes this more than a filing preference. Your company's communication tools are already inside the security perimeter. InfoSec reviews them. Email, Slack, Teams and Gmail sit under monitoring, retention and acceptable-use policy precisely because that's where employees might do something careless, something outside policy, or something they shouldn't.

When your AI employees work through those same channels, they inherit that scrutiny automatically. Who asked for what. Who approved it. Whether a request was appropriate. Whether anything touched data it shouldn't have. It's all visible in a system your security team already reviews — not in a product-specific log they'd have to learn, request access to, and write new policy for.

That matters more as you add employees. One AI agent in a chat window is a curiosity. Two dozen of them taking real actions across your systems is an accountability problem — and the honest question a security lead will ask is: if one of these did something wrong, would we know?

Routing the work through governed channels turns that from a hard question into an easy one. Every instruction and every decision is already where your investigations start.

An AI employee should be no harder to audit than a human one.

The interface encodes the relationship

This is the part we keep coming back to. A chat box frames the AI as a tool you operate — you're at the controls, so you're responsible for every keystroke. An inbox frames it as a colleague you delegate to — it owns the outcome, and you review the result.

If you want AI that behaves like an employee, giving it an employee's interface isn't cosmetic. It's what makes the expectation legible to everyone involved.

What this looks like in practice

Concretely, this is how work reaches an EdgeX11 employee:

You email the work in. Send a task to your team address and it's routed to the right employee by subject and content — or tag someone directly to reach them by name.
They reply in the thread. Not just "done" — what they did, what they learned, and what needs your attention. The context stays attached to the request.
Other people can join. Copy in a reviewer, forward it to the person who actually owns that service. The employee sees the thread the way a colleague would.
Approvals happen in place. Production deployments, security-sensitive changes, infrastructure changes and customer-facing messages wait for an explicit human yes.
Slack and Teams work the same way, because a channel thread has the same properties: named participants, threading, and retention your admin already configures.

There's still a console — for the organisational memory, the audit log, and oversight of what everyone's working on. But that's where you go to supervise. It isn't where the work is assigned, because asking your team to adopt a new tool to delegate a task is a tax on the thing you were trying to make easier.

Where chat is still the right answer

To be clear about the boundary, because "email for everything" would be its own mistake:

If you're pair-programming with an AI in your editor, use chat. The loop is tight, you're the reviewer, and the overhead of a thread would slow you down for no benefit. Coding assistants belong in chat and they should stay there — we said as much when we compared the categories honestly.

The distinction is simple: chat is for work you're doing. Threads are for work you're delegating. Most companies need both, and most companies currently only have the first.

Trust is earned — and that raises the ceiling

There's a second-order effect here that we think is the actually interesting part.

Think about how a new hire earns autonomy. On week one, everything they do is checked. Six months in, they ship small things unsupervised. After two years, they're talking to customers directly, because they've built a track record and everyone knows what they're good at. Nobody granted that in a single decision — it accumulated, visibly, through work.

Once an AI employee works in governed channels, the same mechanism becomes available. Its record isn't a vibe — it's a measurable history: tasks completed, confidence in what it has learned, corrections it absorbed, and the areas it has genuinely become reliable in. You can look at an employee and say, with evidence, this one has handled ninety of these and never got one wrong.

That's what makes graduated trust possible rather than reckless. An employee that has proven itself on internal work could reasonably be trusted with more — and further out, with drafting or even sending routine customer replies in its area of expertise, the way you'd eventually let a strong support engineer answer customers without a manager reading every email first.

To be clear about where we are today: customer-facing messages at EdgeX11 require explicit human approval, full stop. We're not shipping autonomous customer contact, and we'd be wary of any vendor who offered it before the track record existed to justify it. But that's the direction, and the reason it's plausible at all is the boring infrastructure — a real address, a threaded record, an approval gate, and an audit trail that lets trust be extended for a reason instead of on faith.

Autonomy shouldn't be a setting you toggle. It should be something an employee earns, on the record.

Which is why the interface question isn't a small one. Get it right and you have a path from "AI that needs supervision" to "colleague you'd trust with the customer." Get it wrong and you're stuck at the ceiling of whatever one person can personally watch.

The test worth applying

Next time you evaluate an AI tool that takes real actions on real systems, skip the demo for a moment and ask three questions:

Can I assign something and close my laptop? If it needs me watching, I haven't delegated — I've operated.
Can someone else see it and sign off? If not, every action is implicitly approved by whoever happened to type it.
Where does the instruction live in six months? If the answer is a vendor's scrollback, your audit trail has a hole in it.

Interfaces look like a design decision. For AI that touches production, the interface is the governance model — it decides what can be recorded, who can intervene, and what you'll be able to prove later.

Common questions

Isn't chat just a better interface for AI?

For a coding assistant, yes — you're present and reviewing in real time, so the tight loop wins. That advantage disappears as soon as the task takes an hour, involves other people, or needs an approval before it ships.

What does email actually give me that chat doesn't?

Asynchrony, a real address for each employee, multiple participants, an approval that sits beside the request, and a retained thread your compliance team already governs.

Do I have to learn a new tool?

No. You assign work by email, Slack or Microsoft Teams, and employees reply in the same thread. The console is for oversight — memory, audit logs and approvals — not for day-to-day delegation.

How do approvals work in a thread?

The employee prepares the change and asks. Because a thread is multi-party, the right person approves, others can be copied in, and the decision is recorded next to the request rather than in a separate system.

Does our security team get visibility into what AI employees do?

Yes — that's a deliberate benefit of using governed channels. Email, Slack and Teams are already inside your security perimeter and under InfoSec review, so an AI employee's instructions and decisions land where your team already monitors, retains and investigates, rather than in a separate log they'd need new policy for.

Will an AI employee ever email our customers directly?

Not today — customer-facing messages require explicit human approval. Longer term, graduated trust is the goal: because each employee accumulates a measurable record of what it has handled reliably, autonomy can be widened for a reason rather than on faith, the way a strong hire eventually earns the right to answer customers directly.

Assign work the way you already do

Hire your first AI employee and give it a real task from your backlog — by email, from the inbox you already have open. Nothing ships without your approval.

Start free