{"id":2667,"date":"2026-10-08T18:04:35","date_gmt":"2026-10-08T18:04:35","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/?p=2667"},"modified":"2026-10-12T20:35:51","modified_gmt":"2026-10-12T20:35:51","slug":"ai-103-agents-tools-and-conversation-memory","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/ai-103-agents-tools-and-conversation-memory\/","title":{"rendered":"Microsoft AI-103: Agents, Tools, and Conversation Memory"},"content":{"rendered":"

AI-103<\/a> puts agentic systems near the center of the certification. A Foundry agent<\/a> is not simply a chat model with a longer prompt. It combines a model, instructions, tools, state, and runtime behavior so the application can choose actions and continue work across turns. Candidates need to understand how those pieces fit together and, just as important, how they differ.<\/p>\n

The Microsoft certification<\/a> context is useful, but scenario questions are usually decided by a specific requirement: does the agent need a tool, a conversation, long-term memory, retrieval, or deterministic application state? Mixing those concepts leads to designs that are expensive and hard to govern.<\/p>\n

Agents, conversations, and responses are separate runtime concepts<\/h2>\n

In the current Foundry Agent Service model, an agent defines the model, instructions, and available tools. A conversation provides stateful history across turns. A response is the result of processing input in that context. This separation matters because an application can reuse an agent definition across many independent conversations without merging their histories.<\/p>\n

Conversation state is appropriate when the system must preserve the messages, tool calls, and outputs that make one interaction coherent. The application should persist the conversation identifier securely and associate it with the correct user or business record. Reconstructing state by prepending only the last model answer loses important context and can produce inconsistent behavior.<\/p>\n

State also has security consequences. A conversation identifier is effectively a pointer to history. Applications must prevent one user from resuming another user\u2019s conversation and should apply retention rules that match the sensitivity of stored interactions.<\/p>\n

Tools turn reasoning into capability<\/h2>\n

Tools let an agent retrieve information, perform calculations, search files, call APIs, or invoke enterprise functions. Foundry provides hosted tools such as web search, file search, code interpreter, and memory, and it supports custom functions, OpenAPI-based operations, and MCP-connected capabilities. The correct tool is the one whose semantics match the required action.<\/p>\n

A tool schema is part of the control surface. Use narrow names, clear descriptions, constrained parameters, and structured results. If a tool can issue a refund, do not expose a generic \u201cexecute arbitrary customer operation\u201d interface. Smaller capabilities are easier for the model to select correctly and easier for policy code to authorize.<\/p>\n

The application should validate tool arguments before execution. The model can propose a call; deterministic code should enforce types, ranges, identity, permissions, and business rules. This is especially important for write operations, where a plausible but incorrect argument can change durable state.<\/p>\n

Conversation history and long-term memory are not the same<\/h2>\n

Conversation history preserves what happened in an interaction. Long-term memory preserves selected information across sessions. Foundry\u2019s managed memory capabilities can retain user preferences, summarized conversation context, and reusable procedural information. That can improve continuity, but it should be enabled because the use case needs it, not because persistence sounds intelligent.<\/p>\n

Memory introduces lifecycle questions: what is worth remembering, how long it should remain, who can read it, how a user can correct or remove it, and how conflicting information is reconciled. Stable preferences such as language or accessibility needs are different from sensitive transient facts. A professional design defines memory policy before collecting durable information.<\/p>\n

For knowledge that belongs to the organization rather than the individual, a knowledge base or retrieval system is usually a better fit. Product documentation should not become \u201cmemory\u201d merely because the agent uses it repeatedly. Keep user-specific continuity separate from shared authoritative knowledge.<\/p>\n

Tool selection needs observable failure handling<\/h2>\n

Agent failures are often tool failures in disguise. The model may choose the wrong tool, provide invalid parameters, misinterpret the result, or retry an operation that should not be repeated. Instrument the agent so traces show the sequence of model decisions, tool calls, timings, and errors. Without that evidence, teams tend to blame the final model response instead of locating the actual failure.<\/p>\n

Design tools to return structured errors. Authentication failure, authorization denial, rate limiting, validation failure, timeout, and not-found conditions should be distinguishable. That allows the runtime or model to decide whether to retry, ask the user for information, choose a different tool, or escalate.<\/p>\n

For irreversible actions, approval is a first-class control. A tool can prepare a change while a human or deterministic policy authorizes the final commit. This pattern keeps agentic flexibility where it helps and protects business state where mistakes are costly.<\/p>\n

Use memory and tools to reduce prompt bloat<\/h2>\n

A common anti-pattern is placing every instruction, user fact, document, and tool result into an ever-growing prompt. That increases token use and can reduce relevance. Conversation history should contain the interaction state that matters; memory should surface durable user context; retrieval should provide current knowledge; tools should obtain live information or perform actions. Each mechanism exists for a different reason.<\/p>\n

Compaction and summarization can help when conversations grow, but they should preserve facts and commitments that matter to the workflow. Do not rely on an unconstrained summary to preserve every legal or transactional detail. Critical state belongs in structured application data, not only in natural-language conversation history.<\/p>\n

This separation also improves testing. You can evaluate retrieval quality, tool correctness, memory relevance, and conversational reasoning independently instead of treating the entire agent as one opaque component.<\/p>\n

Read AI-103 scenarios by the state they require<\/h2>\n

When a scenario says the user returns days later and needs the complete interaction history, think about persistent conversation state. When it says the agent should remember a preference across new conversations, think about long-term memory. When it needs current public information, calculations, or user-provided documents, choose the corresponding tool. When the requirement is a business record that must be authoritative, use application storage rather than model memory.<\/p>\n

Authentication around these features should align with Microsoft Entra ID<\/a> and Azure RBAC rather than being improvised inside prompts. Identity and state are application concerns even when the agent is the user-facing interface.<\/p>\n

The strongest designs make each layer explicit: the agent reasons, the conversation carries interaction history, memory provides selected durable context, retrieval supplies authoritative knowledge, tools expose bounded capabilities, and deterministic services own security and durable business state. That mental model maps closely to how AI-103 tests modern agent engineering.<\/p>\n

Keep authoritative state outside the conversation<\/h2>\n

Agents can remember context, but business truth should live in systems designed for durable state. Order status, approval state, account balances, workflow checkpoints, and authorization decisions should be read from or written to authoritative services. Conversation history can explain how the user arrived at a request; it should not silently become the source of record.<\/p>\n

This distinction improves recovery. If a conversation is lost or summarized, the application can reconstruct the important workflow state from durable records. It also makes audits clearer because the final business outcome does not depend on reconstructing what a model happened to remember.<\/p>\n

Design state for privacy and recovery<\/h2>\n

State design should include retention and deletion from the beginning. Conversation history, long-term memory, tool outputs, and business records may have different retention requirements. Keeping them in separate stores with separate policies makes it easier to honor privacy obligations and to remove one category without destroying another.<\/p>\n

Recovery is another reason to separate state types. If an agent process restarts, the application should be able to resume from durable workflow data rather than hoping that a summarized conversation contains every important fact. Persist identifiers, approvals, transaction states, and external record keys explicitly; use natural-language context to support reasoning around that state.<\/p>\n

Finally, verify that memory retrieval itself is scoped correctly. A memory useful for one user, tenant, or case should not leak into another. Treat memory stores and conversation identifiers as security-sensitive references and bind them to authenticated application context before reuse.<\/p>\n

Choose the tool surface carefully<\/h2>\n

Hosted tools are convenient when the capability matches the requirement, but custom tools are appropriate when the business needs a domain-specific contract. A custom function can expose exactly the fields an agent needs and hide internal implementation detail. OpenAPI or MCP can standardize broader capability sets. The architecture should choose the smallest useful surface rather than exposing an entire backend API to the model.<\/p>\n

Tool descriptions deserve the same version control as prompts. Small wording changes can affect when an agent selects a tool. Test positive cases where the tool should be used and negative cases where it should not. If tool choice changes after a model upgrade, the regression suite should reveal it before users do.<\/p>\n

Keep approvals outside model memory<\/h2>\n

Approval state should never exist only as something the agent remembers from a previous turn. Record the approver, timestamp, scope, and exact action in structured application state, then let the agent read that state when deciding what can happen next. This prevents a summary or memory error from turning into an unauthorized operation.<\/p>\n

The same rule applies to consent and policy acknowledgements. Natural-language context can help explain the interaction, but durable authorization facts need deterministic storage and validation. Agents are good at reasoning over state; they should not be the sole custodian of high-impact state.<\/p>\n

Treat every tool result as untrusted input<\/h2>\n

A tool can return malformed data, stale records, adversarial text, or a response that is technically valid but inappropriate for the current user. Validate tool outputs before they become new model context or trigger another action. Check schemas, expected ranges, tenant ownership, and provenance, and separate display text from control data wherever possible. This prevents an external system from smuggling instructions into the reasoning path and makes failures easier to classify. For high-impact tools, retain the original request and normalized result so operators can reconstruct exactly what the agent saw without relying on a conversational summary.<\/p>\n","protected":false},"excerpt":{"rendered":"

AI-103 puts agentic systems near the center of the certification. A Foundry agent is not simply a chat model with a longer prompt. It combines a model, instructions, tools, state, and runtime behavior so the application can choose actions and continue work across turns. Candidates need to understand how those pieces fit together and, just […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-2667","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2667","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=2667"}],"version-history":[{"count":4,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2667\/revisions"}],"predecessor-version":[{"id":3912,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2667\/revisions\/3912"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=2667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=2667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=2667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}