Azure AI Foundry Agent: How to Add Memory

Fatima Abdillahi 0 Reputation points
2025-06-12T03:53:07.8833333+00:00

Hello,

I’ve developed a multi-agent system, and I’ve noticed a difference in behavior between the Playground environment and when the agent is accessed via a webhook.

In the Playground, the agent is able to retain context across interactions within the same thread meaning it can refer back to previous responses and carry out multi-step workflows (e.g., conducting research and then updating a database upon user approval).

However, when I connect the agent to a webhook and communicate through it, the agent seems to lose context between steps. It no longer recalls the previous interaction, making it unable to complete the full workflow as expected.

How can I ensure that the agent maintains context across interactions when triggered via a webhook? I tried keeping the connection open, but this resulted in the webhook repeatedly pinging the agent, causing it to send unsolicited messages to the user without being explicitly invoked.

Any guidance on maintaining thread continuity or session state in webhook-triggered flows would be greatly appreciated.

Thank you!

My architecture is as follows: Slack > Function App Webhook > Azure Foundry Agent > Function App Webhook > Back to Slack

Azure AI services
Azure AI services
A group of Azure services, SDKs, and APIs designed to make apps more intelligent, engaging, and discoverable.
3,602 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Prashanth Veeragoni 4,930 Reputation points Microsoft External Staff Moderator
    2025-06-12T05:23:42.15+00:00

    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!  


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.