Foundry Hosted Agents 30일 내 GA, 세션별 샌드박스

AI 요약

• 무슨 일: Microsoft가 Build 2026에서 Foundry Agent Service의 hosted agents GA 일정을 예고했습니다.
  • 공식 블로그는 30일 내 GA, Build recap은 2026년 7월 초 GA를 적었고, 세션별 sandbox와 전용 filesystem을 강조했습니다.
• 운영 변화: Agent Framework v1.0, Toolboxes, procedural memory, tracing/evals, Agent Optimizer가 prototype 이후의 운영면을 구성합니다.
• 주의점: 여러 기능은 preview입니다. Teams·Microsoft 365 Copilot 배포, Agent Control Specification, ROI 측정은 tenant 정책과 실제 로그 검증이 필요합니다.
  • 발표 직후 커뮤니티 검증은 얕고, Foundry agent를 Copilot/Teams에 붙이는 인증 flow 문제도 Reddit에 올라왔습니다.

Microsoft가 2026년 6월 2일 Build 2026에서 Microsoft Foundry Agent Service 업데이트를 공개했습니다. 발표의 중심은 모델이나 챗 UI가 아니라 agent가 prototype을 벗어난 뒤 필요한 runtime입니다. Microsoft는 Build, Deploy, Operate 세 layer를 제시했습니다. 그 안에 Microsoft Agent Framework, Toolboxes, hosted agents, memory, Teams·Microsoft 365 Copilot publishing, tracing/evaluation, Agent Optimizer를 배치했습니다.

이번 글은 최근 devlery가 다룬 Work IQ APIs, MAI 모델, MXC Windows 격리와 다른 면을 봅니다. Work IQ 글은 Microsoft 365 context와 credit 과금, MXC 글은 Windows의 local containment가 중심이었습니다. 이번 Foundry 발표는 agent가 어디에서 실행되고, 어떤 tool endpoint를 통해 외부 시스템을 부르며, 실패 trace가 어떻게 evaluation과 개선 후보로 돌아오는지를 다룹니다. 개발팀 입장에서는 “어떤 모델이 좋은가”보다 “agent가 밤새 실행되다가 실패했을 때 누가 보고 고칠 수 있는가”에 가깝습니다.

Microsoft Foundry Blog는 현재 agent 개발의 병목을 분명하게 적었습니다. 로컬 prototype은 GitHub Copilot 같은 coding agent 덕분에 쉬워졌지만, enterprise workflow 안으로 들어가는 순간 tool과 data source마다 인증, protocol, lifecycle이 갈라집니다. 또 production에서는 세션 간 isolation, durable state, load를 견디는 runtime, trace와 eval이 필요합니다. Microsoft는 이 상태를 10년 전 microservices가 겪었던 discovery, isolation, observability, deployment 문제와 비교했습니다.

Build 2026에서 Foundry가 제시한 첫 조각은 Microsoft Agent Framework입니다. Foundry Build Edition recap은 Agent Framework가 stable release로 agent harness, skills, memory, middleware를 포함한다고 설명합니다. GitHub Copilot SDK와 Claude Agent SDK integration도 stable release로 적혔고, Magentic-One multi-agent orchestration pattern도 안정화 항목에 들어갔습니다. 새 framework를 강제하기보다 LangGraph, Copilot SDK, Claude Agent SDK 같은 기존 투자를 Foundry runtime에 연결하겠다는 메시지입니다.

두 번째 조각은 hosted agents입니다. Microsoft는 Hosted agents in Foundry Agent Service가 30일 내 일반 제공에 도달한다고 썼고, Build Edition recap은 2026년 7월 초 GA를 예상한다고 적었습니다. 설명은 구체적입니다. 매 session은 자체 sandbox에서 실행되고 dedicated compute, memory, filesystem access를 받습니다. Runtime은 framework-agnostic이며 Microsoft Agent Framework, GitHub Copilot SDK, LangGraph 또는 다른 SDK로 만든 agent를 rewrite 없이 배포할 수 있다고 합니다.

Build Live는 이 runtime에 더 공격적인 수치를 붙였습니다. Hosted Agents가 framework-agnostic runtime에서 untrusted code를 per-session sandbox로 실행하고, sub-100 ms cold starts와 zero idle cost를 제공한다고 적었습니다. 이 문장은 agent 운영비를 계산하는 팀에게 중요합니다. Agent는 사용자가 바로 답을 기다리는 voice/chat 작업도 있지만, issue triage나 report generation처럼 몇 시간 간격으로 깨는 작업도 있습니다. zero idle cost가 실제 청구서에서 어떻게 잡히는지는 GA 후 pricing과 telemetry로 확인해야 합니다.

Hosted agents가 지원하는 protocol도 두 갈래입니다. Foundry Blog는 OpenAI-compatible stateful interaction을 위한 Responses API와, request/response format을 개발자가 통제하는 schema-free pass-through용 Invocations protocol을 언급했습니다. 이 설계는 Microsoft가 OpenAI-style API compatibility만으로 agent runtime을 정의하지 않는다는 뜻입니다. 이미 자체 orchestration stack을 가진 팀은 Invocations protocol을 통해 payload를 통과시키고, stateful interaction을 원하는 팀은 Responses API 쪽을 선택할 수 있습니다.

Long-running agent와 routine도 Build 2026 발표의 실무 포인트입니다. Microsoft는 hosted agents가 OpenClaw와 Hermes 같은 long-running autonomous agents, durable state, filesystem access를 지원한다고 설명했습니다. Routines는 public preview로, agent를 timer나 schedule에 맞춰 실행하는 기능입니다. 발표 예시는 밤새 GitHub repository를 모니터링하고 새 issue를 triage한 뒤 standup 전에 Teams에 summary를 올리는 agent입니다. 이 예시는 모델 성능보다 scheduling, identity, filesystem, notification, failure recovery가 제품 요구사항이 되는 상황을 보여줍니다.

Toolboxes in Foundry는 agent tool 표면을 줄이는 방향입니다. Build Edition recap은 Toolboxes가 public preview이며, tools, skills, MCP clients, governance를 하나의 managed endpoint로 제공한다고 설명합니다. 개발자는 tool을 한 번 구성하고 MCP-compatible client를 하나의 URL에 붙입니다. Foundry는 auth, lifecycle, governance를 처리합니다. Skills도 preview로 project-scoped catalog 안에서 versioned resource가 되고, tool search가 task별로 필요한 tool을 고르는 preview 기능으로 붙습니다.

이 설계가 필요한 이유는 agent prompt에 tool 목록을 끝없이 넣는 방식이 오래 버티기 어렵기 때문입니다. Tool이 수십 개로 늘면 모델은 어떤 tool이 필요한지 고르는 일에도 token과 실패 확률을 씁니다. Foundry의 Toolbox 방향은 MCP와 enterprise data, Work IQ, Fabric IQ, Foundry IQ를 같은 endpoint 뒤에 숨기고, agent가 필요한 tool만 발견하도록 만드는 쪽입니다. 발표문은 이를 “custom plumbing”을 줄이는 일로 포장하지만, 운영팀 관점에서는 누가 어떤 tool version을 노출했고 어떤 identity가 호출했는지 추적하는 control point입니다.

Memory 업데이트는 marketing 문장보다 수치가 중요합니다. Microsoft는 Memory in Foundry Agent Service public preview가 procedural, user, session memory 세 유형을 포함한다고 적었습니다. Procedural memory는 agent가 “무엇을 말했는가”가 아니라 “어떻게 일을 해야 하는가”를 runs 사이에서 학습하는 기능입니다. 공식 예시는 PR review agent에게 “test coverage를 먼저 보고, 새 dependency를 flag하고, breaking API change를 찾으라”고 한 번 coach하면 몇 주 뒤 다른 PR에서도 같은 순서로 검사한다는 내용입니다.

Microsoft는 procedural memory의 early Tau-bench 결과로 +7-14% absolute success-rate gains를 제시했습니다. 단, 이 수치는 Microsoft가 공개한 초기 결과이며 benchmark 구성, task 분포, baseline cost, memory write/read 정책을 독립적으로 검증할 자료는 발표문에 충분히 나오지 않았습니다. 개발팀은 이 숫자를 일반 성능 보증으로 읽기보다, repetitive workflow에서 agent procedure를 prompt에 계속 붙이는 대신 memory로 분리하려는 제품 방향으로 읽는 편이 맞습니다.

Operate layer는 Foundry 발표에서 가장 production에 가까운 부분입니다. Build Edition recap은 tracing and evaluations for any agent framework가 public preview로 LangChain, Semantic Kernel, custom framework agent에도 Foundry tracing/evaluation을 제공한다고 적었습니다. Agent Optimizer는 soon public preview입니다. Foundry AI Operations Service에서 evaluation suite를 실행하고, 결과를 Foundry Optimizer로 보내 prompt, tools, skills, context의 ranked improvement candidate를 만든다는 설명입니다. Agent ROI는 private preview로 task completion rate, time saved, cost efficiency를 측정한다고 합니다.

이 loop가 제대로 작동하려면 trace와 eval이 같은 사건을 가리켜야 합니다. Agent 실패는 “답이 틀렸다” 하나로 끝나지 않습니다. 잘못된 tool을 골랐거나, 권한이 부족했거나, memory가 오래됐거나, retrieval source가 틀렸거나, policy가 runtime에서 막았을 수 있습니다. Microsoft가 trace와 eval을 agent boundary 밖으로 확장하려는 이유도 이 때문입니다. 평가가 따로 돌고 production log가 따로 남으면, 실패한 run에서 무엇을 고쳐야 하는지 ranked diff로 만들기 어렵습니다.

Governance 쪽에서는 Agent Control Specification과 Agent 365가 같은 발표권 안에 들어옵니다. Build Live는 Agent Control Specification preview가 Foundry, Microsoft Agent Framework, LangChain 전반에서 production agent가 할 수 있는 일을 정의하고 집행하도록 한다고 적었습니다. Microsoft 공식 블로그는 Agent 365, Entra, Purview, Defender가 agent estate를 catalog로 보여주고, 누가 deploy했는지, 어떤 data와 tool에 접근하는지, 비용과 행동을 어떻게 모니터링하는지 관리한다고 설명했습니다. 이 부분은 에이전트 수가 수십 개에서 수백 개로 늘 때 IT가 요구하는 control plane입니다.

Distribution도 이번 발표의 큰 축입니다. Foundry Blog는 Foundry agent를 Microsoft Teams와 Microsoft 365 Copilot에 publishing하는 기능이 다음 달, 즉 2026년 6월 GA 예정이라고 적었습니다. Identity, permissions, policy가 자동으로 흐른다는 설명도 붙었습니다. 또한 assistive agents, autonomous agents 외에 autopilot agents public preview가 추가됩니다. Autopilot agents는 독립적으로 행동하며 Entra Agent ID, email address, Microsoft Teams presence, org chart 안의 위치를 가진다고 설명됐습니다.

이 지점은 실무 검증이 필요합니다. Teams와 Microsoft 365 Copilot 배포는 데모에서는 단순해 보여도 tenant login, Entra 정책, app consent, Copilot 노출 위치, Teams presence, audit log가 모두 얽힙니다. 실제로 Reddit r/AZURE에는 Foundry Agent를 Microsoft 365 Copilot/Teams/Web365로 노출하려는 사용자가 “Foundry login 완료 대기” 상태에서 멈춘다는 글을 올렸습니다. 단일 사례지만, 발표가 말하는 distribution path가 운영에서는 identity flow와 tenant configuration 문제로 나타날 수 있다는 신호입니다.

경쟁 구도는 분명합니다. AWS는 Bedrock AgentCore와 Bedrock Managed Agents로 agent runtime, gateway, identity, observability를 묶고 있습니다. Google은 Gemini API Managed Agents와 Antigravity 쪽에서 sandboxed execution과 developer workflow를 밀고 있습니다. OpenAI는 Agents SDK와 Codex 제품군으로 agent harness를 확장하고, Vercel은 Sandbox와 AI Gateway로 web application 안의 agent execution을 겨냥합니다. Microsoft Foundry의 차별점은 Microsoft 365, Teams, Entra, Purview, Defender, Azure model catalog가 같은 enterprise control plane에 붙는다는 점입니다.

개발팀이 바로 볼 체크리스트는 모델 benchmark가 아닙니다. Hosted agents를 평가한다면 session isolation, filesystem persistence, routine scheduling, cold start를 확인해야 합니다. zero idle cost의 실제 청구 방식, supported regions, private networking, log retention도 같은 표에 넣어야 합니다. Toolboxes를 평가한다면 MCP endpoint 구성, tool search가 잘못된 tool을 숨기거나 추천하는 사례, skill versioning, credential rotation을 봐야 합니다. Memory를 평가한다면 procedural memory가 어느 범위까지 저장되고, 사용자 요청이나 compliance 정책에 따라 삭제되는지 물어야 합니다.

이번 발표에서 가장 강한 문장은 “agent prototype은 쉽고 production은 어렵다”는 진단입니다. Microsoft는 그 뒤의 어려움을 runtime, tools, memory, distribution, observability, governance로 쪼개 제품화하고 있습니다. Foundry Hosted Agents가 30일 내 GA에 도달하면 비교 기준은 model list보다 per-session sandbox, tool endpoint, trace-eval loop, tenant policy, cost telemetry로 이동합니다. Build 2026의 Foundry 업데이트는 에이전트를 만드는 발표가 아닙니다. 만든 에이전트를 기업 안에서 계속 돌리기 위한 운영면을 넓힌 발표입니다.

출처

• Microsoft Foundry Blog, Build and run agents at scale with Microsoft Foundry at Build 2026.
• Microsoft Foundry Blog, What’s new in Microsoft Foundry | Build Edition.
• Microsoft Build Live, Microsoft Foundry updates.
• Microsoft Official Blog, AI alone won't change your business.
• Microsoft Official Blog, Microsoft Build 2026: Be yourself at work.