Event Planning Multi-Agent System
Five specialist agents coordinate venues, budgets, catering, weather, and calendars into one event plan.
Specialists are assigned domain-specific tools, and a test confirms that the budget agent receives only the code interpreter, providing reasonable least-privilege evidence; Azure roles, network permissions, and a complete tool authorization inventory are absent. The README documents human approval, feedback, pausing, and state preservation, but does not show confirmation before every calendar, search, or deployment effect. Architecture, tool allocation, service-managed threads, telemetry, and .env generation make major flows visible, while transmitted fields, retention periods, and third-party destinations remain unspecified. Sensitive-data evidence is limited to GitHub Secrets, .env usage, and a vulnerability-reporting route; there are no rules for rotation, log redaction, personal data, or conversation retention. Dependencies are constrained, core framework packages are exactly pinned, and the a2a-sdk incompatibility is documented, but prerelease components are used and pip-audit failures are allowed to pass. External effects are enumerated—Azure provisioning, search, weather, calendar generation, and telemetry—but their consent and side-effect boundaries are incomplete. State preservation is described, yet no deployment rollback, calendar undo, or data-deletion procedure is given. Repository ownership, package authorship, copyright, licensing, and security reporting are consistently attributed, justifying full source-attribution credit.
The README, package metadata, CI, and tests are mostly consistent about entry points, workflow identity, and dependencies, with mocked dependency-injection tests supporting internal coherence. Deductions reflect unsupported broad claims such as “production-ready” and the mismatch between README Python 3.11+ and package support for 3.10. Installation prerequisites and version constraints are clear, and CI covers Python 3.11 and 3.12, but availability depends on Azure, external APIs, and beta framework packages, with no offline or degraded mode. The supplied files do not demonstrate user-facing error classification, retries, timeouts, quota handling, or recovery guidance, so failure-message support is thin.
The intended event-planning scenario and a concrete request covering headcount, budget, location, dietary needs, and weather are clear, though audience and scenario coverage is narrow. Five agent roles and their tools establish useful capability boundaries, but unsupported tasks, geographic/date constraints, and safety limits are undocumented. Pydantic next_agent routing and the coordinator topology provide structured trigger selection; routing prompts, ambiguity handling, and termination conditions are not supplied. Azure deployment plus console and DevUI modes offer reasonable environment fit, while non-Azure backends, restricted networks, regional differences, and cloud-free operation are not addressed.
The README is well organized across architecture, features, setup, structure, development, resources, contribution, and licensing, earning full information-architecture credit. Installation commands are usable, but configuration is largely delegated to azd and the supplied evidence omits detailed environment variables, required permissions, and manual troubleshooting. Package names, entry points, and workflow ID are mostly stable, though the project is at 0.0.1 and “Spec-to-Agent” differs slightly from the plural repository name. One concrete input and expected workflow stages are included, but there is no complete output example or FAQ. Known limitations appear only indirectly in dependency-compatibility comments, with no dedicated limitations section. The complete MIT text matches the metadata, warranting full credit. Version 0.0.1 is present, but no release policy or changelog is shown. The Microsoft organization, author contact, contribution notice, and SECURITY.md establish clear maintenance and reporting paths.
A synthesized event plan, structured routing, specialist roles, CLI, and visual UI indicate ordinarily usable output, but no actual output specimen, export contract, or quality constraints are shown. Combining venue research, budgeting, catering, weather, calendar work, and synthesis offers clear marginal value over a single undifferentiated assistant, although no baseline comparison validates the improvement. Cost-benefit treatment is weak: several Azure, model, search, container, and telemetry resources are listed without cost estimates, sizing, quotas, teardown guidance, or a lower-cost configuration.
Several concrete claims trace to package metadata, CI, and focused tests, including entry points, dependencies, workflow ID, and the budget agent's tool assignment. Broader claims such as “production-ready,” “one-click,” and comprehensive human approval are not adequately traced to the supplied tests. The README, pyproject, CI, and tests provide some cross-source corroboration of the stack and operating model, but end-to-end workflow tests, prompts, tool implementations, and infrastructure files are absent. Fact and inference are not cleanly separated because marketing-style capability claims are not labeled as intended behavior, examples, or statically unverified assertions.
- This assessment is based only on the supplied files; no code, tests, deployment, or dependency audit was executed.
- Deployment provisions multiple potentially billable Azure resources; verify subscription, region, quotas, RBAC, budget alerts, and teardown procedures before running azd up.
- Service-managed threads, Application Insights, web search, and the external weather service may transmit or retain event or attendee information; confirm fields, redaction, retention, and regional compliance before using real data.
- Per-action confirmation, idempotency, undo behavior, and failure recovery for calendar and other external effects are not established by the evidence.
- Core Agent Framework dependencies are beta releases and the CI security audit is non-blocking; run a blocking dependency audit and validate the lockfile before production use.
What does this agent do, and when should you use it?
This repository is an event-planning sample built with Microsoft Agent Framework, combining Semantic Kernel orchestration with AutoGen multi-agent patterns. It uses a coordinator-centric star topology in which an Event Coordinator routes work among five specialist agents and synthesizes their results into a comprehensive plan. Users can run it through the `uv run console` interactive CLI or the `uv run app` DevUI, while the workflow supports approval, feedback, pausing, and state preservation. Its specialists integrate Bing Grounding, a Python REPL, Open-Meteo, iCalendar tools, and MCP Sequential Thinking. Deployment is centered on `azd up` and depends on Microsoft Foundry, Azure OpenAI, and related Azure resources, making it a stronger fit for teams already adopting the Microsoft cloud stack than for teams seeking a provider-neutral package.
A user submits an event specification through the interactive console or DevUI, including details such as attendance, date, location, budget, dietary needs, and weather requirements. The Event Coordinator routes work through a star-shaped workflow: Venue Specialist searches through Bing Grounding, Budget Analyst performs calculations with the Code Interpreter Python REPL, Catering Coordinator searches for catering options, and Logistics Manager uses Open-Meteo and iCalendar tools for weather and scheduling. Every agent can use MCP Sequential Thinking. Agents return Pydantic models containing explicit routing decisions in a next_agent field. The workflow can pause through ctx.request_info() for human approval or feedback, while store=True delegates conversation-history management to Azure AI Service; the coordinator then synthesizes the specialist results into a comprehensive event plan.
- A Microsoft Agent Framework development team needs a concrete example of five specialists coordinated through central routing and final synthesis.
- An internal events team wants to prototype a human-approved planning workflow spanning venues, budgets, catering, weather, and calendar creation.
- An Azure architect needs a demonstration that provisions Microsoft Foundry, Azure OpenAI, Bing Grounding, Application Insights, and optional container infrastructure.
- An agent engineer wants to study
ctx.request_info(),store=True, and Pydantic-basednext_agentrouting in a stateful workflow. - A technical instructor needs a lab that combines web search, Python calculations, a weather API, iCalendar tools, and MCP-based reasoning.
What are this agent's strengths and limitations?
- The Event Coordinator organizes five specialists, while Pydantic outputs with
next_agentmake workflow routing explicit and structured. - Framework-native
ctx.request_info()provides a documented mechanism for pausing the workflow, collecting approval or feedback, and preserving state. - The sample assigns concrete integrations—Bing Grounding, Python REPL, Open-Meteo, iCalendar, and MCP Sequential Thinking—to relevant specialists.
- It offers both interactive CLI and DevUI entry points, plus an
azd uppath that provisions infrastructure, connection settings, and dependencies. - Using
store=Truemoves conversation-history management into Azure AI Service instead of requiring manual message tracking in the application.
- The documented core depends on Microsoft Foundry, Azure OpenAI, and Azure AI Service, with no stated local-model or alternative-cloud path.
- Adoption requires an Azure subscription plus Python,
uv, Azure CLI, and Azure Developer CLI, creating a substantial setup footprint. - Venue and catering research rely on Bing Grounding, while weather handling relies on Open-Meteo; network or service failures can impair those workflow stages.
- The material provides no pricing estimate, spending controls, rate-limit guidance, or production recovery strategy, so operating cost and resilience remain unverified.
- The demonstrated scope is event planning, and there is no evidence that the specialist agents and prompts transfer to unrelated domains without modification.
How do you install or deploy this agent?
Prerequisites are Python 3.11+, uv, Azure CLI, Azure Developer CLI, and an Azure subscription. Run:
git clone https://github.com/microsoft/spec-to-agents.git
cd spec-to-agents
az login
azd auth login
azd upAccording to the documented flow, azd up provisions Microsoft Foundry and OpenAI models, writes connection details to .env, and installs Python dependencies through uv sync. The deployment also provisions Bing Search and can include a container registry, container app, and Application Insights.
How do you use this agent?
After deployment, start the recommended interactive console with:
uv run consoleFor the visual interface, run:
uv run appOpen the URL printed by the application, which defaults to http://localhost:8080. A documented first request is to plan a corporate holiday party for 50 people in Seattle on December 6, 2025, with a $5,000 budget, venue options, dietary accommodations, and a weather check. Run the test suite with:
uv run pytestHow does this agent compare with similar options?
The repository explicitly combines Semantic Kernel's enterprise orchestration approach with AutoGen's multi-agent patterns instead of presenting a single-framework design. It provides no benchmark comparing their cost, speed, or output quality.
FAQ
Which cloud account and credentials are required?
az login and azd auth login. The azd up workflow then provisions Microsoft Foundry, Azure OpenAI, Bing Search, and related resources and generates .env connection settings.Can the system run completely offline?
Can a person intervene while the agents are working?
ctx.request_info() to pause for approval or feedback while preserving its state.