Orkestra: Pag-orchestrate ng mga AI Agent sa Malaking Sukat

Ang mga numero sa post na ito ay sumasalamin sa system noong publication (Enero 2026). Tingnan ang aming team page para sa kasalukuyang mga figure.

Nang magsimula kaming bumuo gamit ang Claude Code, nadatnan namin ang isang problema na kalaunan ay haharapin ng bawat team na gumagamit ng AI coding assistant: hindi kayang gawin nang mahusay ng isang solong agent ang lahat.

Puwede mong i-prompt ang isang agent na maging database specialist. O security auditor. O frontend engineer. Pero sa sandaling hilingin mong maging lahat ng tatlo nang sabay, humihina ang kalidad. Nadi-dilute ang context. Nagkakabanggaan ang mga instruction. Ang agent, nagiging isang generalist na katamtaman lang sa lahat.

Kaya gumawa kami ng Orkestra.

Ano ang Orkestra?

Ang Orkestra ay isang agent orchestration system para sa Claude Code at katulad na AI coding tools. Kino-coordinate nito ang maraming specialized na agent, bawat isa may natatanging expertise, sa ilalim ng iisang orchestrator na nag-ruruta ng trabaho papunta sa tamang specialist.

Isipin mo itong parang staffing agency para sa mga AI agent. Tumatanggap ang orchestrator ng isang task, kinikilala kung aling specialist ang dapat humawak nito, at ini-delegate ito nang may tamang context. Kapag tapos na ang trabaho, dumadaloy pabalik ang mga resulta sa orchestrator para sa synthesis.

Sinasabi ng mga numero ang kwento:

Bahagi	Bilang
Mga specialist agent	46
Reusable na mga skill	466
Mga identity archetype	27
Mga mindset	11
Mga estilo ng komunikasyon	10
Mga knowledge domain	21

Ang Character System: D&D para sa mga Agent

Ang core insight sa likod ng Orkestra, umuusbong ang agent behavior mula sa tatlong composable na primitive:

Tinutukoy ng Identity kung ano ang agent. Nagdi-disenyo ng system structures ang isang architect. Sinusubaybayan ng isang debugger ang mga kabiguan hanggang sa root cause nito. Ipinapatupad ng isang guardian ang compliance at security boundaries. May 27 kami identity archetype na puwedeng pagsamahin.

Tinutukoy ng Mindset kung paano nag-iisip ang agent. Ini-anchor ng isang analytical na mindset ang mga assertion sa ebidensya at kinukwantipika nito ang uncertainty. Kinukwestyon ng isang skeptical na mindset ang mga assumption at naghahanap ng disconfirming na ebidensya. Yakap ng isang exploratory na mindset ang ambiguity at sinusubukan ang maraming approach.

Tinutukoy ng Style kung paano nakikipag-usap ang agent. May kasamang eksaktong values at nag-re-reference ng specific na mga file ang isang technical na style. Pinuputol ng isang concise na style ang mga fluff at nangunguna sa sagot. Tinitimbang ng isang diplomatic na style ang katapatan kasama ng tact.

Pinagsasama ng isang agent ang mga primitive na ito:

# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise

Gumagawa ang composition na ito ng isang agent na nagdi-disenyo ng systems (architect), nag-uugnay ng kaalaman sa iba’t ibang domain (knowledge-architect), nagtatakda ng strategic direction (strategist), nag-iisip sa ebidensya at data (analytical), at nakikipag-usap nang walang fluff (concise).

Nasa combinatorial explosion ang lakas. Ang 27 identity beses 11 mindset beses 10 style, nagbubunga ng halos 3,000 posibleng agent personality. Pero ang mga combination lang na mahalaga sa trabaho mo ang ide-define mo.

Skills: Reusable na mga Capability Module

Ang skills ang kaalaman at workflow na puwedeng gamitin ng mga agent. Sumusunod sila sa isang tiered system batay sa scope:

Tier	Pangalan	Scope	Halimbawa
K0	Mga pundasyon	Universal na methodology	Disiplinang test-first, pagkumpleto batay sa ebidensya
K1	Mga identity	Role-based na workflow	CLI interface standard, performance playbook
K2	Mga domain	Domain-specific na kaalaman	Pattern ng database migration, validation ng authentication
K3	Mga stack	Specific sa teknolohiya	Cloudflare deployment, operasyon sa Supabase
K4	Proyekto	Ang codebase na ito lang	Workflow at convention na specific sa proyekto

Lazy-loaded ang mga skill. Nakikita ng isang agent ang mga pangalan at deskripsyon ng skill sa startup, pero nagloload lang ang buong laman ng skill kapag na-trigger. Pinapanatili nitong lean ang context habang ginagawang discoverable ang daan-daang skill.

Kasama sa bawat skill:

• Malinaw na trigger conditions (“Gamitin kapag nag-mimigrate ng database schema”)
• Step-by-step na gabay
• Mga allowed tool para sa workflow
• Success criteria at failure recovery paths

Sinasaklaw ng 466 skill sa registry namin ang lahat mula sa git worktree isolation hanggang sa web research workflows hanggang sa deployment health validation.

Bakit Mahalaga ang Orchestration

Mabilis na tumatama sa pader ang single-agent architectures:

Context dilution. Malaki ang tunog ng isang 200k token context window hangga’t hindi mo na-load ang mga database schema, API docs, test fixtures, at domain knowledge. Puwedeng magtrabaho ang mga specialist gamit ang targeted na context.

Salungatan sa instruction. Ang pagsabi sa isang agent na “maging thorough pero mabilis” at “i-verify ang lahat pero huwag mag-over-engineer” ay gumagawa ng tension. Sinosolusyunan ito ng mga specialist sa pamamagitan ng pagkakaroon ng malinaw na scope.

Lalim ng expertise. Kaunti lang ang alam ng isang generalist agent tungkol sa lahat. Malalim naman ang alam ng isang specialist agent, na naka-compose gamit ang tamang identity at skills, tungkol sa domain nito.

Nagpapatupad ang Orkestra ng flat orchestration: isang orchestrator ang nag-coco-coordinate ng maraming specialist. Hindi puwedeng gumawa ng sub-specialist ang mga specialist. Pinipigilan nito ang complexity explosion habang binibigyang-daan ang parallel na trabaho.

May access ang orchestrator sa 2.2 milyong token ng effective capacity: ang sarili nitong 200k window dagdag pa ang 10 concurrent na subagent na may 200k bawat isa. Komportableng tumatakbo sa buong fleet ang trabahong magpapaubos sa isang solong agent.

Ang Rendering Pipeline

Nakatira sa YAML ang mga agent definition. Binabasa ng Claude Code ang Markdown. Ini-bridge ng Orkestra ang puwang na ito gamit ang isang deterministic na rendering pipeline:

YAML Registries → Jinja Templates → .claude/agents/*.md

Ini-edit ng mga operator ang YAML source. Patakbuhin ang orkestra sync. Lumalabas ang rendered Markdown sa .claude/agents/. Kinukuha ng Claude Code ang mga pagbabago.

Ang paghihiwalay na ito, naglilingkod sa iba’t ibang audience:

• Kasama sa YAML source ang lifecycle metadata, tags, validation rules, at deprecation notes para sa tooling
• Kasama lang sa Rendered Markdown ang kailangan ng model: description, tools, skills, at behavioral guidance

Kino-compose ng pipeline ang mga identity, mindset, style, at skills papunta sa iisang coherent na prompt. Napakaiba ang system prompt ng isang architect-analytical-concise na agent kumpara sa isang debugger-skeptical-technical na agent, kahit magkapareho sila ng ilang underlying na skills.

Domain Knowledge: Ang Four-File Pattern

Sumusunod ang bawat knowledge domain sa isang consistent na structure:

domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes

Naglilingkod ang structure na ito sa agent context loading. Nagloload ang isang agent na nagtatrabaho sa authentication ng authentication/patterns.md para sa gabay at authentication/anti-patterns.md para maiwasan ang mga kilalang patibong. Ang mga file, sinukat para sa efficient na context loading: focused nang sapat para maging kapaki-pakinabang, comprehensive nang sapat para maging authoritative.

Pinapanatili namin ang 21 top-level na domain kasama ang analytics, authentication, agham ng datos, infrastructure, machine learning, performance, security, at marami pang iba. Puwedeng magkaroon ng sub-domain ang bawat domain para sa mas mainam na granularity.

Values: Ang Operating System

Nagbabahagi ang lahat ng agent ng isang base layer ng values na tumutukoy kung paano sila gumagana:

Unahin ang pagiging simple. Gamitin ang pinakasimpleng solusyon na gumagana. Magdagdag ng complexity lang kapag may dahilan.

Ayusin ang ugat ng problema. Huwag kailanman itapal ang paligid ng mga pagkabigo. Kung nabigo ang isang pipeline, i-debug ang pipeline. Kung nabigo ang isang test, ayusin ang code o ang test.

Evidence-based. I-label ang mga claim bilang “verified” (may benchmarks) o “estimated” (may assumptions). Hindi katumbas ng nakumpirmang problema ang isang na-detect na pattern.

Context economics. 0.1% ng context ang halaga ng mga MCP tool. 2% bawat isa ang halaga ng file reads. Ilapat ang domain expertise bago mag-explore ng code.

Kumakalat ang mga values na ito sa bawat specialist sa pamamagitan ng rendering pipeline. Hindi ito puwedeng balewalain ng isang agent sa pamamagitan ng composition.

CLI: Ang Control Plane

Dumarating ang Orkestra kasama ng isang CLI para sa pamamahala ng agent ecosystem:

# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"

Ang CLI ang source of truth kung anong mga agent ang umiiral, anong mga skill ang meron sila, at kung malusog ba ang system. Nagpapatakbo ito ng validation bago mag-sync para mahuli nang maaga ang mga problema.

Mga Konsiderasyon sa Open Source

Ginawa namin ang Orkestra para solusyunan ang sarili naming problema: pag-coordinate ng mga AI agent sa malaking sukat para sa isang komplikadong codebase. Ang mga pattern na natuklasan namin, hindi eksklusibo sa domain namin.

Ang character composition system (identity + mindset + style) ay umaapply sa anumang team na nagde-define ng agent personalities.

Nagbibigay ang skill tier system (K0-K4) ng mental model para sa pag-organisa ng reusable na capabilities ayon sa scope.

Ang rendering pipeline pattern (YAML source + templates + generated artifacts) ay naghihiwalay ng mga concern sa pagitan ng tooling at model consumption.

Iniiwasan ng flat orchestration model (isang coordinator, maraming specialist) ang complexity habang binibigyang-daan ang parallelism.

Ang kung magiging open source man ang Orkestra, nakadepende sa kung may value ba ang mga pattern na ito para sa iba na bumubuo gamit ang Claude Code. Kung tumatama ka sa mga pader na inilarawan namin, puwedeng makatulong ang architecture.

Ano ang Natutunan Namin

Itinuro sa amin ng pagbuo ng Orkestra na hindi tungkol sa paggawang mas matalino ng mga agent ang orchestration. Ito ay tungkol sa paggawa sa kanila na mas focused.

Isang solong agent na may perpektong instruction, uubusin pa rin ang context nito. Isang solong agent na may lahat ng skills, malilito pa rin kung alin ang ilalapat. Isang solong agent na sinusubukang maging lahat, gumagawa ng katamtamang resulta kahit saan.

Apatnapung specialist, bawat isa mahusay sa sariling domain, kino-coordinate ng isang orchestrator na alam kung kailan mag-delegate: ganoon kami nagship.

Hindi kasing halaga ng architecture ang mga numero. Baka limang agent lang ang kailangan mo o limampu. Nananatili ang prinsipyo: composition higit sa capability, specialization higit sa generalization, coordination higit sa individual heroics.

---

Pinapatakbo ng Orkestra ang agent ecosystem sa likod ng Maguyva, ang code intelligence platform namin. Gustong matuto pa? Makipag-ugnayan sa team.