{"id":30639,"date":"2026-10-27T09:30:21","date_gmt":"2026-10-27T08:30:21","guid":{"rendered":"https:\/\/whiteduck.de\/running-flock-multi-agent-apps-as-microsoft-foundry-hosted-agents\/"},"modified":"2026-10-27T09:44:35","modified_gmt":"2026-10-27T08:44:35","slug":"running-flock-multi-agent-apps-as-microsoft-foundry-hosted-agents","status":"publish","type":"post","link":"https:\/\/whiteduck.de\/en\/running-flock-multi-agent-apps-as-microsoft-foundry-hosted-agents\/","title":{"rendered":"Running Flock Multi-Agent Apps as Microsoft Foundry Hosted Agents"},"content":{"rendered":"

Flock<\/a> is our open-source framework for multi-agent systems built on a blackboard. A Flock crew is a set of agents that react to typed artifacts on a shared blackboard, and the answer is whatever the crew publishes while the cascade runs. That model makes parallel work and joins almost free. It also makes hosting hard: put a crew behind a request\/response endpoint, and you have to answer which artifacts belong to which request, when a request is done, and what the caller gets to see.<\/p>\n

Microsoft Foundry hosted agents are the natural place to run such a crew on Azure. You package the agent as a container, and Foundry Agent Service<\/a> runs it behind an OpenAI-compatible Responses endpoint, with conversations, streaming, an Entra identity per agent and scaling handled by the platform. Microsoft documents that path for the Agent Framework<\/a> and LangGraph<\/a>, where a request enters one graph or agent loop and the answer comes out at its end. For a Flock crew, our position is simple: one request should be one isolated blackboard. With flock-core<\/code> 0.5.700, Flock ships exactly that as FlockApplication<\/code>, plus a Foundry adapter in the new flock-core[foundry]<\/code> extra.<\/p>\n

Flock in 90 seconds<\/h2>\n

Flock is a blackboard architecture<\/a> for LLM agents. Agents do not call each other and nobody wires a graph. Each agent declares which artifact types it consumes and which it publishes, as Pydantic models, and Flock schedules it whenever a matching artifact lands on the blackboard. Parallelism and joins fall out of those contracts: two agents that consume the same type run concurrently, and an agent that consumes two types waits for both.<\/p>\n

Here is the incident-triage crew we use throughout this post, taken from the sample in the Flock repository:<\/p>\n

from pydantic import BaseModel, Field\nfrom flock import Flock, WorkflowContext, flock_type\n\n\n@flock_type\nclass IncidentRequest(BaseModel):\n    report: str\n    history: list[dict[str, str]] = Field(default_factory=list)\n\n\n@flock_type\nclass IncidentTriage(BaseModel):\n    \"\"\"Internal: severity and affected component. Never returned to callers.\"\"\"\n\n    severity: str = Field(description=\"low, medium, high or critical\")\n    component: str = Field(description=\"The affected system component\")\n\n\n@flock_type\nclass IncidentSummary(BaseModel):\n    summary: str = Field(description=\"Two sentences for the on-call engineer\")\n\n\ndef build_flock(context: WorkflowContext) -> Flock:\n    flock = Flock(\"azure\/incident-model\", no_output=True)\n    flock.agent(\"triage\").description(\n        \"Classify the incident report; use the conversation history for context.\"\n    ).consumes(IncidentRequest).publishes(IncidentTriage)\n    flock.agent(\"summarizer\").description(\n        \"Write a short, actionable summary for the on-call engineer.\"\n    ).consumes(IncidentTriage).publishes(IncidentSummary)\n    return flock\n<\/code><\/pre>\n
triage<\/code>  reacts to the request and publishes an IncidentTriage<\/code>, which in turn triggers summarizer<\/code>. The topology is a consequence of the types, not something we declared, and the same types double as the structured output schema for the model. IncidentTriage<\/code> is an intermediate result: useful on the blackboard, but not something a caller should receive. For readability, this version uses Flock’s default engine; in the model access section we swap in an engine that authenticates with the hosted agent’s identity instead of an API key.<\/p>\n
Flock already had a way to serve a crew: flock.serve()<\/code> runs one long-lived blackboard with a REST API and a live dashboard. That is the right tool for a shared workspace. It is the wrong tool for a hosted agent that answers independent requests from many users.<\/p>\n
Why hosting a blackboard is different<\/h2>\n
 When we first put a Flock crew behind a Foundry endpoint, we wrapped one long-lived blackboard in a request handler. It worked in the demo and failed on four problems as soon as we thought about real traffic.<\/p>\n