One Markdown File Is One Employee: The Orchestrator-Workers Pattern in AgentScope-Java
Multi-agent teams in Java now scale by editing markdown instead of rewiring code, which moves role composition from compile time to deployment time. The pattern also gives a concrete way to solve context pollution and temperature conflicts, the two failures that make a single agent unreliable for multi-stage work.
AgentScope-Java ships multi-agent orchestration as an orchestrator-workers pattern. A HarnessAgent plays editor-in-chief: it splits a request into stages, spawns the right worker for each stage, waits for the result, and merges everything into a final briefing. Workers are declared as markdown files under workspace/agents/. YAML front matter sets name, description, temperature, and an optional tools list; the file body is the agent's system prompt.
The pattern targets three limits of a single agent. Workers run in isolated contexts, so one role's intermediate reasoning does not leak into another's output. Different temperatures can be assigned per role: the demo content team uses outliner at 0.7, writer at 0.8, and reviewer at 0.3, giving both creative drafting and stable review in one pipeline. The editor carries only the workflow, not the domain expertise, and receives condensed results instead of raw dumps.
The agents/ directory is scanned at first inference, not at builder time, so a team can be changed by editing files between conversations. The framework gives HarnessAgent 21 built-in tools, including agent_spawn, agent_send, and agent_list; to the editor, delegating to a worker is just another tool call. A compaction setting of 30 trigger messages and 10 kept messages keeps long orchestration runs inside context limits, and AgentSpecLoader can validate declaration files in CI without starting an agent.
Declaring agents as files makes team composition a data operation. The scan at first inference means a role can be added, retuned, or removed without a rebuild, which changes how an orchestration system is operated in production.
Multi-agent orchestration here adds no new execution model: agent_spawn is just another tool in the ReAct loop. That keeps the same event-stream debugging and tool-call tracing that already work for single agents.
Isolated worker contexts plus condensed returns are what make the editor's own context manageable. The architecture controls information flow as much as it divides labor.
Explicit per-worker tool lists enforce least privilege, but they are easy to miss: a worker with no tools can only answer in text even though the parent has registered the tool.
Splitting temperature across roles is one of the most concrete multi-agent advantages: a single agent cannot be exploratory and strict at the same time, while a pipeline of roles can be both.