03 — Microsoft Agent Framework and Semantic Kernel

Answer:

Microsoft Agent Framework (MAF) is the open-source SDK for building agents and multi-agent workflows in Python and .NET (a Go SDK exists in a separate repo, in public preview as of late 2026). Microsoft's docs call it the direct successor to both Semantic Kernel (SK) and AutoGen, built by the same teams.

Status, as of late 2026 (check the overview and the repo): MAF announced 1.0 for .NET and Python in April 2026. Some provider packages may still ship as prerelease, so read the package page before pinning. AutoGen is archived, and SK is in maintenance mode, with new feature work going to MAF.

In an interview, say "successor" and "consolidation", not "replacement of everything": SK's vector store and connector layers still matter, and MAF provides a compatibility path for them (see Q8).

Answer:

The loop is the same in every framework (SK, MAF, LangGraph, a hand-rolled ReAct loop):

1. Send instructions, conversation state and tool schemas to the model.
2. If the model returns tool calls, the framework executes them (your code runs, not the model).
3. Append the tool results to the conversation and call the model again.
4. Stop when the model returns a plain answer, or a step/token limit is hit.

Exposing retrieval as a tool, instead of always retrieving before generation, makes retrieval a decision. The agent can skip it for chit-chat, issue several differently-phrased queries, filter by metadata, retry after a weak result, or call a second source (SQL, graph, web). That is the core of agentic RAG, covered in 01_concepts/agentic_orchestration.md.

The costs are real: every iteration adds latency and tokens, the model can pick the wrong tool or loop, and tool output is untrusted text entering the context (Q15). For simple FAQ-style questions, a fixed retrieve-then-generate pipeline is cheaper and more predictable.

Answer:

• Kernel: the dependency-injection container and orchestration hub. It holds AI services (chat completion, embeddings), plugins, and filters.
• Plugin: a named group of functions, for example a SearchPlugin or TimePlugin.
• Function (KernelFunction): a unit of work, either native code (decorated with [KernelFunction] in .NET or @kernel_function in Python) or a prompt template. Its name, description and parameter metadata are sent to the model as the tool schema when function calling is enabled.

Typical flow: register plugins on the kernel, enable automatic function calling in the execution settings, and SK runs the tool-calling loop for you.

The migration guide notes that in SK every agent depends on a Kernel, whereas in MAF you pass tools directly when creating the agent and there is no mandatory plugin wrapper (a class with several tool methods still works). This is the main conceptual simplification when moving over; see Q16.

Answer:

The MAF docs give this rule of thumb:

The docs add a line worth quoting: if you can write a function to handle the task, do that instead of using an agent.

For RAG this maps naturally. A support bot that answers from a knowledge base is usually one agent with a search tool. A document-processing pipeline (classify, extract, validate against retrieved policy, route for approval) is a workflow, where the steps are deterministic and only some nodes call a model. Workflows also give you checkpointing and pause/resume for human review, which a free-running agent loop does not.

Answer:

The Model Context Protocol (MCP) is an open protocol that standardizes how an LLM application connects to external tools, resources and prompts through MCP servers (see the MCP section of 01_concepts/agentic_orchestration.md).

In MAF, agents can call tools and MCP servers: the overview lists "MCP clients for tool integration" as a foundational building block, and the docs have a hosted-MCP-tools page. In practice this means a retrieval service (for example one wrapping Azure AI Search) can be written once as an MCP server and consumed by a MAF agent, a LangGraph agent, or an IDE assistant without per-framework glue.

Interview caveats:

• MCP is a wire protocol, not an orchestration framework; it does not replace MAF, LangGraph or SK.
• Every connected MCP server expands the attack surface. Tool descriptions and tool outputs are untrusted input, so pin servers, scope credentials, and require approval for side-effecting tools (Q12, Q15).
• Client features (auth flows, which transports, hosted versus local) vary by SDK version, so verify against current docs.

Answer:

AutoGen started as Microsoft Research's framework for multi-agent conversation: several LLM agents (plus optional humans and code executors) exchange messages to solve a task, for example a planner, a coder and a critic in a group chat. It popularized patterns such as two-agent chat, group chat with a speaker-selection policy, and code-execution agents. It was layered as Core (event-driven message passing, local and distributed runtimes), AgentChat (a high-level API) and Extensions. AutoGen Studio was a no-code prototyping UI explicitly not meant for production.

Status: the microsoft/autogen README says the project is no longer maintained by Microsoft, with no new features or support, and that new projects should use Microsoft Agent Framework (as of late 2026, verify at github.com/microsoft/autogen). MAF's orchestration patterns (group chat, handoff, magentic and others) are the descendants of that work.

Practical point: do not start a new system on AutoGen, and plan migration for existing ones using the official AutoGen migration guide.

Answer:

Treat the tool as a narrow, typed API, not a raw search box. Design points:

• Few, meaningful parameters: query (string), optional business filters such as product_line or doc_type, and top (bounded, e.g. max 10). Do not let the model pass raw OData filter strings.
• Descriptions matter: the function name, docstring and parameter descriptions are what the model reads to decide when to call it. State what the corpus contains and what it does not.
• Return compact, cited results: chunk text, source title, URL or ID, and the date. Cap total characters so one call cannot flood the context.
• Hybrid search with semantic ranking inside the tool (keyword plus vector, then reranking) so the model does not need to choose a search mode.
• Security trimming server-side: derive the user's group/ACL filter from the authenticated identity in your code, never from a model-supplied argument (Q26).
• Return errors as text the model can act on ("no results; try broader terms"), and do not retry silently forever.

The Semantic Kernel Python vector store can build such a function: collection.create_search_function(...) with search_type="keyword_hybrid" returns a KernelFunction, and .as_agent_framework_tool() converts it for a MAF agent (shown in the official migration guide, semantic-kernel 1.38+). In plain MAF, a typed Python function passed as tools= is enough:

# Pattern from the MAF migration guide (Python, agent-framework 1.x)
def search_policies(query: Annotated[str, "What to look up in HR policies."]) -> str:
    """Search the HR policy knowledge base and return cited passages."""
    return run_hybrid_search(query)   # your Azure AI Search call

agent = chat_client.as_agent(tools=search_policies)

Answer:

SK's Vector Store layer defines a typed data model (key, data and vector properties), collections, and a uniform search / hybrid search API with top, skip, include_vectors and a LINQ/lambda filter that is translated to each store's native filter syntax. Connectors exist for Azure AI Search, Qdrant, Pinecone, PostgreSQL, in-memory and others. Text search plugins wrap a search backend so it can be called as a function from prompts or by the model.

Why it matters: it is a thin portability layer, so swapping the store is mostly a connector change. Limits to know: filter support differs per store (not every store supports negative filters), and the docs flag parts of the layer as preview with possible breaking changes (check each language's status).

Relevance with MAF: the official migration guide shows a collection's create_search_function(...) result converted with .as_agent_framework_tool(), which "works with any Semantic Kernel VectorStore connector". So you can migrate agents first and keep SK's data layer, then replace it later if you choose. The guide describes this as a gradual-migration compatibility layer, so do not treat it as a permanent architecture without checking the roadmap.

Answer:

In current MAF docs the state object is an agent session (AgentSession; agent.create_session() in Python, await agent.CreateSessionAsync() in .NET). Older SK and early MAF material says "thread", so expect both terms. A session can be local (the app holds the history) or service-backed (the provider holds the conversation, continued via a service session ID). Pass it to agent.run(..., session=session) on each turn.

Memory layers to distinguish:

The overview describes "context providers for agent memory", and the Python packages include a Mem0 integration (agent-framework-mem0).

Design cautions: summarize or compact history so long sessions do not blow the context window; scope memories per user and tenant; give users a way to inspect and delete memories (privacy and GDPR); and never store secrets or retrieved confidential text in shared memory. Exact provider APIs change, so verify against the docs before building.

Answer:

The orchestrations docs list five built-in patterns:

Selection heuristic: start with the most deterministic pattern that fits (sequential or concurrent), use handoff when specialists need different tools or instructions, and use group chat or magentic only when the task genuinely needs open-ended collaboration. Also remember a single agent with several tools often beats a multi-agent design on cost and debuggability. Orchestrations also support human-in-the-loop through approval-required tools.

Answer:

Both are interception points around the model and tool loop. Semantic Kernel has filters (function invocation, prompt render, auto function invocation); MAF documents "middleware for intercepting agent actions" and lists middleware in its core building blocks. The idea is the same as HTTP middleware: code runs before and after a call and can inspect, modify, short-circuit or log it.

Useful RAG uses:

• Authorization: block a tool call if the caller lacks a role, or inject the user's ACL filter into search arguments.
• Input and output screening: PII redaction, prompt-injection classifiers, content-safety checks on retrieved text and on the final answer.
• Budget control: count tool calls and tokens per run and stop at a limit.
• Audit logging: record each tool call with arguments, user and result size.
• Caching and rate limiting of expensive retrieval calls.
• Approval gates: pause for human sign-off on sensitive actions.

Pitfall: middleware is code you must test and keep fast, since it runs on every iteration of the loop. Check the current docs for exact class and decorator names, since they differ between SK filters and MAF middleware and between Python and .NET.

Answer:

MAF supports approval-required tools: when the model asks to call such a tool, the run pauses and surfaces an approval request to the caller, and execution continues only after a human approves or rejects. Workflows add "request info" for human input and checkpointing so a long-paused run can be persisted and resumed later (see the human-in-the-loop docs). The Harness agent also mentions "don't-ask-again" approval to reduce prompt fatigue. Exact parameter names vary by SDK version, so look them up rather than recalling them.

When to require approval:

• Actions with side effects: send email, update a claim, issue a refund, write to a database.
• Tools that touch sensitive data scopes.
• Anything triggered after untrusted content (retrieved documents, web pages) entered the context.

Read-only retrieval from a pre-authorized, access-trimmed index usually does not need per-call approval, or the UX becomes unusable.

Design details: show the human the exact tool name and arguments (not a model paraphrase), enforce timeouts and a default of reject, record the decision for audit, and do not let the model decide whether approval is needed.

Answer:

MAF documents built-in OpenTelemetry integration for distributed tracing, monitoring and debugging in both Python and .NET, following the OpenTelemetry GenAI semantic conventions (which are still evolving, so check versions). Practically you get a trace per agent run with child spans for model calls and tool executions, exported to any OTLP backend such as Azure Monitor / Application Insights, or to Foundry's tracing UI.

What to capture and look at:

• Per run: total latency, number of model calls, input and output tokens, cost, final status.
• Per tool call: name, arguments, result size, latency, errors. For retrieval, log the query, filters, returned IDs and scores.
• Quality signals: user feedback, groundedness scores sampled by an LLM judge, refusal rate.
• Loop health: runs hitting max iterations, repeated identical tool calls.

Privacy: prompts and completions often contain PII and confidential text. Content recording is typically opt-in in OTel GenAI instrumentation, so decide deliberately, redact, and set retention.

Operational loop: alert on cost and latency outliers, sample failing traces into an evaluation set (Q18), and replay them after each prompt or tool change.

Answer:

They overlap but have different centers of gravity:

Decision factors in order: team language (a .NET shop leans MAF), cloud and identity constraints (Azure and Entra ID favor MAF), need for complex stateful graphs (LangGraph or MAF workflows), and how document-heavy the pipeline is (LlamaIndex for ingestion, possibly feeding any agent framework through a tool or MCP server).

They compose: a LlamaIndex query engine can be a tool in a MAF agent, and MCP lets any agent consume the same retrieval service. Avoid choosing on a feature checklist alone, since all of them can run the loop; prototype your hardest flow in the top two and compare debuggability.

Answer:

Indirect injection means malicious instructions sit inside retrieved documents, web pages, emails or tool outputs, and the model treats them as commands. There is no complete prompt-level fix, so use defense in depth:

1. Least privilege: give the agent only the tools the task needs, and scope credentials per user, so a hijacked agent cannot do much. This is the strongest control.
2. Separate read and act: after untrusted content enters the context, do not allow high-impact tools in the same run, or require human approval (Q12).
3. Server-side authorization: enforce ACLs and tenant filters in tool code, never in the prompt (Q26).
4. Treat tool output as data: delimit it, strip active content, truncate, and keep instructions in the system message. This helps but is bypassable.
5. Screening: run content-safety or prompt-shield style classifiers on retrieved text and on tool arguments, through middleware. Azure AI Content Safety offers prompt-attack detection; verify the current product name and coverage.
6. Egress control: block exfiltration channels such as arbitrary URL fetches, markdown image rendering with data in the URL, and unrestricted email.
7. Ingestion hygiene: control who can write to the indexed corpus; an attacker who can edit a wiki page can attack your agent.
8. Monitor and red-team: log tool calls, alert on anomalies, and test with known injection suites.

Be honest in the interview: these reduce risk, and the design should assume the model can be tricked.

Answer:

First decide whether to migrate now: SK is in maintenance mode and AutoGen is archived, so for AutoGen urgency is high; for a stable SK app, migrate on a planned schedule.

Semantic Kernel mapping (from the official guide, which has .NET and Python sections):

AutoGen: map conversation patterns to MAF orchestrations or workflows, using the official AutoGen guide.

Steps: inventory agents, tools, memory and filters; add a regression suite of real conversations and RAG questions first; migrate leaf agents; use as_agent_framework_tool() to reuse existing SK functions and vector search functions during the transition; port filters to middleware; swap telemetry to the MAF OpenTelemetry setup; run old and new side by side on shadow traffic; compare quality, cost and latency; cut over by traffic share.

Risks: behavior drift from different default prompts and tool-call handling, hosted-thread semantics (the guide notes no thread deletion API), and prerelease packages. Pin versions.

Answer:

For the GraphRAG concepts (entity and relationship extraction, community detection, community summaries, local versus global search) see 02_interview_bank/05-graph-rag.md; for the cheaper query-time variant see 02_interview_bank/47-lazygraphrag.md. Here is only the agent integration.

Pattern: keep indexing offline (microsoft/graphrag's indexing pipeline is slow and LLM-expensive) and expose query as tools:

• graph_local_search(question) for entity-centric questions ("who approved contract X and what else did they approve?").
• graph_global_search(question) for corpus-wide themes ("what are the main risks across all incident reports?").
• A plain hybrid chunk search tool for factual lookups.

Wrap each behind a service (HTTP or an MCP server) so the agent framework does not depend on the GraphRAG library version. The agent's tool descriptions should say when each applies, because tool choice is where this goes wrong: global search is many LLM calls, so it can be slow and costly, so consider gating it, caching by question, and bounding concurrency.

Operational points: return citations (source documents or community IDs), version the index and expose its build date, rebuild or update incrementally as the corpus changes, and apply the same document-level access control, which is hard because community summaries blend documents of different sensitivity. Often the right answer is separate indexes per permission tier.

Answer:

Score the trajectory as well as the outcome.

Method: build a golden set from real queries, including multi-hop, unanswerable, ambiguous and adversarial cases; run it on every prompt, model or tool change; use LLM judges for groundedness and relevance but calibrate them against human labels; record traces so failures can be diagnosed per step (Q13). Because agents are non-deterministic, run each case several times and report pass rates, not single results.

The MAF overview lists evaluation services among its integrations, and Azure AI Foundry has evaluators for groundedness, relevance and tool-call accuracy. Names and availability change, so check current docs. Open tools such as Ragas or LangSmith evaluate the same dimensions regardless of framework.

Answer:

Constraints: regulated data, .NET team, auditability, humans must approve any change.

Architecture

• Agent: one MAF AIAgent (.NET) with Azure OpenAI or Foundry models, behind an API authenticated with Entra ID. One agent plus tools, not a multi-agent system, since the task is lookup and drafting.
• Tools:
  • search_policy(query, plan_type?) over Azure AI Search hybrid plus semantic ranking, with a security filter built from the adjuster's groups in code.
  • get_claim(claim_id) read-only, authorized per adjuster.
  • draft_claim_note(claim_id, text) writes only a draft.
  • update_claim_status exposed only as an approval-required tool; a human sees the exact arguments before execution.
• Memory: session history per adjuster, no long-term memory of claimant PII.
• Guardrails: middleware for PII redaction in logs, injection screening on retrieved text, a max-tool-calls budget, and a refusal rule when no policy passage is found, with mandatory citations.
• Observability: OpenTelemetry to Application Insights, with prompt content recording off or redacted; audit log of tool calls with user, claim ID and approval decision kept in a separate store.
• Evaluation: golden set from past adjuster questions, run in CI on each prompt or model change, including unanswerable and injection cases.

Trade-offs: approvals add friction, so keep them only on writes. Pin package versions and note any prerelease packages. If response time matters, cache policy retrieval for common questions.

Answer:

Start from traces, not guesses. Pull per-run spans (Q13): count model calls per request, tokens per call, and tool-call patterns.

Likely causes and fixes:

Also consider a smaller model for routing and query rewriting, with the larger one only for the final answer, and prompt caching for the static prefix (system prompt plus tool schemas) where the provider supports it.

Verify the fix by replaying the same golden set before and after, checking that answer quality did not drop, since cutting tools or k can silently hurt recall.

Answer:

Multi-agent helps when:

• Specialists need different instructions, tools or models, and one prompt cannot carry them all without confusing the model.
• Context isolation matters: a research sub-agent can read 50 pages and return a 200-word summary, protecting the main context.
• Security boundaries differ: the agent that reads untrusted web content has no write tools, and the agent with write tools never sees raw web text.
• Independent subtasks can run concurrently.
• Different teams own different capabilities behind agent interfaces (and possibly A2A or MCP boundaries).

It hurts when:

• Each handoff or group-chat turn is an extra model call, with the shared transcript growing, so cost and latency multiply.
• Errors compound across agents, and a wrong early summary is trusted downstream.
• Debugging requires reading long inter-agent conversations.
• Routing is ambiguous, causing handoff loops.

Default: start with one agent plus well-described tools, and measure. Split only when the trace shows tool confusion, context bloat or a security need. When you do split, prefer deterministic workflow edges (sequential, concurrent, explicit handoff) over free-form group chat, bound the number of turns, and give each agent a narrow output contract. This is the same advice the MAF docs give when they say to use a function if a function will do.

Answer:

I have not verified an official one-to-one mapping for the SK Process Framework, so treat this as the concept-level approach, and check the migration guides before committing.

Both model a business flow as steps with explicit transitions and state, in contrast to a free-running agent loop. MAF workflows are graph-based: executors (agents or plain functions) connected by edges, with streaming, checkpointing, human-in-the-loop and time-travel debugging listed in the docs.

Migration approach:

1. Draw the existing process as a graph: steps, events, branching, shared state, external waits.
2. Classify each step as deterministic code (becomes a function node), an LLM call (agent node), or human input (request-info or approval).
3. Move shared state into the workflow's explicit state or checkpoints rather than hidden globals.
4. Replace durable-wait logic (waiting days for a reviewer) with checkpoint and resume, and test that resume works after a process restart.
5. Add tests per node with mocked model output, plus a few end-to-end golden cases.

Check particularly whether any current step relies on SK-specific runtime hosting (for example Dapr or Orleans-based hosting) that has no direct counterpart, and what the MAF hosting options are. If the process is simple and stable, leaving it on SK until a planned migration is a defensible choice given SK's maintenance mode.

Answer:

Correct: C. MAF's guidance is to use a workflow when the process has well-defined steps and you need explicit control over execution order. Workflows connect agents and functions through explicit edges and add checkpointing and human-in-the-loop support.

• A is wrong because a free-running agent decides its own order, which is the opposite of what a fixed process needs, and it adds token cost and variance.
• B is wrong because Magentic is for open-ended tasks where a manager plans on the fly; here the plan is already known.
• D is wrong because group chat is a collaboration pattern with a dynamic speaker, so it is the least predictable choice for a fixed pipeline.

Answer:

Correct: A. The microsoft/autogen README states the project is no longer maintained by Microsoft and recommends Microsoft Agent Framework for new projects, with a migration guide for existing ones (verify current wording in the repo).

• B is wrong because it was Agent Framework that absorbed AutoGen's ideas, and AutoGen is not a continuing research branch.
• C is wrong because the consolidation went into Agent Framework, which is itself the successor to Semantic Kernel agents; SK is in maintenance mode.
• D is wrong because AutoGen Studio was a prototyping UI that the docs said was not production-ready, and it was never a rename of the framework.

Answer:

Correct: D. Controls enforced outside the model hold even if the model is fooled. A human sees the exact recipient and body before sending, and the tool itself refuses non-allowlisted recipients, so a hijacked agent cannot exfiltrate data.

• A is wrong because prompt instructions are helpful but can be bypassed by well-crafted injected text; they are not a security boundary.
• B is wrong because larger models are somewhat more robust but still fail, and you cannot prove safety by model choice.
• C is wrong because fewer documents only lowers the odds of retrieving the poisoned page; it does not stop the attack once it is retrieved.

Answer:

Correct: B. Authorization must be enforced deterministically in code the model cannot influence, using the identity from your authentication layer, and applied at query time so unauthorized chunks are never retrieved or placed in the context.

• A is wrong because the model would already have seen the restricted text, and a prompt rule can be overridden by injection or simple error.
• C is wrong because the model controls the argument, so a user (or an injected document) can steer it to another department's value.
• D is wrong because it relies on the model to censor data it has already received, which is neither reliable nor auditable.