Email That Knows What to Do: How Argus Translates User Rules Into Actions

Traditional email rules work well when the condition can be described in advance: a specific sender, a subject line containing a certain word, or a message that arrives in a particular folder. But work correspondence is rarely that predictable. The same intent can be phrased in dozens of different ways.

We built Argus — an intelligent assistant for working with email inside Microsoft Teams. The user describes a rule in plain language, and Argus analyzes the content of incoming messages and performs the specified actions: it classifies, moves, flags, forwards, or deletes an email, or prepares a reply. The point here isn't the automatic moving of messages — it's understanding the meaning of an email and composing a reply that reflects its specific context.

In June 2026, iXBT, citing Cloudflare data, reported that automated traffic had surpassed human traffic for the first time. According to Cloudflare, the share of bots ranged from 52% to 62% at various points, and over the seven-day period in question it stood at roughly 57.4% versus 42.5% for human traffic. Cloudflare attributes this growth in part to the spread of AI agents, which retrieve information from the internet and perform actions on behalf of users.

This is data about internet traffic, not email. It shouldn't be applied directly to corporate correspondence. But the trend is telling: more and more communication is created, processed, and initiated by automated systems.

For email, this points to a different problem.

When messages are generated by both humans and bots, arrive in different formats, and carry different contexts, rules like "if the subject contains word X, move the email to folder Y" quickly run into their limits.

The problem is no longer just what's written in the subject line. You need to determine why a person wrote the message and what should be done with it.

Consider a common scenario. A candidate's résumé arrives at a corporate address.

In one message, a person might write:

"Please consider my résumé for any of your open positions."

In another:

"I would be grateful if you could consider my candidacy."

In a third, the word "position" won't appear at all: the candidate simply sends a résumé and briefly describes their experience, hoping for a suitable role.

With a classic rule, you'd have to list all the possible phrasings in advance. With Argus, the user defines the meaning:

"If this is a request to consider a résumé for any vacancy or position…"

The rule can then continue with actions:

"…move the email to 'Rejections,' mark it as read, and prepare a polite reply to the candidate: let them know that their résumé will definitely be reviewed and that we'll reach out if there's interest."

Argus analyzes the email, matches its content against the rule's condition, and builds a sequence of actions.

The user doesn't need to know how semantic classification works or which model analyzes the text. They simply describe the desired behavior in human language.

Moving an email to a folder is technically easier than writing a proper reply.

If a company receives a partnership proposal, a reply like "Thanks, we're not interested" formally closes the task. But such a response barely reflects the content of the specific message.

Argus receives both the email itself and the user's instruction. That's why the task is framed differently:

"If this is any kind of partnership proposal — mark it as read, prepare a polite decline, and delete the email."

Here, the reply text isn't generated from a single pre-written template. The model sees the context of the specific message and composes a reply tailored to it.

This is the fundamental difference between an auto-responder and intelligent email processing.

An auto-responder picks text from a predefined set.

Argus first determines what's happening in the email, then applies the rule, and only then composes a reply in line with the user's instruction.

Automatically sending AI-generated replies without user oversight is a bad idea for a first launch.

That's why Argus uses a different mechanism.

Once a rule is triggered, it sends the user a card in Microsoft Teams:

Rule ready to run

The rule "Request to consider a résumé for any vacancy or position" requires confirmation.

Subject: Résumé From: Stepan Ivanov

Draft reply:

"Hello! Thank you for your interest in our position. We'll be sure to review your résumé and will get in touch soon if there's interest."

The user sees the original email, the rule, and the prepared reply. They can then apply the rule, or skip this trigger and adjust the settings.

This is a key element of the product's architecture: autonomy is never switched on blindly.

The user first observes how the rule performs. If several triggers run correctly, they can click "Enable auto-apply." After that, confirmation cards stop arriving and the rule begins to operate on its own.

If needed, this mode can be turned off through the Rules panel.

In a typical filter system, actions are often tied to simple conditions. With Argus, the condition and the sequence of actions are defined together.

For example:

IF (semantic): "any kind of partnership proposal" THEN mark as read; reply to the sender: "Politely decline"; delete the email.

Or:

IF (semantic): "request to consider a résumé for any vacancy or position" THEN move to "Rejections"; mark as read; prepare a reply to the candidate.

And the user isn't limited to a predefined set of phrases. The rule is written in free, natural language.

This changes the setup process itself.

Before, the user configured a filter.

Now, they describe a task to an employee.

t's easy to mispositioning the product as "an AI that runs your email on its own."

For corporate use, a different model is more accurate.

A person defines how a certain category of emails should be handled. Argus recognizes that category, applies the rule, and — depending on the settings — either waits for confirmation or acts on its own.

As a result, the user defines the logic once, tests it on real emails, and then hands routine operations over to automation.

This is especially noticeable where emails are similar in meaning but vary widely in wording.

For corporate email, the question of automation can't be separated from the question of security.

Argus works with the content of real correspondence. Emails may contain personal data, commercial terms, internal documents, and other information that a company must not send to external services.

In Argus's implementation, data does not leave the corporate perimeter.

This is a fundamental requirement for this class of systems. Intelligent email processing must not mean automatically sending corporate correspondence outside.

At the same time, the specific deployment architecture, the models used, access rights, and retention policies should be defined by the requirements of each customer and their information security team.

Argus shouldn't be seen as a system where you write "sort my email" once and it flawlessly makes every decision fr om then on.

There are scenarios wh ere automation requires additional constraints.

If a rule is phrased too vaguely, the model may misinterpret the email's intent. If a single category of emails contains different business scenarios, one rule may not be enough. For critical messages, mandatory human confirmation may be required.

There's an organizational side, too. The customer needs to define which actions may be performed automatically, which require confirmation, and which categories of messages must not be processed without an employee's involvement.

That's why Argus is designed for a gradual transition from oversight to autonomous operation.

First, the user reviews the triggers. Then they enable auto-apply only for the rules they trust.

Getting started doesn't require describing every possible type of email in advance.

You'll need to define:

• which categories of messages employees want to handle automatically;

• which actions are acceptable without confirmation;

• which operations require human involvement;

• which mail folders, categories, and policies are already in use;

• what requirements apply to storing and processing corporate correspondence.

From there, rules can be created directly in natural language and tested on real messages.

You don't need to automate all of your email at once.

Take one recurring category of emails — for example, résumés, partnership proposals, or standard inquiries. Write a rule for it in plain language, run it in confirmation mode, and review a few real triggers.

If you're happy with the results, enable auto-apply.

This is the stage where it becomes clear how well intelligent processing fits a specific email workflow — not on a demo example, but on your company's real correspondence.