No, I assure you, we do not. Nobody wants to live in hell. Even at my current company, we are mandated solely to use Teams for meetings. But nobody uses it for chat.

Thankfully we have Slack to save us from that hell. Even if giphy is disabled because it might have R rated content whatever the hell that means.

Why do I have to create a weird "workflow" to receive webhooks in a chat channel? Why does it have such complicated ownership permissions? Why is it automatically deleted if it doesn't see "enough" use? Why do I need to send the message in some weird "adaptive card" format - for which there are barely any ready-made libraries? Heck, why can't I create a new chat channel on my own, but need to invite three other people into it? Why does chat have a completely separate "channels" functionality which act more like a forum?

Please, stop trying to reinvent the wheel! Just do exactly what all your competitors are doing and I'd be so much better. My company is already stuck with Teams due to M365 licensing, there is no need to make it "unique".

The company I'm at has been been building call analytics for Teams since 2021 (QueueMetrics Live). A long-time customer migrated their entire phone system to Teams during the pandemic and asked my boss if we could follow them there. We said "in principle, yes": the Graph API exposes telephony events, so it seemed doable.

It was doable. It was also far harder than anybody expected. The Graph API gives you raw call records, but it doesn't model concepts like "wait time in queue" or "lost call" or "failed agent attempt", and whet it does, nowhere it written HOW. You have to reconstruct those from sequences of low-level events. We ended up building the whole processing pipeline in Elixir because we needed to handle the real-time stream reliably at scale. After a long beta and a few million calls processed, we got to GA. I was dabbling in Elixir at the time, I put it on my CV, and it was noted. In a sense, I owe Teams my current job (though I ended up on a different team, so I'm mostly referring coffee-mug lore here).

We set out to track queues and auto-attendants (that's our bread and butter from the Asterisk world), but we discovered we were seeing everything — inbound, outbound, Teams-to-Teams, even calls with other companies with their internal ids. You can get a complete picture of someone's telephony activity regardless of whether they work in a contact center or just use Teams as their phone. Most of the boring config (names, groups, codes) comes straight from Graph, which is nice.

Like it or not, a lot of enterprises are quietly moving their entire communications (including telephony) to Teams. When they do, they lose the monitoring and analytics they had with their old PBX. That's a real gap, and the Graph API — despite its limitations — gives you something to fill it. But I have a feeling that "3 lines of code" won't cut it. :-)

Apparently not.

I remember when we started working on our teams bot in 2023, Microsoft announced that they will stop supporting Python for the teams sdk, which felt super short sighted. Eventually they silently picked it up again and the old sdk never stopped working.

Kudos for turning it around. I believe it'll last this time as AI agents in communication tools are something a lot of people want. and unlike pre LLM chatbots and agents, they are so much more useful now.

It's nice that they start the post with some sarcasm

Teams / IDE / Harnass / Router / Agent

… and Teams is where it will stay! Microsoft’s piss-poor integrability across its productivity suite is the single biggest reason agentic AI will fail to deliver its promised productivity benefits. You probably could build an agent to do a lot of people’s jobs, provided it had unfettered access to Teams, Outlook, Word, Excel, and PPT. But I can’t think of an organization who would want to grant that access today, and even if they wanted to, the solution here is to expose a self-managed HTTP endpoint for all your Teams traffic? Seriously?

I started like everybody else trying to do simple things via Whatsapp and Slack. Terrible experience. Both systems are pretty locked down and very inflexible and the OpenClaw integration is very limited. You need a phone number for each user in Whatsapp and if you don't have an extra one, you basically end up chatting with yourself. With Slack you end up in permission hell. And their UI for editing permissions is terrible. I never quite managed to make this work.

With Matrix, the experience massively improved. I self host it and I got codex to generate me a working setup that has been running on a cheap vm for a few weeks now. Backups and everything. Hooking that up to OpenClaw was pretty straightforward. You just get a user/password and it gets an access token and then you are good to go to do whatever via the REST API and CLI. So, the OpenClaw integration worked on the first try for me.

Then I had a nice idea and took this to the next level: I gave codex access to my vms with OpenClaw and Matrix stack (Synapse & Element) and I made it create an OpenClaw Admin agent for me, with its own matrix admin user. And then I "taught" it to create more rooms, agents, and bot users for me.

Now I can prompt "create an agent called Foo" via matrix and it will invite me and the rest of our team to the new room. And a minute later I can be chatting to my new agent via a freshly created bot user and model of my choice. Super simple.

We actually ditched Slack a week into this experiment. Because obviously I got the Admin agent to also invite the rest of the team to these rooms and everybody started engaging with agents. We made the admin agent recreate our dozens of slack channels we had as rooms from a screenshot. Migrating content from Slack is a bit meh so we just just skipped that. But Slack in general is a bit meh these days so we don't really miss it.

MS seems to be catching on to this with Teams. I still don't like it. But providing an SDK for it is the smart move. It's essential to enable doing stuff like this.

Is OpenClaw useful? It can be. But you need to solve a lot of plumbing issues like this. Getting the basic plumbing out of the way for setting up new agents with communication channels is a nice first step. We are currently experimenting with all sorts of simple use cases currently. They all require setting up a dedicated agent and having OpenClaw do that for us is both nice as a demo and something we now use a lot.