Machine translation from Turkish (Cloudflare Workers AI), not reviewed by the author. Read the Turkish original

← Posts

Council Architecture with Gemini and Argon 4 in Google Antigravity: How Did We Distribute the Capabilities?

Score —

The 12-member AI council in which we positioned Gemini 4 Argon as the orchestrator on Google Antigravity, the task distribution of 19 plugins, more than 300 capability packs, and over 45 MCP servers. A practical guide for those who want to use Argon 4 more efficiently.

· 9 min read
Contents

Summary: Running a very powerful AI model in a single chat window as a researcher scanning hundreds of files, a developer writing code, a test runner, and a security auditor all at once eventually reduces efficiency. As the context window fills with raw output, the model's attention drifts, the rules set at the start are forgotten, and token costs multiply unnecessarily. In this article, I first explain why, on Google Antigravity, we positioned the Gemini 4 Argon model as an orchestra conductor and final auditor rather than a lone worker, then how we set up our 12-member council, and how we distributed 19 plugins, more than 300 SKILL.md skill packages, and over 45 MCP servers according to their areas of responsibility. In the final section, I have gathered practical recommendations that can be applied directly by those who want to use Argon 4 more efficiently in their own workflows.

Why does loading every task onto a single model get stuck?

In everyday software development work, opening a model with high deep-reasoning capability such as Gemini 4 Argon and having it do the entire project in a single session looks easy at first. But as the task grows, three concrete problems emerge:

  • Contamination of the context window: When you have it read 30-40 different files to find a bug or add a new feature, and pile build outputs and error logs into the same chat, the model's working area (context) fills with noise. Known in the research literature as Lost in the Middle, this situation causes the model to overlook the architectural rules or security constraints you gave at the start.
  • Spending the same weight of model on every task: Running the top-tier reasoning model over and over with a giant context for a mechanical multi-file rename, a routine unit test, or a simple dependency update both lengthens the time and wastes the token budget.
  • Blindness to auditing its own code: When the model writing the code and the model auditing that code share the same chat history, the model tends to accept a faulty assumption it made while writing the code as correct during the review phase as well.

To overcome this bottleneck, we changed our working setup inside Antigravity. We took Argon 4 from being a single agent that personally writes every line to being a council chair that manages specialized tools and sub-models.

Which models are on the council and how did we divide their roles?

Our system has a declarative task layer (ax.io/v1alpha1) running under /home/ozdil/Projects/SubAgents/ax. When we say "do it with the council", random scripts do not run; 12 council members, each with its own binary and a bounded task definition, come into play:

Council Member Working Tool Primary Task Undertaken
Antigravity (Gemini 4 Argon) antigravity-chief Orchestra conductor, multimodal research, plugin/skill/MCP coordination, and Phase 7 fullstack final check
Claude Code claude (v2.1.302) System architecture design, cloud solution templates, SecOps, IAM, WAF, and HANCORE security auditing
J-Code Harness jcode (v0.98.1) High-performance Rust agent harness, Rust migrations (migrate-to-rust), C/Rust FFI bindings, and Genkit (Go/Dart) construction
OpenAI Codex CLI codex (v0.163.0) Kernel-level isolated sandbox execution, algorithmic verification, unit/component tests, and scientific computing
Google Gemini CLI gemini-cli (v0.64.0) 1M+ token long-context local code repository scanning, Agent Platform, Cloud Run, AlloyDB/Spanner, and Firebase integration
OpenCode opencode (v1.19.3) Language Server Protocol (LSP)-based static analysis and modern Flutter/Android UI architecture (Jetpack Compose, CameraX, Media3, LiteRT)
Cline cline (v3.0.72) Autonomous task execution, modern web and Chrome extensions, performance/accessibility analysis with Chrome DevTools MCP, and Cloudflare integration
Grok grok (v1.0.62) High-speed algorithmic reasoning, GKE and AI/TPU cluster infrastructure, Cloud Monitoring/Logging/Trace, and SLO/FinOps
Qwen Code qwen (v0.25.2) Data Agent Kit (10 DAK MCP servers), BigQuery/Spark/Dataflow/Airflow pipelines, bioinformatics (41 scientific skills), and localization
Mimo Code mimo (v0.1.15) Rapid isolated prototyping, micro-module construction, UI component previews, and mobile ad/media SDK integrations
Aider aider (v0.86.2) Multi-file precise diff management, version upgrades (AGP 9, Compose migrations), and patch merging
Jev Gate jev-gate (v0.7.0) Deterministic quality gate (0.85 acceptance threshold), R8/Proguard analysis, store policy compliance, and source citation auditing

Antigravity's built-in expert subagents

In addition to this 12-member council, Gemini 4 Argon can directly launch 5 built-in subagents in its own internal runtime via the invoke_subagent tool. The biggest advantage of these subagents is that they work in their own isolated context and return only the result to Argon without bloating the main chat window:

  • research: A read-only research agent. When we need to scan dozens of files in the code repository or do web/documentation research, we delegate the work to this agent. The main Argon session is not polluted with hundreds of lines of raw file content.
  • self: A twin agent that inherits all of Argon's capabilities. When two independent tasks need to be run in parallel, it works in a separate workspace branch (branch or share) and finishes its work.
  • firestore-rules-author: The mandatory expert subagent we use for writing and auditing Cloud Firestore security rules (firestore.rules).
  • flutter_a11y_agent: An expert agent that audits Flutter screens and components against WCAG accessibility standards.
  • image-generator: An image generation agent that steps in when interface visuals or design assets are needed.

How did we deploy 19 plugins, 300+ skill packages and 45+ MCP servers?

In our Antigravity environment there are 19 installed plugins, under them more than 300 SKILL.md skill guides, and more than 45 MCP (Model Context Protocol) servers. If you load all these skill files and MCP tool schemas into Argon 4's startup context at once, you will have consumed most of the context budget before writing a single line of code.

To solve this, we set up a two-tier deployment mechanism: the Domain Routing Matrix (DOMAIN_SKILL_MATRIX) and the Eager/Lazy MCP Split.

1. Domain routing matrix (DOMAIN_SKILL_MATRIX)

When ax-run is executed, it analyzes the keywords of the incoming request and the target project directory, and maps the work to the relevant ones among 12 engineering domains. Only the agents, plugins, SKILL.md packages and MCP servers belonging to the selected domain are activated:

Task Area Plugins Woken When Matched Featured Capabilities (SKILL.md) and MCP Tools
flutter-dart flutter, firebase, google-skills-catalog flutter-apply-architecture-best-practices, dart-use-ffigen, dart-run-static-analysis, firebase-mcp-server
android-kotlin-devices android-skills, android-cli-plugin jetpack-compose-performance, navigation-3, litert-runtime, r8-analyzer, android-management-api
web-modern-extensions modern-web-guidance-plugin, chrome-devtools-plugin modern-web-guidance, a11y-debugging, debug-optimize-lcp, chrome-devtools-mcp, cloudflare-*
firebase-serverless firebase, google-skills-catalog firebase-data-connect, firestore-rules-creation, firebase-security-rules-auditor, cloudrun
agent-platform-gemini-genkit google-antigravity-sdk, gemini-api, google-cloud-developer google-antigravity-sdk, gemini-interactions-api, developing-genkit-go, gemini-api-docs
gke-ai-tpu-cloud-infra google-skills-catalog, google-cloud-developer gke-golden-path, gke-compute-classes, gke-ai-troubleshooting-tpu-*, google-kubernetes-engine
data-bigquery-lakehouse-spark data-agent-kit-plugin, google-skills-catalog bigquery-sql, bigquery-ai-ml, dbt-bigquery, gcp-spark, dak-bigquery, dak-gcs
secops-iam-waf-hancore google-skills-catalog, firebase, android-skills google-cloud-waf-security, secops-hunt, iam-helper-*, google-cloud-organization-policy
observability-sre-finops google-skills-catalog cloud-monitoring-promql-query, google-cloud-slo-alert-configuration, google-cloud-monitoring
science-bioinformatics-epigraphy science alphafold-database-fetch-and-analyze, alphagenome-variant-impact-score, predictingthepast, biomolecular_structure_viewer_mcp
workspace-maps-ads-media gslides, gdocs, gsheets, gdrive, gcalendar, google_maps_platform gslides, google-maps-platform, google-ads-api-mcp-setup, canva, gmp-code-assist
systems-rust-omarchy google-skills-catalog, flutter migrate-to-rust, dart-use-ffigen, agy-customizations, github-mcp-server

2. Eager (direct) and Lazy (on-demand) MCP loading

Each of the more than 45 MCP servers contains dozens of sub-tools. Instead of piling them all into the context, we split them in two:

  • Directly loaded (Eager) tools: The frequently used gemini_search_docs and gemini_get_doc (gemini-api_gemini-api-docs) tools are registered directly as local tools. Argon 4 can reach current Gemini API and SDK documentation instantly.
  • On-demand loaded (Lazy) tools: More than 40 servers such as chrome-devtools-mcp, cloudflare-bindings, data-agent-kit-plugin_dak-bigquery, google-kubernetes-engine or canva exist at startup only as a list of names. When Argon 4 is going to use one of these tools, it first reads the schema file /home/ozdil/.gemini/antigravity/mcp/<server>/<tool>.json, then makes the call with call_mcp_tool. This structure provides roughly 88 percent token savings in the initial context window.

The 7-stage execution pipeline: how does sandwich orchestration work?

The most important design decision of the council was to place the Gemini 4 Argon model both at the very beginning and at the very end of the process. We can call this briefly Sandwich Orchestration (Bookend Verification). The 7 stages in our tasks/pipeline.yaml file work in order as follows:

  1. Discovery and activation (1-discovery-plugins-skills-and-mcp): The first step is led by Gemini 4 Argon. With gemini-cli (1M+ context) and the research subagent, it scans the code repository and determines via ax-run which plugins, SKILL.md files and MCP servers will be used.
  2. Architecture and solution design (2-architecture-and-solution-design): Under the leadership of claude-architect, the system diagram, data types and security rules (together with firestore-rules-author) are established.
  3. Code, data and MCP execution (3-code-data-and-mcp-implementation): jcode (Rust/FFI), codex (algorithms), opencode (mobile/interface), cline (modern web) and qwen (data/science) write the modules in their own areas of expertise and run the MCP tools.
  4. Multi-file patching and migration (4-multi-file-patching-and-migration): aider-patcher steps in and merges multi-file changes and version migrations.
  5. Sandbox testing, LSP and quality gate (5-jev-gate-and-sandbox-verification): codex-sandbox runs unit tests, opencode performs LSP static analysis, flutter_a11y_agent carries out the accessibility audit, and jev-gate performs the quality check with a 0.85 threshold.
  6. SecOps, WAF and HANCORE audit (6-secops-waf-and-hancore-audit): In the layer with restricted network access (offline-strict), secret leakage, IAM permissions and Linux HANCORE security rules (process_group(0) process isolation, 1 MiB file read ceiling, 0600 atomic file permissions) are audited.
  7. Argon full-stack final check (7-argon-fullstack-verification): The final word is again spoken by Gemini 4 Argon. The task is not closed until the front end, back end, database, MCP outputs, build results and runtime integrity have been checked end to end.

What can be done to use Argon 4 more effectively?

Even if you don't set up a full council of 12 models in your own system, adopting the following six habits while using Gemini 4 Argon in Antigravity directly increases the efficiency you get from the model:

  • Offload broad file scans to the research subagent: If understanding a problem requires reading 15-20 files, don't have them opened one by one in the main chat. Assign the invoke_subagent with the research subagent. Let the research agent read all the files in its own context and return only a clean summary with line links to Argon 4. This way, Argon 4's attention is not distracted.
  • Have the relevant SKILL.md file read before writing code: Instead of relying on the model's general training memory, if there is a SKILL.md capability file related to the task you will do (for example bigquery-sql, jetpack-compose-performance or migrate-to-rust), have it read first. Current API rules then enter the working context directly.
  • Run the self subagent in parallel for independent tasks: If two separate modules that don't wait on each other are to be written, don't wait for Argon 4 to write both sequentially in a single window. Start the self subagent in isolated workspace (branch or share) mode and run them in parallel.
  • Don't set up a polling loop for background tasks: Antigravity has a reactive wakeup system. When you start a long-running build or subagent, you don't need to set up a sleep or status-asking loop; when the tool call finishes, go into waiting, and the system automatically wakes Argon when the task is complete.
  • Use targeted patches instead of full file writes for large files: When making changes to an existing long file, having the entire file rewritten (write_to_file) is both slow and carries the risk of losing existing comment lines. Instead, prefer the line-range replace_file_content tool or, for multi-file work, diff-focused tools like aider.
  • Always use Argon 4 as the "final approval gate": After code generation is complete, make sure Argon 4 performs the build test, unit test and, if there is a web interface, the live console/accessibility check via chrome-devtools-mcp. The model's strongest side is its ability to evaluate outputs across different layers together and catch overlooked integration errors.

My reading

  • What is certain: No matter how large the model's context window is, piling every task into a single chat history eventually reduces both quality and speed. Task decomposition and the use of specialized subagents are no longer a preference but a necessity in large projects.
  • What makes the most difference in practice: Separating more than 45 MCP servers into eager and lazy, and delegating broad research to the research subagent, dramatically relieved Argon 4's working memory.
  • In summary: When you use Gemini 4 Argon not as a worker carrying every stone alone, but as an orchestra conductor who distributes the work to the right experts, establishes the architecture and finally audits everything end to end, you see its true power.

Sources