Chat Is Where the Work Is

Work Happens in Chat Workflows

If you are a working professional for any major enterprise, chances are your company uses a chat application like Microsoft Teams, Slack, or even Discord (just be sure to have your ID on you). These chat applications are becoming increasingly more sophisticated, integrating with third-party tools to increase productivity: Trello boards to track work, GitHub updates for keeping an eye on changes, AI chat assistants (e.g., MoveWorks for ITSM), and much more. You can upload or download files, execute commands, receive push notifications, or even have a conversation with them.

In my space, I created an app that enables engineers to submit high-performance compute (HPC) simulations, execute job management commands, receive push notifications about the status of their job, and even chat with the bot to troubleshoot failed jobs or get help from ingested documentation. It started as a side project. Within the first week, about 20 internal engineering users picked it up. Today it serves over 1,500. When I migrated the tool from Teams to Slack, over 700 users followed within the first 48 hours. I sent out announcements and emails, but a significant portion of that growth was organic through word of mouth because the tool was useful enough that people told each other about it.

When it comes to internal tooling, users do not want to switch context between a myriad of different looking home-grown tools. Even if your enterprise enforces a UI model for consistency, these traditional tools require infrastructure to host and maintenance to support.

This is why increasingly I am seeing a shift towards chat-based workflows. Everyone in the company is already using the chat-based tool of choice. So why not bring the work to where the users are and empower them to do what they need in a way that’s as natural and second nature as having a conversation.

The case against traditional dashboards and websites

Traditional web apps have a bloat factor — they come with overhead. They have their role, but it’s increasingly becoming more specialized as logic moves to chat-based agents. Apps like Teams or Slack don’t have a rendering engine in the conversation thread, so they can’t display live dashboards or complex interactive graphics on demand. But there are ways around that. You can programmatically generate charts or screenshots of complex visualizations server-side, upload them to blob storage, and either share a SAS link (a time-limited, signed URL) or upload the image directly in the chat — giving users an image preview right in the conversation. For anything more involved like live dashboards, interactive data exploration, geometry viewers a thin-client web app can work symbiotically alongside the chat agent. The chat app becomes the primary interface; the web app becomes a specialized companion you reach for only when the chat medium genuinely can’t do the job. The point is that the days of the traditional standalone website as the default delivery model for internal tooling are ending. Companies want quick, lightweight, deep functionality — and they want it delivered in a way that’s cheaper to build and maintain than fat-client desktop apps or full-featured thin-client web applications.

Why move workflows to a chat agent

The most obvious reason is that your users are already there. They have the app open all day. They’re reading messages, responding to threads, checking notifications. When you put a workflow inside that same surface, you eliminate the friction of “go open this other tool.” There’s no new URL to bookmark, no new login to manage, no separate UI to learn. The barrier to entry drops to nearly zero — type a command, push a button, get a result. There’s a second reason that’s easy to overlook: mobile access. In large enterprises, internal websites are often gated behind VPNs or network policies that make them inaccessible from a phone. But Slack and Teams are already approved for mobile. Users enroll their device into something like Intune per company policy and they’re in. That means an engineer sitting in a meeting, away from their desk, or on a factory floor can check simulation status, resubmit a failed job, or pull up results without needing a laptop connected to the corporate network. You get mobile access essentially for free because the chat platform already solved that problem. Then there’s the infrastructure argument. Every internal web app is a thing you have to host, patch, monitor, and support. It needs a deployment pipeline, a certificate, a load balancer, someone to answer when it goes down at 2 AM. A chat-based agent still has a back end, but you’re offloading the entire front-end stack — the hosting, the rendering, the cross-browser testing, the responsive design — to the chat platform. Your surface area shrinks reducing the maintenance burden. And the effort you would have spent on a React front end goes instead into the logic that actually matters to your users. There’s also a powerful aggregation benefit that’s hard to replicate with traditional web apps. A single chat agent can serve as the front door to multiple disparate back-end systems. In my case, the same bot interface routes to an HPC job scheduler for simulation management, an AI orchestration layer for multi-agent workflows and response triage, a Go service for pulling product data from a PLM system, and a traditional web app for dashboards and deeper visualization. The user doesn’t know or care that five different systems are behind the curtain. They interact with the chat interface and get what they need when they need it. That kind of seamless aggregation across back ends is something traditional web apps can do too, but the chat medium gives you the UI for free without having to juggle frameworks and libraries. The chat platform becomes the design system. Finally, discoverability. A chat agent lives where conversations happen. Engineers share commands in channels. Someone posts a screenshot of a result and another person asks “how did you do that?” The tool markets itself in the medium where people already communicate about work. That’s how you get 1,500 users from a side project without a product marketing team.

How to guard against migrations through abstraction

What if the vendor goes out of business or changes their licensing model? This is a real concern and there’s a spectrum of approaches depending on how much coupling you’re willing to accept. On one end, you can use abstraction layers like Azure Bot Service so you’re not speaking directly to the vendor API but rather the bot service framework. You put most of your logic in your back end with a lightweight orchestration layer that routes the user action — be it a question, a slash command, a button push — to the right back end for processing. If the chat platform changes, you swap the front-end integration, not the business logic. On the other end, some things are just easier — or only possible — through the vendor API directly. Replying to a specific thread, uploading a file to a conversation, sending an ephemeral response to a slash command via the response_url that Slack provides in the request payload — these are platform-specific interactions. Trying to abstract them through a bot framework can add complexity without adding value. Most teams will land somewhere in the middle: core business logic abstracted behind services, with a thin vendor-specific layer for the interactions that need it. The key is being intentional about where the coupling lives. If your slash command handler calls into a back-end service and the Slack-specific code is limited to parsing the request and formatting the response, then migrating to another platform is a front-end exercise instead of a rewrite. I’ve done this migration and while it’s not painless, the blast radius is contained when the architecture is right.

The future of integrated work

I’m not going to predict what the landscape looks like in five years. I don’t know. The rate of change is accelerating, so any predictions live on shaky ground. What I do know is what’s already happening: logic that used to live exclusively in web apps and desktop tools is moving into chat. Some of those traditional apps can be eliminated entirely. Others get stripped down to the bare essentials. The things that genuinely can’t be done in a chat thread, like rendering interactive 3D geometry or building complex filter-heavy dashboards. AI is accelerating this. As large language models (LLMs) and specialized agents become native features inside Slack and Teams — and as third-party apps in those marketplaces get more capable — the chat window stops being a place where you just talk about work and starts being a place where you do the work. Submit a simulation, check results, troubleshoot a failure, query a database, approve a request all without leaving the conversation. For platform engineers and tooling teams, the implication is practical: if you’re building a new internal tool today, ask yourself whether it needs to be a website or standalone app at all. Maybe the right answer is a bot, a set of commands, and a thin web companion for the handful of things that need a full UI. Your users are already in the chat. Meet them there (and bring the good stuff).