How to Use Slack Incoming and Outgoing Webhooks for Real-Time AI Agents

Now our application is containerized and ready for deployment, let’s expand its capabilities by integrating a new input source. Slack is an excellent choice for this.

Integrating Slack for Real-Time Communications

Imagine a scenario where we want to receive real-time notifications for new messages in specific Slack channels. This allows us to process these messages using Large Language Models (LLMs) to generate summaries or draft replies. This new functionality will work in tandem with our existing AI agent, which continues to poll mailboxes.

This integration will be a cornerstone of our Proactive Agent system. By simultaneously monitoring Slack and email, our application becomes a centralized hub for communications, ensuring no message is missed and every query is handled promptly. This dual-source approach demonstrates the power and flexibility of a well-architected system, combining both traditional and modern communication platforms for a comprehensive solution.

To get notifications about new Slack messages, we can use outgoing Webhooks. A Webhook is a user-defined HTTP callback that is triggered by an event in a source system. When the event occurs, the source system makes an HTTP/HTTPS request to the URL configured in the Webhook.

How Slack Webhooks Works

In the context of Slack, an outgoing Webhook is configured for a specific channel or workspace. When a message is posted or event achieved that meets a certain criteria (e.g., a specific keyword, pattern), Slack sends an HTTP POST request to a designated URL. This URL is the endpoint of our application, which then processes the incoming data.

This mechanism is highly efficient because it’s event-driven. Instead of our application constantly polling Slack for new messages (which is resource-intensive and inefficient), Slack proactively “pushes” the information to us as soon as an event happens. This is the foundation for building a reactive and intelligent system.

Why Choose Webhooks?

Real-time updates: Get messages as they happen, enabling immediate action.

Reduced resource usage: Our application doesn’t need to poll Slack, saving API calls and server resources.

Simple integration: Webhooks are a standard and straightforward way to connect different services.

This approach is crucial for building a Proactive Agent that responds instantly to new communications, whether they originate from Slack or other sources like email.

Incoming and Outgoing Webhooks

Yes, Slack has both incoming and outgoing webhooks. These are two distinct mechanisms that serve different purposes in a communication workflow.

Incoming Webhooks

What they are: This is the most common type of webhook in Slack. They allow external applications to send (push) messages into a Slack channel.

Slack provides a unique URL. Your application makes an HTTP POST request to this URL, sending a JSON payload with the message text and formatting.

Incoming Webhooks used for notifications, alerts, and automated messages. For example, to send notifications about new GitHub commits, deployment statuses, or messages from our Proactive AI Agent back into Slack.

Outgoing Webhooks

This is a legacy mechanism that allows Slack to send (push) data to an external application when a specific event occurs in a channel.

You configure an outgoing webhook by specifying your application’s URL and trigger words or events. When a user in a Slack channel posts a message containing one of these words, Slack makes an HTTP POST request to your application’s URL.

Outgoing Webhooks used for creating interactive bots and automations that react to specific commands or keywords.

In our scenario, we set up an outgoing webhook with a trigger like summary so our agent can receive and process the message to generate a summary.

Key Difference

Incoming Webhooks are used for sending messages to Slack (from an external source).

Outgoing Webhooks are used for receiving messages from Slack (to an external source), but only based on a specific trigger.

In the context of our article about the “Proactive Agent”, we use an outgoing webhook to receive messages from Slack for processing and an incoming webhook to send responses back to Slack.

Step-by-Step Guide to Creating a Slack App

To enable Slack to send us webhook events, we have to first create an application in the developer portal and install it to the Slack workspace or a specific channel from which we want to receive notifications.

Access the Slack API website: Navigate to https://api.slack.com/apps.

1. Click on “Create an App” and choose to build it “From scratch”. Give your application a descriptive name and select the Slack workspace where you’ll be developing and testing it. This is where you’ll install the app to get the webhook URL.
2. Enable Event Subscriptions: In your app’s settings, navigate to the “Event Subscriptions” section and turn on “Enable Events”.
3. Provide a Request URL: You must provide a publicly accessible URL for your application. This is the endpoint where Slack will send event payloads. Slack will perform a one-time URL verification check, where your application must respond with the challenge value from Slack’s request. We’ll create this endpoint in our Symfony app.
4. Subscribe to Bot Events: Scroll down to the “Subscribe to bot events” section. Click “Add Bot User Event” and select the message.channels event. This tells Slack to send your app a payload for every message posted in a public channel.
5. Request Scopes: To receive these events, your bot will need the appropriate permissions. In the “OAuth & Permissions” section, add the channels:history scope to your bot token. This grants your app the ability to view messages in public channels.
6. Reinstall Your App: After adding new scopes, you have to reinstall your app to the workspace for the changes to take effect.

By following these steps, our proactive agent will receive a full JSON payload for every new message in the subscribed channels, providing more context and flexibility than the legacy trigger-word method. This modern approach is the foundation for building advanced, AI-powered applications.

Handling Webhook Validation

It’s time to create an endpoint to handle the response for our endpoint validation request. We have two options for working with webhooks on the Symfony side: we can handle it at the controller level or use the symfony/webhook component. In this article, we’ll focus on working at the controller level. In a future post, I’ll show you how to do this using the Symfony Webhook Component.

When you configure your endpoint URL in Slack’s Event Subscriptions, Slack sends an initial verification request to confirm that the URL is valid and belongs to your application. This request is a simple HTTP POST request with a JSON body that includes a challenge parameter. Our endpoint must respond with the exact challenge value from the request body.

To handle the webhook request properly, we have to not only receive the payload but also validate its correctness. To facilitate this, we’ll prepare Data Transfer Objects (DTOs) and install two key Symfony components: symfony/validator and symfony/serializer-pack.

Why These Components Are Essential

symfony/validator: This component provides a robust framework for validating data against a set of rules. Instead of manually writing if-else statements to check every field, we can define validation constraints (e.g., NotBlank, Type, Length) directly on our DTO properties. This makes our code cleaner, more readable, and less prone to errors.

symfony/serializer-pack: This component bundle provides everything we need to serialize (turn objects into arrays/JSON) and deserialize (turn JSON/arrays into objects) data. We’ll use the deserializer to automatically convert the incoming JSON payload from Slack into a validated DTO object. This process automates the tedious task of mapping data fields, ensuring the payload structure matches our expectations.

And now we’re ready to use the more advanced collections that Doctrine offers. We won’t install the entire Doctrine component just yet; instead, we’ll install only the package for working with collections.

While PHP arrays are versatile, they lack some advanced features like type-hinting, immutability, and specialized methods for filtering or mapping. Doctrine Collections provide a powerful, object-oriented wrapper around arrays, giving us a more robust and predictable way to manage data. This is particularly useful for our Proactive Agent system, where we’ll be dealing with lists of messages, users, or other data payloads.

This small but impactful changes will significantly improve how we manage data within our application, making our agent’s logic more robust and easier to maintain.

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

composer require doctrine/collections 

composer require symfony/validator 

composer require symfony/serializer-pack 

The Workflow for Validating a Webhook Payload

1. Receive the Request: Our Symfony controller receives the HTTP POST request from Slack.
2. Deserialize to DTO: We use the serializer to transform the JSON payload into our predefined DTO object.
3. Validate the DTO: The validator component checks the DTO’s properties against the defined constraints.
4. Handle Errors: If validation fails, we return an error response (e.g., a 400 Bad Request) to Slack.
5. Process Valid Data: If validation succeeds, our application can safely proceed with processing the webhook data, knowing that it’s in the correct format.

This structured approach ensures that our application is resilient and only processes data that conforms to our expected format, which is a critical step in building a reliable and secure system.

Handling Diverse Payloads within a Single Controller

We should also consider that our controller and a single route must properly handle different types of payloads, from URL validation to the working event payloads we’ve subscribed to.

This is a key requirement for a robust webhook endpoint. A single route needs to be smart enough to differentiate between a one-time URL verification request and a live event notification. Our controller should be able to process each request type accordingly.

As previously discussed, the initial URL verification payload from Slack contains a unique challenge key. All subsequent event payloads contain an event key that holds the actual message data. Our controller must check for the presence of these keys to determine the nature of the request.

Typical Slack URL Validation Request

Okay, let’s create a DTO to validate the URL verification request from Slack. First, here is what a typical Slack URL validation request payload looks like.

When you enable Event Subscriptions, Slack sends a POST request to your endpoint with a JSON payload that contains three key fields: token, challenge, and type.

{   "token": "Jhj5...z412",   "challenge": "3eZbr...",   "type": "url_verification" } 

token: A unique token for your application. You can use this to verify the request is from your app.

challenge: A randomly generated string. You must return this exact string in your JSON response to prove you own the URL.

type: The type of event. For validation, this will always be url_verification.

Creating the DTO

Now, we’ll create a DTO that mirrors this structure and includes validation constraints using Symfony’s validator component. We’ll use attributes to define the validation rules directly on the DTO properties.

namespace App\DTO\Slack; use Symfony\Component\Validator\Constraints as Assert;  class SlackUrlValidationRequest {     #[Assert\NotBlank]     #[Assert\Type('string')]     public string $token;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $challenge;      #[Assert\NotBlank]     #[Assert\Type('string')]     #[Assert\EqualTo("url_verification")]     public string $type;      public function getToken(): string     {         return $this->token;     }      public function getChallenge(): string     {         return $this->challenge;     }      public function getType(): string     {         return $this->type;     } } 

This DTO simplifies validation:

Assert\NotBlank: Ensures that the token, challenge, and type fields are present in the request.

Assert\Type(“string”): Confirms that each field’s value is a string, preventing unexpected data types.

Assert\EqualTo(“url_verification”): Specifically validates that the type field matches the required string, so we know we’re handling a URL verification request and not another event type.

By using this DTO, we can deserialize the incoming JSON payload and automatically validate its structure with minimal code in our controller. This makes our endpoint more secure and reliable.

Creating a Controller for Slack Webhook Validation

Perfect, let’s create a controller that uses a SlackUrlValidationRequest DTO to validate the request from Slack. This controller will check if the incoming request is a URL verification request and handle it correctly by returning the challenge code.

We’ll inject the SerializerInterface to deserialize the JSON payload into our DTO and the ValidatorInterface to validate the data. This approach makes the code clean, reliable, and compliant with Symfony standards.

namespace App\Controller;  use App\DTO\Slack\SlackUrlValidationRequest;  use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\HttpKernel\Exception\BadRequestHttpException; use Symfony\Component\Messenger\Envelope; use Symfony\Component\Messenger\MessageBusInterface; use Symfony\Component\Routing\Attribute\Route; use Symfony\Component\Serializer\SerializerInterface; use Symfony\Component\Validator\Validator\ValidatorInterface;  class WebhookController {     #[Route('/webhook/slack', name: 'webhookSlack')]     public function __invoke(Request             $request,                              ValidatorInterface  $validator,                              SerializerInterface $serializer     ): JsonResponse     {          $data = json_decode($request->getContent(), true);          if ($data === null) {             throw new BadRequestHttpException('Invalid JSON.');         }          $dtoClass = SlackUrlValidationRequest::class;          $dto = $serializer->denormalize($data, $dtoClass);          $errors = $validator->validate($dto);          if (count($errors) > 0) {             $errorMessages = [];             foreach ($errors as $error) {                 $errorMessages[] = $error->getPropertyPath() . ': ' . $error->getMessage();             }              return new JsonResponse(['errors' => $errorMessages], Response::HTTP_BAD_REQUEST);         }          switch (get_class($dto)) {             case SlackUrlValidationRequest::class:                 return new JsonResponse($dto->getChallenge());         }          return new JsonResponse(['status' => 'ok'], Response::HTTP_OK);     } } 

This controller now reliably and securely handles verification requests, which is the foundation for our “Proactive Agent.”

Now we can test how our controller works by sending a URL validation message from a server, simulating Slack’s behavior. This check will ensure our endpoint is configured correctly and ready to receive real event data.

Creating a DTO for Slack Event Messages

Now, let’s create a DTO to process and validate the messages that Slack will send us when events occur. Unlike the simple URL validation request, the event payload contains much more data, so we’ll create several DTOs for more effective and modular validation.

Typical Event Request Structure

An event request will contain the token, teamid, apiappid fields, and most importantly, an event object. Inside the event object, you’ll find information about the event type (message, appmention, etc.), the message text, user data, and the channel information.

{     "token": "Jhj5...z412",     "team_id": "T061...R6",     "api_app_id": "A0PN...2",     "event": {         "client_msg_id": "92f...d56",         "type": "message",         "text": "Hey bot, summarize this article for me.",         "user": "U214...97",         "ts": "167...97",         "team": "T061...R6",         "channel": "C0PN...L",         "event_ts": "167...97",         "channel_type": "channel"     },     "type": "event_callback",     "event_id": "Ev08...6",     "event_time": 167...97,     "authorizations": [ ... ] } 

Creating the DTOs for Event Handling

We’ll create a hierarchy of DTO objects to separate the validation of the overall request structure from the specifics of the event itself.

SlackEvent.php (The wrapper DTO for the entire request) \n This DTO will contain the general fields for all events.

namespace App\DTO\Slack;  use Doctrine\Common\Collections\ArrayCollection; use Symfony\Component\Validator\Constraints as Assert;  class SlackEvent {     #[Assert\NotBlank]     #[Assert\Type('string')]     public string $token;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $team_id;      #[Assert\Type('string')]     #[Assert\Nullable]     public ?string $context_team_id;      #[Assert\Type('string')]     #[Assert\Nullable]     public ?string $context_enterprise_id;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $api_app_id;      #[Assert\NotBlank]     public SlackEventData $event;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $type;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $event_id;      #[Assert\NotBlank]     #[Assert\Type('integer')]     public int $event_time;      public ArrayCollection $authorizations;      #[Assert\Type('bool')]     public bool $is_ext_shared_channel;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $event_context;      public function __construct(){         $this->authorizations = new ArrayCollection();     }      public function getToken(): string     {         return $this->token;     }      public function getTeamId(): string     {         return $this->team_id;     }      public function getContextTeamId(): ?string     {         return $this->context_team_id;     }      public function getContextEnterpriseId(): ?string     {         return $this->context_enterprise_id;     }      public function getApiAppId(): string     {         return $this->api_app_id;     }      public function getEvent(): SlackEventData     {         return $this->event;     }      public function getType(): string     {         return $this->type;     }      public function getEventId(): string     {         return $this->event_id;     }      public function getEventTime(): int     {         return $this->event_time;     }      public function getAuthorizations(): ArrayCollection     {         return $this->authorizations;     }      public function isIsExtSharedChannel(): bool     {         return $this->is_ext_shared_channel;     }      public function getEventContext(): string     {         return $this->event_context;     } } 

SlackEventData.php (The DTO for the event object) \n This DTO will contain the data specific to the event itself.

namespace App\DTO\Slack;  use Symfony\Component\Validator\Constraints as Assert;  class SlackEventData {     #[Assert\NotBlank]     #[Assert\Type("string")]     public string $user;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $type;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $ts;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $client_msg_id;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $text;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $team;      #[Assert\NotBlank]     #[Assert\Type("array")]     #[Assert\All([         new Assert\Type("array"),         new Assert\Collection([             'fields' => [                 'type' => [                     'constraints' => [                         new Assert\NotBlank(),                         new Assert\Type("string")                     ],                 ],                 'block_id' => [                     'constraints' => [                         new Assert\NotBlank(),                         new Assert\Type("string")                     ],                 ],                 'elements' => [                     'constraints' => [                         new Assert\Type("array")                     ],                 ],             ],         ]),     ])]     public array $blocks;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $channel;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $event_ts;      #[Assert\NotBlank]     #[Assert\Type("string")]     public string $channel_type;      public function getUser(): string     {         return $this->user;     }      public function getType(): string     {         return $this->type;     }      public function getTs(): string     {         return $this->ts;     }      public function getClientMsgId(): string     {         return $this->client_msg_id;     }      public function getText(): string     {         return $this->text;     }      public function getTeam(): string     {         return $this->team;     }      public function getBlocks(): array     {         return $this->blocks;     }      public function getChannel(): string     {         return $this->channel;     }      public function getEventTs(): string     {         return $this->event_ts;     }      public function getChannelType(): string     {         return $this->channel_type;     }      public function getTsDateTime(): \DateTimeImmutable{         // Separate seconds and microseconds         list($seconds, $microseconds) = explode('.', $this->getTs());          // Convert to DateTime with microseconds         $dateTime = (new \DateTime())->setTimestamp($seconds);         $dateTime->modify("+$microseconds microseconds");          return \DateTimeImmutable::createFromMutable($dateTime);     } } 

SlackEventAuthorization.php (The DTO for the authorizations collection) \n This DTO will contain the data specific to the authorizations collection.

namespace App\DTO\Slack;  use Symfony\Component\Validator\Constraints as Assert;  class SlackEventAuthorization {     #[Assert\Type('string')]     #[Assert\Nullable]     public ?string $enterprise_id;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $team_id;      #[Assert\NotBlank]     #[Assert\Type('string')]     public string $user_id;      #[Assert\NotBlank]     #[Assert\Type('bool')]     public bool $is_bot;      #[Assert\NotBlank]     #[Assert\Type('bool')]     public bool $is_enterprise_install;      public function getEnterpriseId(): ?string     {         return $this->enterprise_id;     }      public function getTeamId(): string     {         return $this->team_id;     }      public function getUserId(): string     {         return $this->user_id;     }      public function isIsBot(): bool     {         return $this->is_bot;     }      public function isIsEnterpriseInstall(): bool     {         return $this->is_enterprise_install;     } } 

We use three DTOs to separate the validation. SlackEvent validates the overall request structure, while SlackEventData validates the content of the nested event object and SlackEventAuthorization validates authorization collection.

This approach gives us flexibility. If in the future we want to handle another event type (e.g., appmention or reactionadded), we simply create a new DTO for that event type and use it for validation.

With these DTOs, our controller will be able to reliably receive and validate messages from Slack, which is a critical step in building our “Proactive Agent.”

Creating a Custom Denormalizer

In its default configuration, the Symfony Serializer cannot automatically deserialize complex, nested objects like SlackEventAuthorization. To correctly map the array of authorization objects from the Slack payload into our DTO, we need a custom denormalizer.

A denormalizer is a component that converts structured data (like an array or a JSON object) into a PHP object. The default serializer can handle simple properties, but it doesn’t know how to handle complex structures like an array of custom DTOs nested within another DTO. By creating a custom denormalizer, we explicitly tell the serializer how to map the incoming data to our specific object.

namespace App\Serializer\Denormalizer;  use App\DTO\Slack\SlackEvent; use App\DTO\Slack\SlackEventAuthorization; use Symfony\Component\Serializer\Normalizer\DenormalizerInterface; use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;  class SlackEventDenormalizer implements DenormalizerInterface {     private ObjectNormalizer $normalizer;      public function __construct(ObjectNormalizer $normalizer)     {         $this->normalizer = $normalizer;     }      public function denormalize($data, string $type, string $format = null, array $context = []): mixed     {          $entity = $this->normalizer->denormalize($data, SlackEvent::class, $format, $context);          if (isset($data['authorizations']) && is_array($data['authorizations'])) {             foreach ($data['authorizations'] as $authorizationData) {                  $authorization = $this->normalizer->denormalize($authorizationData, SlackEventAuthorization::class, $format, $context);                 $entity->getAuthorizations()->add($authorization);             }         }          return $entity;     }      public function supportsDenormalization($data, string $type, string $format = null, array $context = []): bool     {         return $type === SlackEvent::class;     }      public function getSupportedTypes(?string $format): array     {         return [SlackEvent::class => true];     } } 

Updated Controller for Multiple Event Types

We are now ready to modify our webhook controller to handle two event types: url_verification and event notifications. We will update the controller to use a switch statement to route the requests based on the type field in the payload, making our single endpoint flexible and robust.

The updated controller will check the type of the incoming JSON payload. If it’s a urlverification request, it will perform the validation we’ve already set up. If it’s an eventcallback, it will begin the process of handling the actual Slack event.

namespace App\DTO;  class SlackMessage extends MailMessage implements DataCollectionItemInterface { } 

namespace App\Controller;  use App\DTO\DataCollection; use App\DTO\Slack\SlackEvent; use App\DTO\Slack\SlackUrlValidationRequest; use App\DTO\SlackMessage; use App\Message\Command\AIAgentSummarizeMessage; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\HttpKernel\Exception\BadRequestHttpException; use Symfony\Component\Messenger\Envelope; use Symfony\Component\Messenger\MessageBusInterface; use Symfony\Component\Routing\Attribute\Route; use Symfony\Component\Serializer\SerializerInterface; use Symfony\Component\Validator\Validator\ValidatorInterface;  class WebhookController {     #[Route('/webhook/slack', name: 'webhookSlack')]     public function __invoke(Request             $request,                              ValidatorInterface  $validator,                              SerializerInterface $serializer,                              MessageBusInterface $messageBus     ): JsonResponse     {          $data = json_decode($request->getContent(), true);          if ($data === null) {             throw new BadRequestHttpException('Invalid JSON.');         }          $dtoClass = SlackUrlValidationRequest::class;          if (array_key_exists('type', $data) && $data['type'] === 'event_callback') {             $dtoClass = SlackEvent::class;         }          $dto = $serializer->denormalize($data, $dtoClass);          $errors = $validator->validate($dto);          if (count($errors) > 0) {             $errorMessages = [];             foreach ($errors as $error) {                 $errorMessages[] = $error->getPropertyPath() . ': ' . $error->getMessage();             }              return new JsonResponse(['errors' => $errorMessages], Response::HTTP_BAD_REQUEST);         }          switch (get_class($dto)) {             case SlackUrlValidationRequest::class:                 return new JsonResponse($dto->getChallenge());             case SlackEvent::class :                  $emailCollection = new DataCollection(                     new SlackMessage(                         'New Slack message',                         $dto->getEvent()->getUser(),                         $dto->getEvent()->getTeam(),                         $dto->getEvent()->getText(),                         $dto->getEvent()->getTs(),                         $dto->getEvent()->getClientMsgId()                     )                 );                  $messageBus->dispatch(                     new Envelope(                         new AIAgentSummarizeMessage(                             $emailCollection,                             'I have slack message. Please summarize it into a concise overview (100-150 words) focusing on key decisions, action items, and deadlines. Here’s the slack message content:'                         )                     )                 );                  break;         }          return new JsonResponse(['status' => 'ok'], Response::HTTP_OK);     } } 

Leveraging Inheritance for a Unified Workflow

We’ve created a new SlackMessage class that inherits from MailMessage. This is a significant design decision that allows us to send Slack messages to our message bus for standard asynchronous processing by our AI agent, using the existing workflow.

By extending MailMessage, the SlackMessage class automatically conforms to the same message contract required by our message bus and AI agent. This means we don’t need to build a new, separate processing pipeline for Slack. Instead, we can simply pass an instance of SlackMessage to the bus, and the system will handle it just like a regular email.

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

The SlackMessage class contains Slack-specific data but inherits the core properties needed for our agent, such as the message content. And we’ll transform it to Interfaces approach.

We can now dispatch a SlackMessage object to the Symfony Message Bus on a standard async transport. The bus doesn’t need to know the specific type; it just recognizes it as a valid message.

The AI agent, which is already configured to consume messages from the bus and process MailMessage objects, can seamlessly handle SlackMessage objects without any changes to its core logic. The agent can then use the message’s content to perform its tasks, such as summarization or generating a reply.

This approach is highly efficient because it avoids code duplication and keeps our system’s architecture clean and scalable. It demonstrates how our Proactive Agent can easily integrate new communication channels, ensuring all messages — whether from email or Slack — are processed through a single, intelligent workflow.

In our next articles, we’ll explore how to simplify our code by using the symfony/webhook component. This powerful tool provides a higher-level abstraction for handling webhook requests, eliminating the need for some of the manual controller and validation logic we’ve built so far.

We will then dive into creating a separate, dedicated workflow for generating automatic replies to Slack messages.

This will involve:

Advanced Message Processing: Building on our existing architecture, we’ll design a system that can identify messages requiring a response.

Integrating an LLM: We’ll demonstrate how to use a Large Language Model to formulate intelligent, context-aware answers.

Sending a Reply: Finally, we’ll use a Slack API client to send the generated response back to the user, closing the communication loop and completing our Proactive Agent system.

Stay tuned as we continue to build out this powerful real-time communication platform.