How I AI: Yash Tekriwal on Taming Slack with a Custom AI-Built Dashboard

Yash Tekriwal wakes up to roughly a hundred to 150 Slack notifications every day, many of them direct mentions or DMs that all look equally urgent inside Slack’s default inbox. In this episode of How I AI, he shows how he reduced that flood into a smaller queue of messages that actually need attention, first through a structured digest and then through a custom Kanban-style dashboard built on top of Slack. See How to Turn a Text Digest into an Interactive Kanban Dashboard.

The important architectural decision is that the system does not ask AI to manage Slack end to end. Retrieval, timestamps, unread state, and grouping are handled deterministically through APIs and custom logic. The model is reserved for the subjective layer: deciding whether something is Action Required, Need to Read, or simply FYI.

Yash first built the underlying pipeline with an OpenClaw agent, then used Perplexity Computer to generate a cleaner interface over the working data. Later in the episode, he applies the same pattern to a broader personal command center and to a Clay University redesign prototype that helped his team communicate product ideas visually before committing to production work. See How to Prototype a Website Redesign Using an AI with Browser Access.

Designing a better Slack inbox

Yash did not start by asking an AI agent to make Slack better. He started by defining what actually felt wrong about his workflow. Slack treated every notification similarly, but his own priorities clearly did not. A scheduling DM mattered more than a reaction chain in a social channel, even if both generated identical unread indicators.

From there, he built two classification systems into the digest:

1. Source: Direct messages, group direct messages, threads, and group mentions.
2. Urgency: Action Required, Need to Read, and FYI.

That second layer changed the emotional weight of the inbox. Yash estimated that roughly 60 to 80 percent of his notifications were ultimately FYI messages. A queue that initially felt like a hundred to 150 urgent interruptions became closer to 30 or 40 things that genuinely required follow-up.

Building the retrieval layer with OpenClaw

Yash built the first version through long back-and-forth sessions with an OpenClaw agent running inside Discord. He preferred Discord over Telegram because threaded conversations and fast search made it easier to manage a sprawling technical build conversation that stretched across thousands of messages.

1. Slack state: The agent had to reverse engineer how Slack represents unread messages, thread state, and notifications through timestamps and metadata. Yash specifically wanted the system to pull only the notifications that mattered to him, not every new message inside every channel.
2. Digest code: Over roughly a day of iteration, the agent built retrieval and grouping logic that could:

• Pull only messages that generated notifications for Yash rather than ingesting every Slack update.
• Compare timestamps against prior read state so the digest would not repeatedly surface context he had already seen.
• Group notifications into the source buckets he actually uses to prioritize work during the day.

1. AI classification: The model call sits on top of that deterministic pipeline and handles the fuzzier judgment task of labeling urgency from message content. Yash was careful not to let the model become the source of truth for retrieval itself. If the AI misclassifies a message, the dashboard still exposes the original Slack thread and deep link so he can inspect the source directly.

The first usable version posted a structured digest back into Slack itself. It grouped notifications cleanly and attached links into the original conversations, but the experience still involved scrolling through a very long block of text and command-clicking through dozens of threads. You can follow the full implementation in How to Build a Custom AI-Powered Text Digest for Slack Notifications. See How to Build a Custom AI-Powered Text Digest for Slack Notifications.

Turning the digest into a navigable dashboard

Once the retrieval layer worked reliably, Yash moved to Perplexity Computer to build a dedicated interface on top of it. His prompt focused less on generating code in the abstract and more on analyzing the structure of the existing digest channel and turning that information into software that behaved more like a task manager.

He estimated that the dashboard reached roughly 80 percent of the desired functionality within the first few prompt exchanges. Most of the remaining work involved usability refinements, troubleshooting, and adding stateful behavior like deep links and archive actions.

Three characteristics of the environment stood out to him during the build:

• Model routing: Different models handled retrieval, planning, coding, and heavier reasoning tasks during the same workflow instead of forcing a single model to do everything.
• Cloud connectors: Connected services reduced setup overhead and let the tool operate directly against apps like Slack and Notion, though those integrations still require careful scope management and clear ownership over where data flows.
• Concurrent tasks: Multiple long-running jobs could execute in parallel while he continued working elsewhere instead of forcing a strict one-thread-at-a-time coding loop.

A Kanban board for Slack triage

The resulting interface looked more like a lightweight task manager than a messaging client. Notifications were organized into three color-coded columns:

• Red: Action Required.
• Yellow: Need to Read.
• Green: FYI.

Yash also preserved the original source filters, allowing him to process DMs differently from thread mentions or group notifications. Every card linked back to the underlying Slack message so the dashboard never became a disconnected copy of the data. One particularly useful interaction was Archive All for FYI items. That action cleared the low-priority queue inside the dashboard and simultaneously marked those notifications read in Slack itself. Because it changes read state in the source system, it is the kind of feature that benefits from explicit confirmation and tightly scoped permissions.

Expanding the pattern into a personal command center

After validating the Slack workflow, Yash expanded the same architecture across three information streams:

1. AI news
2. Email
3. Slack

The sequence remained consistent. First, make sure the underlying text digest and categorization logic are trustworthy. Then build an interface over the working pipeline. During the episode, Yash described iterating in phases: validating the categorization, adding a Kanban-style UI, and then improving usability by attaching deep links back to the authoritative source items.

The result is less a replacement for Slack or Gmail than a personal triage layer sitting on top of existing systems. The original apps still control permissions, retention policies, and canonical records. The custom dashboard simply changes how one person moves through information overload.

Using AI prototypes to communicate product ideas

Yash also highlighted work from teammate Chris Ming around redesigning Clay University into persona-based learning journeys for RevOps, SDR, and marketing operations users.

The challenge was not just imagining new navigation flows. The team needed a concrete representation that reflected the structure and visual context of the existing Clay University site so education and design stakeholders could react to something tangible.

Perplexity Computer inspected the live public site through the browser and, after roughly an hour of iteration, generated a functional prototype layered on top of the existing experience.

The prototype was not production-ready design work, but it captured the core interaction ideas the team needed to discuss. It showed persona-specific learning tracks, logged-in progress states, recommended courses, and navigation paths tailored to different user types. That gave the team a shared visual artifact instead of forcing everyone to translate abstract requirements across documents, screenshots, and meetings.

Micro-software for personal workflows

One of the more interesting themes in this episode of How I AI is the idea that lower implementation costs make extremely niche software economically reasonable. Yash’s Slack dashboard solves a very specific problem for one heavy Slack user. Under a traditional SaaS roadmap, that kind of workflow customization probably never gets prioritized. With AI-assisted development, it becomes practical to build anyway.

I framed this as an anti-to-do list: identify repetitive tasks you never want to do manually again, validate the data pipeline behind them, and then layer in automation, interface design, and AI judgment where it actually helps. The examples throughout the episode stayed grounded in that pattern. Structured APIs handled retrieval. Models handled categorization and summarization. Humans still approved the results and refined the workflow over time.

When prompting breaks down

Yash joked that he sometimes resorts to all-caps prompts and dramatic fictional consequences when a model gets stuck. The more useful operational lesson from the conversation is elsewhere: when an agent repeatedly fails, he tends to inspect where the context or tooling is incomplete. In one example, he found that calendar workflows improved once timestamp information was passed more explicitly into the system. More generally, the fixes were usually to clarify the task, narrow the scope, provide better state, or create reusable skills for recurring problems.

Keeping the authorization boundary clear

The workflows in this episode rely heavily on connected systems and cross-app access, which makes permission boundaries important. Slack credentials should use the minimum scopes necessary, and secrets should stay outside prompts and generated code.

• Bulk actions that change read state or archive notifications should be explicit and reversible whenever possible.
• Combining Slack, email, meeting notes, and news feeds into one dashboard can be genuinely useful, but it still needs to respect organizational policy, user consent, and retention requirements. The pattern itself is worth copying for people buried in notifications or repetitive coordination work. The strongest implementations keep the data layer deterministic, preserve links back to the source system, and reserve AI for the ambiguous judgment calls humans already make imperfectly themselves.