Turn Chat Messages Into Tasks Automatically: What We Built

To turn chat messages into tasks automatically, you need a bot in the group that reads each message, decides whether it is a request addressed to a named person, and files it in your task system with that person as the owner. The hard part is not the filing. It is deciding what counts as a request, and refusing to guess an owner when the message does not say.

We built one for our own group chats. Here is what it does, the narrow rule that keeps it quiet, and the part we have not proven. We also cover the second thing a bot fleet needs: a register of every bot, who owns it, and what state it is in.

Why do requests get lost in group chats?

Requests get lost in group chats because a chat has no owner field and no due date. A message is a sentence, and the sentence scrolls away. Microsoft’s 2025 Work Trend Index, built on Microsoft 365 telemetry, found the average worker receives 153 Teams messages per weekday. If one of those is “can someone look at the sealer on line two”, it sits among 152 others.

The failure is quiet. Nobody refuses the request. Two people each assume the other saw it, and a week later someone asks again. Maintenance requests and price enquiries are the usual casualties in our group, because they come from people typing on a phone, not filling in a form.

Chat is a good place to ask and a poor place to track. Don’t ban it. Remove the manual step between the message and the task.

What does the agent do, step by step?

The agent receives every message from the groups it sits in, checks whether the message opens by tagging a known team member, and if so creates a task assigned to that person. That is the whole loop. We call a job like this a tomte, our word for one production agent with one defined job, and this one has exactly one: turn directed requests into owned tasks.

In order:

1. The chat platform pushes each group message to a small web function, verified with a shared secret so nobody else can post to it.
2. The function checks the message opens with a tag of a person on a mapped team list. A tag buried mid-sentence (“doc also shared with Priya”) does not count. A keyword match with nobody tagged does not count either.
3. If the message passes, the agent copies the text into the task system as a pending task assigned to the tagged person.
4. That person sees the task in their normal task list, not in a chat scroll.

There is no “assign to whoever is on duty” fallback, because a default owner quietly becomes the dumping ground for every ambiguous message. If a message does not name someone, it is not a task. People learn the rule fast: tag the person first, then say what you need.

The agent’s write access is also narrow. It can create tasks and nothing else. It cannot close them, reassign them, or reply in the group. Matched message text goes to the task system and nowhere else.

How do the chat platforms let a bot see messages?

Each platform sets its own rules for how much of a chat a bot reads. Telegram’s bot documentation says privacy mode is enabled by default, so a bot in a group only receives commands addressed to it, replies to its messages and a few other cases. Turning privacy mode off lets a bot receive all messages like an ordinary user, and the same page recommends doing that only when absolutely necessary.

Slack works differently. Its Events API documentation says an app must be subscribed to the relevant message event and be a member of the channel, and that the app should answer each event with an HTTP 2xx within three seconds. After a failure, Slack retries three times with exponential backoff.

Our design reads the whole group, so our code applies the tag rule, not the platform. That is a real trade: the bot can see every message, including the ones that are not tasks. The group’s owner should make that call deliberately, and the register below records which groups the bot sits in and what it can read.

Platform rules also shape the build. Three seconds to acknowledge means the web function answers fast and does slow work afterwards. Retries mean a task can be filed twice, so the agent has to recognise a message it has already handled.

Chat bot, native task feature, or workflow tool?

Most platforms now offer some version of “save this message as a task”. The question is who does the deciding. The table compares the three common approaches.

Approach	Who decides a message is a task	Owner assigned by	Best when
Native “create task from message”	A person, by clicking	The person clicking	Small teams who already live in the platform’s own task tool
General workflow tool with a keyword trigger	A keyword or emoji	A fixed rule or default	A single group with predictable phrasing
Purpose-built agent with a tag rule	The message itself, if it opens with a tag	The tagged person	Many groups, one task system, requests typed on phones

The native feature fails when nobody clicks. The keyword route fails when people phrase things differently, or when a default owner collects everything. The tag rule is stricter than both, and the strictness is the point: it only fires when the sender already did the work of naming an owner.

If you only have one group and a few requests a week, use the native feature. An agent earns its place when requests come from many groups, when the task system lives outside the chat tool, and when the senders will not click anything.

Where does ours stop?

Ours stops short of what we would call proven. The agent is built, deployed, and still being changed as of October 2026. But when we last checked its fleet manifest, the central agent log held no run history for it, and the manifest noted that no owner had formally confirmed the entry. We can say how it is designed to behave. We cannot hand you a success rate, and we will not invent one.

Three limits are worth stating plainly:

• It does not yet report its runs to the fleet-wide run log. Until it does, it fails the same freshness check we ask of any agent.
• It has no feedback path. A task filed from chat does not post back to the group when it is done, so the sender still has to look in the task system.
• It decides on the opening tag only. Replies in a thread, edited messages and requests written as a question to nobody in particular are not handled.

A side job living in the same bot taught us a smaller lesson. It counts shared links for a content team, and its first real messages went uncounted because a chat identifier we had derived by a shortcut was wrong. The real identifier only showed up in a live log. Verify any derived identifier against a real message before you trust it.

We would rather you hear where it stops from us than discover it in week three. The same gap shows up with meeting notes, which we cover in captured is not completed.

Why keep a register of every bot, owner and status?

Because a bot in a group chat is a standing permission, and nobody remembers permissions. Once you have more than a handful, you cannot answer “which bots can read this group, and who do I call if one misbehaves” from memory. We keep one register for every bot we run. The principle is the same one in our write-up on agent registry governance.

Each record answers the same questions:

• The platform, the bot’s name and public handle, and its status: live, testing, paused or retired.
• Who created it, who manages it, and a named backup. A live bot without a backup owner is flagged, because the person who built it will eventually leave or change role.
• What it is for, and how it works in numbered steps.
• Its triggers, its outputs, the groups it sits in, what data it can read and store, and where it is hosted.
• The names of the secrets it needs. Never the secrets.
• A change history: who changed what, and when.

Three rules do most of the work. The register refuses any entry that looks like a bot token, in the form and again on the server, so credentials cannot be pasted into a shared page by accident. It shows a bot as needing review when it has never been reviewed or the last review is stale. And a daily check asks each bot’s platform whether the bot is still reachable and whether its webhook still points where it should, then compares owner and status against the fleet manifest to catch drift.

The register has limits too. It is only as honest as its owners make it, and the first version of any register is wrong about something. It records a bot’s declared status and does not by itself prove the bot ran. That is why the daily check exists, and why we treat a “live” label as a claim until a run says otherwise.

What would this cost as a Sprint?

A chat-to-task agent is a good shape for an AI Workforce Sprint: one input, one decision rule, one output. The Sprint is fixed price, from $9,500, four to six weeks, built on your infrastructure, documented, and handed to your team at the end. The register is a natural second deliverable, because every bot you add makes the question of ownership harder.

Scope for this job: the chat integration for one platform, the tag-and-team mapping, the connection to your task system, and the run reporting that ours still lacks. Feedback into the chat and multi-platform support are separate orders. Change after scope is agreed is a new order, not an invoice surprise.

Our own fleet, described on the agent fleet proof page, is built the same way: one agent, one job, one named owner.

If requests in your group chats are getting lost, write down the last three that were, who they were meant for, and where they ended up. Start async. You will get a written reply within one business day, and no meetings.