Hi Fatima Abdillahi,
You're encountering a context continuity issue with Azure AI Foundry agents when moving from the Playground (which maintains thread context) to a webhook integration (where context is lost between messages).
Root Cause:
In Azure AI Foundry, context is tied to a Thread ID. In the Playground, all user inputs within a session belong to the same thread. However, when you're using a webhook (like in your Slack → Function App → Foundry → Function App → Slack flow), you're likely not persisting the Thread ID between webhook invocations.
So, even though you're invoking the same agent, each call creates a new thread, meaning the agent has no memory of previous steps.
Solution: Persist and Reuse the Thread ID:
To maintain memory across webhook-triggered interactions, follow these steps:
1.Create or Retrieve the Thread ID
You have two options:
· Create a thread only once, when the user first interacts.
· Retrieve and reuse the same Thread ID for all future messages from that user in that session.
Code Example:
# When initiating a new conversation
thread = client.thread.create()
# Store thread.id somewhere (like in Redis, CosmosDB, or session state)
store_thread_id(user_id, thread.id)
2.Send messages to the same thread
Use the stored thread.id when posting follow-up messages:
thread_id = get_stored_thread_id(user_id)
client.message.create(
thread_id=thread_id,
content="User's follow-up message"
)
This way, Azure Foundry understands all interactions are part of the same conversation.
3.Store Thread State
In your case (Slack > Function App Webhook > Foundry), you should:
· Extract the user/session ID from Slack message payload.
· Use that ID to store and retrieve the corresponding thread_id in a fast store (e.g., Redis).
· Use the thread ID in all subsequent messages from that user/session.
Common Pitfall – Open Webhook Loops
You mentioned keeping the connection open led to unsolicited messages.
This happens if the agent auto-responds to itself in a loop. To prevent:
· Only send messages back to Slack when a user message arrives, not every time the agent updates.
· Implement a state check to filter out agent-initiated callbacks unless explicitly requested.
Final Architecture Guidance:
Updated Flow with Thread Persistence:
Slack
↓
Function App Webhook
↳ Extract user/session ID
↳ Retrieve or Create thread ID
↳ Send message to Foundry agent using thread ID
↓
Azure Foundry Agent (maintains context via thread ID)
↓
Function App Webhook
↳ Parse response
↳ Send appropriate response back to Slack
Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.
**
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Thank you!