{"slug": "the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router", "title": "The Thin Orchestrator: How Meta Routes Agent Work Without Overloading the Router", "summary": "Meta rebuilt its data-pipeline column-onboarding agents around a \"thin orchestrator\" after an initial single-agent design hallucinated invalid configurations in production. The new 1,300-line orchestrator routes 20+ workflows to 14 specialized agents using state-based flags rather than domain reasoning, performing no domain work itself and trading higher latency for reliability.", "body_md": "Meta's data pipeline agents automate column onboarding across three code repositories, three languages, and six pipeline stages. The first version used a single agent loaded with all domain knowledge. It hallucinated in production. The fix was not better prompts or larger context windows. It was giving the orchestrator less to do.\n\nThe thin orchestrator pattern separates routing logic from domain reasoning. The orchestrator enforces reliability checks and delegates work. Specialized agents handle schema inference, query generation, and validation. This inverts the common pattern of stuffing all context into a single orchestrator prompt.\n\nMeta's pipeline is config-as-code. Python configurations drive C++ code generation, which feeds data processing services, which populate analytics systems. Onboarding a single data column requires coordinated changes across configuration registries, backend services, and data pipelines.\n\nThe first agent design loaded the orchestrator with:\n\nIn demos, it worked. In production, it started generating invalid configurations. The root cause was context overload. The orchestrator tried to reason about domain semantics while also managing workflow state. When schema definitions changed or new edge cases appeared, the agent's routing decisions became brittle.\n\nMeta rebuilt the system with a 1,300-line orchestrator that routes 20+ workflows to 14 specialized agents. The orchestrator performs zero domain work itself.\n\nThe thin orchestrator owns three things:\n\nIt does not interpret schemas, generate code, or validate domain logic. It does not need to understand what a \"data column\" is or how pipeline stages relate.\n\nEach specialist owns one domain task:\n\nSpecialists receive narrow context. The schema inference agent sees only the source data and existing column definitions. The Python config generator sees only the target schema and Python syntax rules. No agent needs the full system picture.\n\nThe orchestrator routes based on workflow state, not task semantics. It uses a simple decision tree:\n\n``` python\nclass ThinOrchestrator:\n    def route_next_agent(self, workflow_state):\n        if workflow_state.stage == \"schema_inference\":\n            if workflow_state.schema_proposed:\n                return self.agents[\"validation\"]\n            else:\n                return self.agents[\"schema_inference\"]\n\n        elif workflow_state.stage == \"config_generation\":\n            target_lang = workflow_state.target_language\n            return self.agents[f\"config_gen_{target_lang}\"]\n\n        elif workflow_state.stage == \"deployment\":\n            if workflow_state.validation_passed:\n                return self.agents[\"deployment\"]\n            else:\n                return self.agents[\"error_handler\"]\n\n        else:\n            raise UnknownStageError(workflow_state.stage)\n```\n\nThe orchestrator checks flags (schema_proposed, validation_passed) and routes accordingly. It does not inspect the schema content or validation results. It trusts specialists to set the correct flags.\n\nThe orchestrator enforces reliability without understanding task semantics:\n\nThese checks apply uniformly across all agents. The orchestrator does not need to know what \"schema inference\" means to enforce a timeout on the schema inference agent.\n\n| Aspect | Thin Orchestrator | Fat Orchestrator | \n|---|---|---|\n| Context per agent | Narrow, task-specific | Full system knowledge | \n| Routing logic | State-based flags | Domain reasoning | \n| Failure isolation | Agent-level boundaries | Orchestrator collapse | \n| Prompt maintenance | Distributed across specialists | Centralized, brittle | \n| Debugging | Trace agent outputs | Inspect orchestrator reasoning | \n| Latency | Higher (more agent calls) | Lower (fewer hops) | \n\nThe thin pattern trades latency for reliability. Each workflow makes more agent calls because specialists do not overlap. A fat orchestrator might generate and validate a config in one step. The thin version calls the config generator, then the validator, then checks the result.\n\nThe thin pattern also shifts debugging. When a workflow fails, you trace which agent set the wrong flag. With a fat orchestrator, you debug why the orchestrator made the wrong routing decision, which often means inspecting its internal reasoning about domain semantics.\n\nMeta reports efficiency and accuracy improvements after switching to the thin orchestrator:\n\nThe latency increase is real but acceptable for Meta's use case. Data column onboarding is a batch process, not a user-facing API. The reliability gains outweigh the extra round trips.\n\nThe thin pattern works when:\n\nThe thin pattern does not work when:\n\nMeta's orchestrator uses a state machine with explicit transitions. Each agent returns a structured output that includes:\n\nThe orchestrator does not parse the result payload. It only checks the next stage flag and error signal. This keeps routing logic independent of domain semantics.\n\nSpecialists communicate through a shared state object, not direct calls. The orchestrator mediates all data flow. This prevents specialists from developing hidden dependencies.\n\nUse the thin orchestrator pattern when you have multi-domain workflows where reliability and maintainability matter more than latency. It works best for batch processes, data pipelines, and infrastructure automation where each step has clear inputs and outputs.\n\nAvoid it for latency-sensitive user-facing APIs or workflows where steps need shared context to make decisions. The overhead of routing through a central state machine adds real latency, and forcing specialists to communicate only through flags can create awkward indirection.\n\nThe key insight is that orchestrators should route, not reason. When your orchestrator starts needing domain knowledge to make routing decisions, you have crossed into fat orchestrator territory. Pull that knowledge back into specialists and let the orchestrator stay thin.", "url": "https://wpnews.pro/news/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router", "canonical_source": "https://dev.to/mech_app_ai/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router-34e7", "published_at": "2026-10-19 20:06:36+00:00", "updated_at": "2026-10-19 20:14:43.475498+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence", "large-language-models", "mlops"], "entities": ["Meta"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router", "markdown": "https://wpnews.pro/news/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router.md", "text": "https://wpnews.pro/news/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router.txt", "jsonld": "https://wpnews.pro/news/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router.jsonld"}}