--- title: How to Enable Sage-A1.5 Subagent Orchestration and Verification Mode url: "https://goremy.ai/blog/articles/sage-a1-5-agentic-orchestration-spawn-subagent" author: Luis Chavez-Mattos editor: Luis Chavez-Mattos editor_title: Director, Product published: "2026-10-23T07:00:10.809Z" updated: "2026-10-23T07:00:10.809Z" topic: AI Agents & Automation description: Sage-A1.5 can fan work out to parallel subagents through a spawn_subagent tool and self-review with Verification Mode. Setup, schema and harness notes. --- # How to Enable Sage-A1.5 Subagent Orchestration and Verification Mode > Sage-A1.5 can fan work out to parallel subagents through a spawn_subagent tool and self-review with Verification Mode. Setup, schema and harness notes. Edited by Luis Chavez-Mattos, Director, Product ยท Published 2026-10-23 ## How do I enable Sage-A1.5's agentic orchestration and Verification Mode? Both features are opt-in. For orchestration, you register a `spawn_subagent` tool in your harness, with arguments for `task`, `context` and `expected_output`, and your harness runs each call as an isolated subagent and returns the result as JSON. For Verification Mode, you switch on a chat-template flag so the model reviews its own progress mid-reasoning. The model weights alone do not do either for you. Your serving and harness code has to opt in. One caveat up front. The model card excerpt I worked from covers the model's capabilities, benchmarks and serving commands. It does not reproduce the exact flag name or the full result schema. Take those from the official repository before you ship anything. ## TL;DR - Sage-A1.5 is a **35B Mixture-of-Experts model** from Shanghai AI Laboratory, released as open weights in Hugging Face Transformers format. - **Agentic orchestration is opt-in.** You expose a `spawn_subagent` tool with `task`, `context` and `expected_output` fields, and your harness executes it. - Subagents run with **isolated contexts**, which the model card says reduces interference between concurrent investigations. - **Verification Mode is a separate opt-in** that makes the model pause mid-trajectory, review what worked and what failed, and revise direction in the same turn, with no external critic. - The card reports modest but real gains from orchestration: **BrowseComp 81.7 to 82.8** and **DeepResearch-Bench2 43.7 to 47.5**. - Serving works with **SGLang and vLLM**, using the `qwen3` reasoning parser and `qwen3_coder` tool-call parser in the SGLang examples. ## What is Sage-A1.5? Sage-A1.5 is a 35B Mixture-of-Experts agentic model built for long-horizon scientific problem solving. It builds on an earlier model called A1. The model card names three headline capabilities: agentic orchestration, verification, and open scientific discovery. It supports native function calling, which matters here. Orchestration is not a special runtime inside the model. The model decides when to delegate and emits a tool call. Everything else happens in your harness. The weights are on Hugging Face and ModelScope, with code in the InternScience GitHub organization. The card says the artifacts work with Transformers, vLLM and SGLang. ## How does agentic orchestration work? Standard single-agent execution runs one chain of reasoning and tool calls. Orchestration lets the model split a task and hand the pieces to subagents that run in parallel, each with its own context window. The card describes subagents that can challenge assumptions, refine conclusions through evidence, and have their findings synthesized into a final result. The loop looks like this: 1. The orchestrator model reads the task and decides it can be decomposed. 2. It emits one or more `spawn_subagent` calls, each with a `task`, some `context`, and an `expected_output`. 3. Your harness starts a fresh model session per call, with only the supplied context. 4. Each subagent works, possibly using its own tools, and returns a result. 5. Your harness feeds the JSON results back to the orchestrator as tool responses. 6. The orchestrator synthesizes them and continues or answers. Isolation is the point. A subagent that goes down a dead end does not pollute the orchestrator's context or its siblings' contexts. ## What does the spawn_subagent tool schema look like? The three arguments are `task`, `context` and `expected_output`. Here is a sketch in the common OpenAI-style function format. The field names come from the model's documented interface. The types and descriptions are my assumptions, so verify them against the official definition. ```json { "type": "function", "function": { "name": "spawn_subagent", "description": "Delegate a self-contained subtask to an isolated subagent.", "parameters": { "type": "object", "properties": { "task": { "type": "string", "description": "What the subagent should do." }, "context": { "type": "string", "description": "Background the subagent needs. It sees nothing else." }, "expected_output": { "type": "string", "description": "The form the result should take." } }, "required": ["task", "context", "expected_output"] } } } ``` Because subagents are isolated, `context` has to be complete. Anything the orchestrator knows that you leave out of it, the subagent does not know. Treat `expected_output` as a contract. A precise description makes the returned JSON easier to merge. ## How should my harness execute subagent calls? Your harness owns the execution. A few practical points follow from the design. - **Run calls concurrently.** If the model emits several `spawn_subagent` calls in one turn, dispatch them in parallel. Sequential execution throws away the benefit. - **Start each subagent clean.** Build a new message list from the call arguments. Do not pass the orchestrator's history. - **Return JSON.** Wrap each subagent's final answer as JSON in the tool response. Check the official repository for the exact result shape the model expects. - **Set limits.** Cap fan-out, recursion depth, and per-subagent token or time budgets. The sources do not specify defaults, so choose your own. - **Handle failures.** Return an explicit error result when a subagent fails, so the orchestrator can retry or route around it. For serving, the SGLang examples in the card use these flags, which expose tool calls and reasoning in the API response: ```shell python -m sglang.launch_server \ --model-path InternScience/Sage-A1.5 \ --port 8000 \ --mem-fraction-static 0.8 \ --context-length 262144 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder ``` That creates an endpoint at `http://localhost:8000/v1`. The card also lists a Multi-Token Prediction variant using EAGLE speculative decoding, and a vLLM path. Native context is 256K, and the card describes extending to 512K with YaRN at a factor of 2.0. ## What is Verification Mode and how do I turn it on? Verification Mode is an opt-in self-review capability that lives inside the model's own chain of thought. The model pauses mid-trajectory, reviews what it has established and what has failed, then acts on a revised direction in the same turn. The card stresses there is no external critic. You are not running a second model as a judge. The brief describes enabling it through a chat-template flag. In practice that means passing an extra template argument when you render the prompt, rather than adding a tool. I could not confirm the flag's name from the excerpt, so look it up in the repository's template or usage docs. The card frames the benefit as long-horizon reliability: progress checking, evidence validation, and recognizing unproductive search paths so the model tries another approach. Expect it to cost more reasoning tokens, though the sources give no figures. ## Does orchestration actually improve results? A little, and more on research-style tasks. The card reports these scores for Sage-A1.5 without and with agentic orchestration: | Benchmark | Without orchestration | With orchestration | |---|---|---| | BrowseComp | 81.7 | 82.8 | | DeepResearch-Bench2 | 43.7 | 47.5 | The BrowseComp gain is about one point. DeepResearch-Bench2 improves by 3.8 points. These are the vendor's own numbers, and they depend on the vendor's harness. Your results will vary with how you implement subagents. For context, the card claims strong results for a ~35B model, including 95.1 on GAIA and 61.2 on SWE-bench Pro. It also lists larger models such as Kimi-K3, GLM-5.3 and GPT-5.6-sol ahead on several benchmarks, for example BrowseComp at 91.2 for Kimi-K3. ## Should I use both modes together? It depends on the task. Orchestration pays off when work splits into independent pieces, such as researching several sources or testing several hypotheses. Verification Mode pays off when a single line of work is long and likely to drift. They address different failure modes, so they can combine. Start with one, measure, then add the other. For short, simple queries, neither is worth the extra tokens and latency. ## Frequently Asked Questions ### Do I need to fine-tune Sage-A1.5 to use subagents? No. The model already supports the behavior. You register the `spawn_subagent` tool and implement the execution in your harness. The model decides when to call it. ### Are subagents separate models? Not necessarily. A subagent is a fresh session with its own isolated context. You can point it at the same Sage-A1.5 endpoint, and the sources do not require a different model. ### Can I run Sage-A1.5 locally? The weights are open and the card gives SGLang and vLLM serving commands. Hardware requirements are not stated in the material I reviewed, so check the repository before planning capacity. ### Where do I find the exact flag and result format? Check the model's Hugging Face page, the Agents-A1 GitHub repository, and the technical report linked from the model card. This article describes the interface from the brief and card, but those are the authoritative references for names and schemas.