Step-by-Step: Turning Your Slack Listener into a Proactive Agent

Step-by-Step: Turning Your Slack Listener into a Proactive Agent

Estimated reading time: 8 minutes

• Transition from a passive Slack listener to a dynamic, proactive agent by enabling intelligent responses.
• Set up Slack Incoming Webhooks to establish a secure, one-way communication channel for sending automated messages from your application.
• Leverage the Symfony Notifier Component for a robust, abstract, and scalable solution to send notifications across various channels, including Slack.
• Implement asynchronous processing with Symfony Messenger to handle incoming Slack notifications and integrate with services like Large Language Models (LLMs) efficiently, ensuring system responsiveness.
• Build a complete communication loop: receive Slack events, process data using a message bus, and send targeted, automated responses back to Slack channels.

• Setting Up Outbound Communication: Slack Incoming Webhooks
  • Actionable Step 1: Slack Incoming Webhook Creation
  • How to Send Your First Message
• Choosing Your Symfony Communication Method
  • Top Pick: Symfony Notifier Component
  • Actionable Step 2: Integrate Symfony Slack Notifier
• Building the Proactive Logic: Webhook Processing with Symfony Messenger
  • Using Symfony Messenger for Asynchronous Slack Notification Handling
  • Actionable Step 3: Create the Message and Handler
  • Real-World Example: Automated Support Bot
• Conclusion: From Passive Listener to Proactive Agent
• Discover Solutions and Continue Building
• Frequently Asked Questions

In today’s fast-paced digital environment, merely listening isn’t enough; proactive engagement is key. For applications integrated with communication platforms like Slack, the ability to not just receive information but also intelligently respond can revolutionize efficiency and user experience. This article builds upon previous foundations, guiding you from a passive listener to a dynamic, proactive agent.

“In our previous article, we delved into the mechanics of receiving real-time notifications from Slack using a webhook and handling the incoming data with a Symfony controller or symfony/webhook component. This was the foundational step — the “ear” of our system.” Now, we’re ready to move from passive listening to proactive action. This article will guide you through the process of building a Slack auto-answer system. This is the next evolution of our “proactive agent”, which will not only receive event data but also analyze it and send an automated response back to the channel. This is a crucial step towards creating a truly intelligent and responsive bot that can handle routine queries, provide instant updates, or trigger further actions based on specific keywords or events.

We’ll focus on the architecture and key components needed to build this system, leveraging Symfony’s power to process the incoming webhook data and interact with the Slack API to send messages. Get ready to turn your simple webhook receiver into a powerful real-time automation tool.

Setting Up Outbound Communication: Slack Incoming Webhooks

To kick things off, we need to set up the communication channel for our automated responses. We’ll enable our Slack workspace to receive messages from our application. This is done by configuring Incoming Webhooks within the Slack API developer console at api.slack.com.

An Incoming Webhook is a simple way for an external application to post messages into Slack. It provides a unique URL that acts as a secure, one-way bridge. When our Symfony application sends a message (payload) to this URL, Slack will receive it and post it in the designated channel.

Actionable Step 1: Slack Incoming Webhook Creation

To create an Incoming Webhook in Slack, you need to follow these steps:

1. Select your Slack App or create a new one: Go to api.slack.com/apps and click “Create an App”. Choose a name for your app and select the Slack workspace where you want to install it. It’s a good idea to use a dedicated development or testing workspace to avoid spamming your main channels.
2. Activate Incoming Webhooks: In the left-hand sidebar, navigate to “Features” > “Incoming Webhooks”. Toggle the “Activate Incoming Webhooks” switch to “On”.
3. Add a New Webhook to Your Workspace: Once activated, the page will refresh and you’ll see a new section. Scroll down and click “Add New Webhook to Workspace”. A new page will appear, prompting you to choose the channel where your app will post messages. Select a channel and click “Authorize”.
4. Get the Webhook URL: After authorization, you’ll be returned to the app’s settings page. A new Webhook URL will be listed under the “Webhook URLs for Your Workspace” section. Copy this URL. This is the unique endpoint that your Symfony application will use to send messages to Slack. Remember to treat this URL like a password and keep it secure (e.g., using environment variables).

How to Send Your First Message

Once you have the webhook URL, you can use a command-line tool like curl to test the connection and send your first message from the console. This is a great way to confirm that your Slack Incoming Webhook is set up correctly before you start integrating it into your application.

curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello from our Proactive Agent!"}' [YOUR_SLACK_WEBHOOK_URL]

This command dispatches a JSON message to your specified Slack channel. The -X POST method signals you’re sending data, -H 'Content-type: application/json' correctly formats the request, and --data carries the message payload. Upon execution, you should instantly see “Hello from our Proactive Agent!” appear in your designated Slack channel, confirming successful one-way communication.

Choosing Your Symfony Communication Method

Now that we have our outbound channel, let’s analyze the options for sending messages from a Symfony application. We have four main choices: using the external curl utility, Symfony’s HttpClient, the Guzzle library, or the Symfony Notifier component.

• Using curl from the Command Line: Simple for quick tests but carries security risks, performance overhead due to process spawning, and poor error handling for production environments.
• Symfony/http-client: The official, native Symfony solution. Offers high performance, robustness, and seamless integration with the framework. Best suited for Symfony-specific projects.
• Guzzle: The most popular third-party PHP HTTP client. Feature-rich, framework-agnostic, and widely adopted, but can be overkill for simple webhook tasks.
• Symfony Notifier Component: Provides a high-level abstraction for sending notifications across various channels (email, SMS, Slack, etc.). It simplifies switching transports and offers pre-built integrations. It requires more setup but offers superior abstraction and maintainability for notification systems.

Top Pick: Symfony Notifier Component

While symfony/http-client is an excellent choice for direct HTTP requests within a Symfony project, the Symfony Notifier Component is superior for building a reusable and abstract notification system, which aligns perfectly with our proactive agent’s goal of flexible communication. It treats Slack as just another channel, making your code cleaner and easier to adapt.

Actionable Step 2: Integrate Symfony Slack Notifier

Since we’ve already installed the symfony/notifier component (as often happens in a Symfony project), to solve our task we just need to install the Slack bridge. This will allow the Notifier to “know” how to send notifications via Slack.

To install the necessary package, run the following command in your terminal:

composer require symfony/slack-notifier

This command integrates the Slack API, enabling the Notifier component to send messages without you handling low-level HTTP requests or JSON formatting.

Next, we’ll update the config/packages/notifier.yaml file to configure our Slack transport. For this example, we’ll keep it simple and focused on email and Slack channels:

framework: notifier: message_bus: core.command.bus chatter_transports: slack: '%env(SLACK_DSN)%' texter_transports: channel_policy: urgent: [!php/const App\Const\NotificationChannel::EMAIL] high: [!php/const App\Const\NotificationChannel::SLACK] medium: [!php/const App\Const\NotificationChannel::EMAIL] low: [!php/const App\Const\NotificationChannel::EMAIL]

Crucially, you need to add the SLACK_DSN variable to your .env file. This is the [YOUR_SLACK_WEBHOOK_URL] you obtained earlier:

SLACK_DSN=YOUR_SLACK_WEBHOOK_URL

Based on our configuration, the Symfony Notifier component is set to send all notifications to an email address, with the exception of high-importance notifications. This allows us to strategically route urgent messages. Our next step is to configure our Slack responses to be of high importance. By doing this, we can ensure that any automated replies we generate are sent directly to the Slack channel, bypassing the default email transport. This provides a clean and logical separation of communication channels: standard notifications go to email, while real-time, high-priority responses are delivered to Slack.

This approach is highly effective for building a proactive agent because it enables you to send routine, low-priority alerts to one channel and reserve the Slack channel for critical, time-sensitive information, such as immediate answers to user questions or alerts about system failures. By following this strategy, we maintain a clear and efficient communication flow, ensuring that the right message reaches the right channel at the right time.

Building the Proactive Logic: Webhook Processing with Symfony Messenger

This is a main step for our “Proactive Agent” because it provides the mechanism for our system to take action — to send automated replies, confirmations, or other relevant information back to the user or channel. This completes the communication loop: receive an event via webhook and send a response via webhook.

First, we need to properly interpret the incoming Slack webhook. The symfony/webhook component and symfony/remote-event component work together to provide a robust and secure way to handle webhooks. The Webhook component receives the HTTP request, validates it, and then creates a RemoteEvent object from the request payload. We’ll create a RemoteEvent named slack_webhook_processing.

The RemoteEvent object serves as an abstraction for the external event, containing a unique $id, a $name (e.g., slack_webhook_processing), and a $payload with all incoming data. This architecture decouples event processing logic from webhook reception and validation, ensuring clean, maintainable, and testable code.

Using Symfony Messenger for Asynchronous Slack Notification Handling

To ensure our system is performant and responsive, we’ll process the incoming Slack notifications asynchronously using Symfony Messenger. This means our webhook controller can immediately return a 200 OK response to Slack, while the actual processing — like communicating with the LLM service — happens in the background. This process involves two key components: a message that represents the data we want to process and a handler that contains the business logic to act on that message.

Actionable Step 3: Create the Message and Handler

1. Creating the Message: First, let’s create a new message class AIAgentActionMessage. This message will encapsulate the necessary data from the Slack webhook payload, which our handler will need to perform its task. A good practice is to make the message class an immutable data object.

namespace App\Message\Command; use App\DTO\DataCollection;
use Symfony\Component\Notifier\Notification\Notification; readonly class AIAgentActionMessage { public function __construct( private DataCollection $dataCollection, private string $prompt, private string $from, private string $replyTo, private string $subject, private string $notificationImportance = Notification::IMPORTANCE_MEDIUM ) { } public function getDataCollection(): DataCollection { return $this->dataCollection; } public function getPrompt(): string { return $this->prompt; } public function getFrom(): string { return $this->from; } public function getReplyTo(): string { return $this->replyTo; } public function getSubject(): string { return $this->subject; } public function getNotificationImportance(): string { return $this->notificationImportance; }
}

Now, in our RemoteEvent consumer, we’ll dispatch this message to the message bus:

namespace App\RemoteEvent; use App\DTO\DataCollection;
use App\DTO\Slack\SlackEvent;
use App\DTO\SlackMessage;
use App\Message\Command\AIAgentActionMessage;
use Symfony\Component\Messenger\Envelope;
use Symfony\Component\Messenger\MessageBusInterface;
use Symfony\Component\RemoteEvent\Attribute\AsRemoteEventConsumer;
use Symfony\Component\RemoteEvent\Consumer\ConsumerInterface;
use Symfony\Component\RemoteEvent\RemoteEvent; #[AsRemoteEventConsumer('slack_webhook_processing')]
final readonly class SlackWebhookConsumer implements ConsumerInterface
{ public function __construct(private MessageBusInterface $messageBus) { } public function consume(RemoteEvent $event): void { if (array_key_exists('entity', $event->getPayload()) && ($event->getPayload()['entity'] instanceof SlackEvent)) { $entity = $event->getPayload()['entity']; $slackCollection = new DataCollection( new SlackMessage( 'New Slack message', $entity->getEvent()->getUser(), $entity->getEvent()->getTeam(), $entity->getEvent()->getText(), $entity->getEvent()->getClientMsgId() ) ); $this->messageBus->dispatch( new Envelope( new AIAgentActionMessage( $slackCollection, 'I have slack message. Please generate reply it into a concise overview (100-150 words) focusing on key decisions, action items, and deadlines. Here’s the slack message content:', $entity->getEvent()->getTeam(), $entity->getEvent()->getUser(), '' ) ) ); } }
}

2. Creating the Message Handler: The handler is a service that “listens” for messages of a specific type (AIAgentActionMessage in our case) and executes the logic. This is where we’ll integrate the existing LLM service and the Notifier component.

The handler AIAgentActionMessageHandler will receive the AIAgentActionMessage, use the injected LLM service (GeminiAIAgentService or OpenAIAgentService) to get a response, and then use the Notifier to send the answer back to Slack.

namespace App\Handler\Command; use App\DTO\MailMessage;
use App\Message\Command\AIAgentActionMessage;
use App\Message\Command\NotifySummarizedMessage;
use App\Service\AIAgentService;
use App\Service\AIProvider\GeminiAIAgentService;
use Symfony\Component\Messenger\Attribute\AsMessageHandler;
use Symfony\Component\Messenger\Envelope;
use Symfony\Component\Messenger\MessageBusInterface; #[AsMessageHandler(bus: 'core.command.bus', fromTransport: 'main.transport')]
readonly class AIAgentActionMessageHandler
{ public function __construct( private AIAgentService $aiAgentService, private GeminiAIAgentService $geminiAIAgentService, protected MessageBusInterface $messageBus ){ } public function __invoke(AIAgentActionMessage $message): void { $result = $this->aiAgentService->action($this->geminiAIAgentService, $message->getDataCollection(), $message->getPrompt()); if (!is_null($result)) { $this->messageBus->dispatch( new Envelope( new NotifySummarizedMessage( new MailMessage( $message->getSubject(), $message->getFrom(), $message->getReplyTo(), $result, null ), $message->getNotificationImportance() ) ) ); } }
}

Real-World Example: Automated Support Bot

Imagine a scenario where a user posts a common query like “How do I reset my password?” in a Slack support channel. Our proactive agent, upon receiving this message via the Slack webhook, dispatches an AIAgentActionMessage. The AIAgentActionMessageHandler then processes this message asynchronously. It can query a large language model (LLM) with the user’s question. The LLM would then generate an appropriate response, perhaps providing a direct link to the password reset page or a step-by-step guide. Finally, the Symfony Notifier component dispatches this LLM-generated answer back to the Slack channel as a high-importance notification, providing an instant, automated reply to the user, freeing up human support agents for more complex issues.

By using this asynchronous approach with Symfony Messenger, we ensure that our application remains highly responsive, even when dealing with potentially slow external services like a large language model. It’s a key architectural decision for building a robust and scalable “Proactive Agent.” Now that our code is complete, we’re ready to deploy and run our application. For our Proactive Agent system, we’ll use a containerized approach with Docker Compose, which simplifies the process of managing both our Symfony application and its dependencies, such as a database or message broker.

Conclusion: From Passive Listener to Proactive Agent

In this two-part series, we’ve transformed a simple webhook receiver into a powerful real-time auto-answer system. We began by establishing the foundation: listening for events from Slack using a Symfony controller and symfony/webhook. In this article, we completed the communication loop by building the outbound messaging system.

We leveraged Slack Incoming Webhooks to create a secure, one-way channel for our application to send messages back to users. By integrating Symfony Messenger, we ensured our system is asynchronous and highly performant, offloading heavy processing tasks like communicating with an LLM to the background. Finally, we used the Symfony Notifier component to create a clean, abstract, and scalable way to deliver our automated responses.

The result is a robust, event-driven application that not only detects user activity but proactively responds to it. This “Proactive Agent” is a prime example of how modern, decoupled architecture can be used to build intelligent and responsive applications. The principles we’ve applied — asynchronous processing, message-based communication, and service abstraction — are foundational to modern application development. You can take this foundation and build upon it: integrate a more complex routing system, connect to a database to provide personalized answers, or even add more services to your “Proactive Agent” to perform complex tasks with different LLM Models. The possibilities are endless.

Discover Solutions and Continue Building

I am ready to provide code examples for:

• curl: Demonstrating a direct command-line approach.
• symfony/http-client: Using Symfony’s built-in, high-performance HTTP client.
• Guzzle: The most popular standalone PHP HTTP client.
• Dynamic Symfony Notifier Channels: Showing how to programmatically create multiple notification channels without notifier.yaml.

Just let me know which examples you’d like to see, and I will prepare them for you. Stay tuned — and let’s keep the conversation going!

Frequently Asked Questions