AI Agents: Orchestration

Orchestration and Multi-Agent Coordination

• The industry consensus is shifting from wanting a single powerful agent to wanting one coordinator agent that manages teams of sub-agents -- the "1 agent who runs teams of agents" mental model is becoming dominant (from agent orchestration coordination)
• Agent swarms fail not from technical limitations but from coordination failures: task assignment, deduplication, handoff, and human-in-the-loop monitoring are the unsolved UX problems (from agent orchestration coordination)
• Discord-as-OS pattern for agent orchestration: a coordinator spawns agents into structured channels, agents work in parallel and spawn sub-agents ("interns") for subtasks, then terminate them when done (from agent orchestration coordination)
• The winning agent orchestration solution likely will not come from a single AI lab -- it will be a mix of closed/open source models combined with deterministic orchestration logic (from agent orchestration coordination)
• Hermes Agent v0.12.0 ships Kanban-based multi-agent coordination: agents claim tasks from a shared board, work in parallel, and hand off when blocked — a unified dashboard view replaces juggling multiple terminal windows (from hermes agent multi agent kanban v012)
• Discord-as-intake / Kanban-as-execution split: plain-English Discord commands feed a bridge that creates real tasks in Hermes Kanban, then mirrors them back to a Discord task board for mobile access — the two don't sync natively so the bridge is the integration point (from hermes discord kanban orchestration)
• gstack turns Claude Code from a solo assistant into a 6-specialist AI team (CEO, Eng Manager, Designer, Release Manager, Doc Engineer, QA Lead) installable in 30 seconds — the CEO agent challenges every decision ("why does this need to exist?") before any code is written, the Designer ships 4-6 variants and picks a winner, and QA Lead runs real browser tests (from gstack claude code ai team)
• @conductor_build lets a single workflow switch between Claude Opus (feature planning) and GPT-5.5 (plan review to catch issues pre-development) without managing separate interfaces — multi-LLM orchestration as a ~$400/month full-dev-team substitute (from multi llm development workflow conductor)
• The highest-leverage skill in agentic engineering is ascending layers of abstraction: setting up long-running orchestrator agents with tools, memory, and instructions that manage multiple parallel coding agent instances (from karpathy coding agents paradigm shift)
• A Codex remote-development network makes orchestration physical: one always-on primary Mac writes all code, while iPhone/iPad/secondary Macs issue commands and Tailscale lets agents traverse the private device graph (from codex remote development network setup)

Always-On and Background Agents

• Running always-on AI agents via macOS launchd creates a "staff" that works asynchronously -- producing a daily brief by 9am without manual triggering, turning the OS scheduler into an agent orchestrator (from always on agents launchd obsidian)
• Using Obsidian as the documentation layer for agent outputs means all agent work products are stored in a human-readable, searchable, linked knowledge base rather than ephemeral chat logs (from always on agents launchd obsidian)
• A weekly AI coaching conversation that reviews meeting transcripts, task progress, and goal alignment represents a new pattern: agents as accountability partners, not just task executors (from always on agents launchd obsidian)
• An "AI-native agency OS" pattern is emerging where AI agents continuously scan client communication channels, auto-classify incoming work, assign it to team members, and suggest next steps in real time (from ai native agency os)
• The value proposition of agent-powered operations is shifting the team's role from triaging/organizing work to pure execution -- the AI handles intake, classification, routing, and prioritization (from ai native agency os)

Agent Operating Systems and Command Centers

• NovaStation is a personal AI operating system as a unified command center — Mission Control tracks active systems/agent lanes/health/memory/alerts/approvals, plus dedicated lanes for market intelligence (Market Swarm), content automation, business operations (Gemini-powered), product builds, persistent memory (NovaForget), remote machine control (Tailscale + OpenClaw Node), and live Gmail/Calendar panels (from novastation ai operating system command center)
• The dashboard pattern: AI stops being a tab and becomes the OS — agents, tools, memory, automations, products, content, markets, and operations all live in one interface, eliminating app-switching overhead (from novastation ai operating system command center)
• See Hermes Agent for the Hermes ecosystem (Workspace, Curator, Atlas, deploy/ops generalist, research-agent recipe) — Hermes has its own dedicated topic.

Finance Agents as Multi-Agent Reference Architectures

• See Ai Trading for the full set of finance/trading multi-agent reference architectures (FinceptTerminal, virattt/ai-hedge-fund, TauricResearch/TradingAgents, HKUDS/Vibe-Trading, Kronos, daily_stock_analysis, AI-Trader). Trading has its own dedicated topic; the cross-cutting takeaway here is that multi-agent debate (investor-style agents arguing before a Portfolio Manager casts the vote) is now the dominant reference pattern for high-stakes, structured-outcome verticals.
• AutoHedge spins up an autonomous hedge fund in minutes — agent-economy primitive applied to markets, parallel to Single Brain's specialized-agent fleet pattern (from ai automation github repositories passive income)
• Vibe-Trading packages 64 finance skills and 29 specialist swarms in a DAG model where agents debate strategies in real time, including crypto liquidation heatmaps and token unlock tracking as orchestration inputs (from free github repos replacing paid tools)
• AutoHedge's four-agent split (director, quant, risk manager, execution agent) shows autonomous trading systems becoming productized as explicit role orchestration, not monolithic bots (from free github repos replacing paid tools)
• ClawRouter (re-surfaced): routes 41+ LLM models in <1ms, cuts AI API costs up to 92% — the smart-routing layer is now table stakes for cost-sensitive agent stacks (from ai automation github repositories passive income)
• Camofox Browser is an anti-detection browser specifically for agents to avoid being blocked while scraping/automating; web crawling infrastructure is becoming first-class for agent data ingestion ("crawl army so agents can read it all") (from ai automation github repositories passive income, web crawling agents data access)
• Agentic Inbox runs on Cloudflare Workers as a self-hosted email agent: receives → classifies → drafts, with human approval before send — same "draft don't send" guardrail Jim Prosser identified, now packaged as deployable infra (from ai automation github repositories passive income)

Quality Gates and Adversarial Review

• Adding an adversarial subagent review gate before marking tasks as done significantly improves plan quality and execution duration in goal-oriented AI systems (from adversarial subagent review gate quality improvement)
• Use the specific prompt 'update this plan: before marking a task as done, validate the task with an adversarial subagent review' to implement quality validation in AI agent workflows (from adversarial subagent review gate quality improvement)
• Adversarial review patterns prevent premature task completion and create longer-running, higher-quality agent execution cycles (from adversarial subagent review gate quality improvement)
• Set up a single persistent Codex thread as a 'chief of staff' that manages all other project threads and maintains context from Slack integrations — everything flows naturally to the top (from codex chief of staff thread management)
• Configure the chief of staff thread to automatically spin up new project threads when starting workstreams, inheriting relevant context from Slack and other sources (from codex chief of staff thread management)
• Implement regular 'heartbeat' check-ins where the chief of staff thread monitors project threads and routes relevant Slack updates to appropriate project contexts (from codex chief of staff thread management)
• Codex now provides autonomous thread management capabilities — thread creation, search, organization, pinning, and spinning up parallel worktrees for concurrent tasks without developer intervention (from codex self managing development environment)

Agent Development Methodology

• Follow a repeatable 5-step agent development cycle: Do it manually first, skillify the task, add to cron for automation, check if resolvable, then run evals and integration tests — repeat (from ai agent development methodology garry tan)
• Use component-based agent architecture where gbrain handles memory, OpenClaw handles approvals/actions, and trajectory bundles handle self-checking (from ai agent development methodology garry tan)

Human Coordination Around Agents

• Complete AI automation at Every increased human headcount from 4 to 30 since GPT-3, suggesting the output of automation often creates more coordination, oversight, and strategic work rather than removing humans from the system (from ai automation increases human work demand)

Research Agents and Council Workflows

• Hermes-based research agent in 6 steps: pick a domain, give it sources (X lists, RSS, GitHub repos, newsletters, YouTube transcripts), define signal criteria, save evidence to a vault, deliver daily briefs to Discord/Slack/Notion/Obsidian/markdown, give feedback ("more like this," "noisy," "useful," "mid") — research-as-substrate for content/trading/sales/coding agents (from hermes research agent workflow)
• Perplexity Computer's Equity Research Council pulls research from GS/JPM/MS/Evercore in 2 minutes and surfaces where they agree vs disagree — multi-analyst comparison in a 2-minute workflow, mimicking how top hedge fund PMs evaluate (from perplexity equity research council workflow)

agent-orchestration-layers

• Reliable agent work is a five-layer control system: prompt engineering (instructions/format), context engineering (what info/tools/state enter each step), harness engineering (runtime/permissions/retries), workflow engineering (order/parallelism/approvals), and backpressure (gates/tests/evals that decide if work proceeds). Prompt is the smallest lever. (from smithers context engineering doctrine)

reversibility-design

• Split irreversible actions from decisions: have an agent return a typed decision (e.g. shouldPay/amount/reason) as its own task, then gate the actual side effect (wire transfer, deploy) behind a separate approval-gated task keyed for idempotency. This makes the decision reviewable/replayable without risking the irreversible act. (from smithers context engineering doctrine)

context-management

• A model call is stateless — context is the only lever. Every tool action is one of three moves: delete incorrect context (false anchors are worse than missing info), add missing context (tests, diffs, stack traces), or remove useless/finished-task residue. Rule of thumb: if you'd /clear it, remove it. (from smithers context engineering doctrine)
• Protect the orchestrator's own context: it's the one process alive for the whole run, so never read large artifacts (diffs, logs, candidate branches) directly into it. Spawn disposable sub-agents to read/judge and return a one-paragraph verdict, keeping the orchestrator lean enough to run all day. (from smithers context engineering doctrine)
• Durable '/clear' pattern: combine a hard token ceiling () that throws ASPECT_BUDGET_EXCEEDED, an error boundary catching that code, and to close the current run and start a fresh one carrying only distilled state (goal, generation, last summary, capped learnings) — automating context handoff without residue. (from smithers context engineering doctrine)
• Concurrency per thread defaults to four agents (including coordinator) and is configurable; fork_turns:"none" gives an agent fresh context instead of inherited history, but fresh-context agents lose the parent's tool/safety boundaries and need those restrictions restated explicitly. (from codex multi agent orchestration roles)

context-budget

• Agents perform best under ~200k tokens of context, noticeably better under ~100k ('the smart zone'); past that, attention thins and quality drops. Design workflows so research/planning happen before implementation, keeping the implementer's window free for the actual work. (from smithers context engineering doctrine)

backpressure-design

• Command/test gates should classify failure evidence before marking work red: only actual diagnostics (e.g. 'error TS...', a failed-test report) count as proof of a bad patch. A nonzero exit, timeout, or OOM with no such evidence is infrastructure failure — retry with more headroom rather than surfacing as red. (from smithers context engineering doctrine)

planning-validation

• A complex feature attempted cold one-shots ~40% of the time; the same feature preceded by a vetted plan with teeth (named tests, acceptance criteria, machine-checkable definition of done) plus real backpressure one-shots ~98%. Review the plan (cheap), test the output, skip reading the diff (expensive and gets skimmed). (from smithers context engineering doctrine)

task-decomposition

• Decompose agent tasks into vertical feature slices (frontend+API+schema together end-to-end), not horizontal layers across all features — boilerplate only should be built horizontally first. Vertical slices give real e2e-testable backpressure and keep a feature's context colocated instead of scattering contracts across windows that drift at integration. (from smithers context engineering doctrine)

graph-fundamentals

• An edge only exists if data actually moves between two steps — 'do A and then B' is not an edge unless B reads A's output; otherwise it's two independent nodes needlessly forced to wait in sequence. (from graph engineering claude code 14 step roadmap)
• The canonical agent graph topology is the diamond: fan out (parallel search/review), reduce (plain code compression), synthesize (final agent writes the answer) — this fan-out→reduce→synthesize skeleton underlies market scans, dependency audits, code reviews, and research reports alike. (from graph engineering claude code 14 step roadmap)

agent-contracts

• Give every agent node a contract: bounded input, one job, and a JSON schema-validated output. In Claude Code's agent() calls, a schema forces the subagent's structured output and triggers automatic retries on mismatch instead of returning unparseable free text. (from graph engineering claude code 14 step roadmap)
• Claude Code's parallel() fans out an array of thunks to concurrent subagents, acts as a barrier (waits for all before returning), and resolves failed thunks to null rather than rejecting the whole batch — always .filter(Boolean) the results to avoid one flaky agent sinking the run. (from graph engineering claude code 14 step roadmap)

cost-optimization

• Reduce/merge steps (flatten, dedupe, filter across fan-out results) should be plain JavaScript, not another agent call — combining results via code is deterministic and free; spawning an agent to 'combine results' wastes tokens on plumbing rather than judgment. (from graph engineering claude code 14 step roadmap)
• Tier models per node and default to pipeline() over parallel(): route repetitive/bounded nodes to cheaper models while reserving the expensive model for synthesis/judgment nodes; pipeline() streams items through stages without a barrier so fast items don't idle behind slow ones, while parallel() forces everything to wait for the slowest node — reserve barriers for stages that truly need the full result set (cross-set dedupe, early-exit checks). (from graph engineering claude code 14 step roadmap)

verification

• Verifier nodes should sit on edges before results pass downstream: adversarial verify (N skeptics try to refute a finding, majority must survive), perspective-diverse verify (distinct lenses like correctness/security/repro), or judge panels (score N attempts, synthesize from the winner). (from graph engineering claude code 14 step roadmap)

convergence

• For unbounded discovery tasks (e.g. bug sweeps), use a loop-until-dry cycle: keep spawning finders until K consecutive rounds surface nothing new. Critical detail — dedupe against everything ever seen, not just confirmed results, or rejected findings resurface every round and the loop never terminates. (from graph engineering claude code 14 step roadmap)

loop engineering

• Loop engineering reframes agent work as five-stage cycles (discover, plan, execute, verify, iterate) run without a human in the loop at every step, contrasted with prompt engineering where a human remains the feedback mechanism after every response. (from agent evals and loop engineering)
• Loop engineering has a hidden cost problem: a medium coding loop can use 50K-200K tokens, an orchestrator-plus-specialists fleet can use 500K-2M tokens, and a daily-scheduled loop can burn millions of tokens weekly — making cheap, high-context, reliable-tool-calling models a prerequisite for practical loops rather than expensive experiments. (from agent evals and loop engineering)
• Closed loops (defined objective, stages, evaluation after each stage, explicit stop condition, human handoff on failure) are recommended as the starting point over open loops (broad goal, exploratory), because open loops can drift, waste tokens, and become hard to control; open behavior should only be added once verification checks are strong. (from agent evals and loop engineering)
• Six building blocks make agent loops work in practice: automations (trigger without manual start), worktrees (isolated branches so parallel agents don't collide), skills (reusable project knowledge files so runs don't cold-start), plugins/connectors (GitHub, Slack, Linear, Jira access), subagents (separate maker from checker to avoid self-forgiving review), and memory (persistent logs/tickets/markdown so the loop remembers past attempts across runs). (from agent evals and loop engineering)

multi-agent orchestration

• Swarm composition pattern: mix model providers within one coordinated swarm — 3 'cod' instances (gpt-5.6 on maximum thinking effort) plus 3 'cc' instances (Opus 5 on xhigh thinking effort) — rather than a homogeneous fleet of one model. (from multi agent swarm orchestration prompt)
• Before spawning any swarm, require agents to fully read AGENTS.md and README.md, then run a code-investigation agent pass to understand architecture and purpose — establishing shared context prevents wasted/conflicting agent work later. (from multi agent swarm orchestration prompt)
• Use a /loop tool firing every 4 minutes to detect idle agents and feed them fresh instructions, sourced from an open-issue tracker ('bv'/beads) — keeps a large swarm continuously utilized without manual babysitting. (from multi agent swarm orchestration prompt)
• Stale work-item detection: periodically scan for beads marked 'in progress' with no recent activity (likely orphaned by dead agents) and reopen them as 'open' so other swarm agents can pick them up. (from multi agent swarm orchestration prompt)
• Prevent build contention in multi-agent swarms by routing all builds/tests through a shared build-cache/coordination skill (rch) and by explicitly avoiding concurrent builds of the same project within a swarm. (from multi agent swarm orchestration prompt)
• Escalation ladder for when a swarm runs out of tracked work and review rounds saturate (diminishing bugs found per token spent): fall back to generic quality-improvement skills — mock-code-finder, deadlock-finder-and-fixer, reality-check-for-project, profiling-software-performance, extreme-software-optimization, running-the-gauntlet-on-your-rust-port — to generate new work items automatically. (from multi agent swarm orchestration prompt)

agent harness design

• Three design requirements for reliable GTM agents: (1) a composable context layer where agents read/write a live shared account view, (2) a real harness (short episodes, memory, triggers, evals, human approval points) rather than just 'shipping an agent', (3) playbooks as an orchestration layer defining who/why/message/channel that agents execute. (from ramp revenue gtm coworker)

agent-driven experimentation

• Prediction: GTM agents will evolve from executing predefined playbooks to driving experimentation themselves — proposing new plays, killing underperforming ones, and sharpening with every interaction. (from ramp revenue gtm coworker)

agent-role-design

• Codex Multi-Agent V2 defines three default roles by reasoning effort: Scout (GPT-5.6 Sol Light) for narrow read-only investigation, Worker (Sol Medium) for scoped implementation, and Smart worker (Sol High) for hard problems or coordinating other agents. (from codex multi agent orchestration roles)
• Ultra mode makes multi-agent coordination the default and should be reserved for high-stakes, ambiguous, or context-scattered work; for routine tasks a short prompt/skill on Sol Medium achieves similar collaborative delegation while staying in conversation with the user. (from codex multi agent orchestration roles)
• A standing coordinator skill can codify defaults: send read-only scouts in parallel at reasoning_effort low with fork_turns none, use medium for routine implementation and high for harder problems, give each agent non-overlapping ownership, and keep approvals with the user. (from codex multi agent orchestration roles)

agent-coordination

• Agents in Codex message each other directly via separate inboxes, letting a scout pass findings straight to a worker without waiting for the coordinator to relay—reducing coordination latency in parallel investigations. (from codex multi agent orchestration roles)
• To prevent runaway delegation, leaf agents need an explicit boundary instruction: 'Complete this assignment directly. Do not spawn other agents; your parent's delegation instructions apply only to your parent.' (from codex multi agent orchestration roles)

agent-ticket-organization

• Tickets are organized as an outcome hierarchy (named after goals, not technical tasks) so agents can be encouraged to finish trees of epics down to the root, giving a high-level progress signal that vanilla agent-scattered backlogs lack. (from linear software factory agent management)
• Each ticket uses a fixed template — Goal, Why, Outcomes, Implementation approach, Verifications (Automated/Manual/Visual) — to act as a human-readable contract; agents are blocked from closing tickets until all checklist items are checked. (from linear software factory agent management)

agent-batching

• Work is organized into batches of 3-5 parallel, non-overlapping-code-area workstreams per cycle (30 min–4+ hours, 2-4 batches/day), proposed via a 'workstream update' skill that reads triage, checks in-progress work, and outputs 4-5 agent prompts to paste into Codex, Claude Code, Cursor, or Antigravity. (from linear software factory agent management)

multi-model plan validation

• Workflow: use Fable to write an initial plan, then explicitly prompt it to get second opinions from Codex CLI (gpt-5.6-sol @ max effort) and Kimi CLI (kimi 3), revising the plan with any sound findings. (from multi agent plan cross validation fable)
• The revision loop is bounded: repeat the cross-model review-and-revise cycle until convergence or up to 5 rounds, preventing infinite iteration while still allowing multiple correction passes. (from multi agent plan cross validation fable)
• This pattern treats different frontier models/CLIs (Fable, Codex/GPT-5.6-sol, Kimi 3) as independent reviewers for plan quality, applying an ensemble/consensus approach to planning rather than coding execution. (from multi agent plan cross validation fable)

self-improvement-loop

• 'Dreaming' is a proposed mechanism where agents review past sessions between runs to learn from mistakes and improve performance offline, rather than only learning in real time. (from anthropic self prompting agents)

production-guardrails

• Production-grade self-improving agent systems require explicit guardrails — versioning of memory/instructions and concurrency control — to prevent corruption or conflicts as agents modify their own state. (from anthropic self prompting agents)

context-scoping

• The primary benefit of multi-thread orchestration here is not parallelism itself but better-scoped context per thread — narrower context windows produce more focused, higher-quality reasoning than one large shared thread. (from codex thread manager scoped context)

agentic-productivity-metrics

• From Jan-June, Replit saw a 5.8x raw increase in lines of code contributed; controlling for hiring by keeping a consistent author cohort, output was 2.9x — effectively tripling per-engineer output while the team doubled in size. (from replit self driving company)
• Replit put its internal agent into the PR review loop as a co-reviewer that assesses risk and only escalates to a human when necessary, saving 30% (and growing) of human PR review time while code review latency stayed flat despite 3x volume. (from replit self driving company)
• Despite tripled code volume, PR reversion rates and incident counts stayed flat at Replit — attributed to agent-assisted code review catching more bugs and an agent that performs root-cause investigation during incidents, lowering mean time to mitigation. (from replit self driving company)

agent-orchestration-patterns

• Replit gave every employee a 'manager agent' that can spawn and orchestrate fleets of sub-agents in parallel loops on verifiable tasks (e.g., completing a stalled CSS migration, automating localization, fixing a hard PSC/fd-shutdown networking bug) — described internally as 'loop engineering.' (from replit self driving company)

self-improving-systems

• Replit's AI team built a continual learning system that analyzes user feedback, proposes improvements to Replit Agent, and validates them via benchmarks + A/B tests — making the agent self-improving without manual retraining cycles. (from replit self driving company)

build-vs-buy

• Replit found its internal agent outperformed purchased vertical SaaS tools: an alert-triage/incident tool and an automated pen-testing tool both matched or exceeded external product quality at roughly 1/10th the cost, leading Replit to churn a seven-figure SaaS contract. (from replit self driving company)

org-wide-agent-adoption

• Agent adoption spread from engineering (via a Slack interface) into sales, marketing, support, and data teams once a semantic layer was added over the data warehouse — enabling any employee to query business data reliably and build charts/presentations from live data. (from replit self driving company)

AI governance guardrails

• Layer 5 (operating principles): a per-repo safeguard file blocks certain operations, a human-ownership rule prohibits 100% AI output (someone is accountable for the full task, not just their 30%), and large tasks get split into 5-20 parallel sub-agents ('agent swarm') that merge results back. (from ai native company os 5 layers)

AI-native operating models

• System design principle: each layer only reaches full value because the prior one exists — company OS without context can't apply to real accounts; context without MCPs still requires manual execution; MCPs without a self-improvement engine never gets better; any of it without operating principles is a liability. (from ai native company os 5 layers)

loop taxonomy

• Loop engineering reduces to a choice among four structures — turn-based, goal-based, time-based, proactive — each defined by who/what answers two questions: what starts a run and what ends it. More handoff = less babysitting, but not 'more advanced' — the right choice depends on whether the task is exploratory, measurable, recurring, or standing. (from four types of agent loops)
• Turn-based loop: human prompts, agent acts, human reviews, human prompts again — both start and stop conditions stay with the human. Use when requirements are still forming and the path is unclear. (from four types of agent loops)
• Proactive loop: no human present — the agent watches a channel, spawns triage/fix/reviewer sub-agents, and closes the task itself. Use for standing duties whose triggers can't be predicted in advance. (from four types of agent loops)

loop mechanics

• A real loop has five stages (discover, plan, execute, verify, iterate) plus persistent external state (a file, Linear board, or log) and a hard stop condition (goal met or cap hit). The verifier must be an objective pass/fail gate — a second opinionated agent grading its own homework isn't a verifier and the setup collapses into an expensive script. (from four types of agent loops)

loop failure modes

• Two silent loop failure modes: the 'Ralph Wiggum loop' (agent declares completion on unfinished work because there's no hard gate — fixed by a dumber, opinion-free test/build) and 'comprehension debt' (fast unreviewed shipping widens the gap between what the repo contains and what the team understands). The real success metric is cost per accepted change — below 50% acceptance means the loop is net-negative. (from four types of agent loops)

agent orchestration

• Design principle 'agent, singular': users don't select a persona or toolset — a classifier reads the task prompt and routes it to the right repository, environment, harness, model, and reasoning budget, mirroring how Sierra hires people who move fluidly between disciplines. (from sierra pinecone internal agent os)

voice-orchestration

• Workflow: open ChatGPT Voice, ask for status + recommended next step on all current projects, approve recommendations, brain-dump on one project, iterate until an idea forms, then say 'start a thread on that' and 'what's next' — repeat across projects. (from chatgpt voice orchestrator workflow)
• Core principle: treat Voice as a chief of staff you ask questions of (more questions than commands), not a worker you command directly — Voice itself doesn't do the work, it hands off good ideas to dedicated agents/threads on your main machine. (from chatgpt voice orchestrator workflow)

agent-harness-mastery

• Recommended workflow sequence: (1) pick one tool, (2) enable YOLO/'Allow All' mode in a sandbox, (3) generate visual/HTML prototypes before coding, (4) use /plan mode to surface edge cases, (5) implement via Autopilot loop, (6) human review/iteration, (7) request a Rubber Duck review from a different model family, (8) commit. (from github copilot harness workflow)
• Copilot's Autopilot mode acts as an orchestrator: it auto-selects an 'Explore' subagent with a small model for file-reading tasks and a 'General Purpose' subagent with a larger model for complex actions—this multi-model subagent routing happens automatically without custom agents or instructions. (from github copilot harness workflow)

cross-model-review

• Rubber Duck review requests a second review from a different AI model family (e.g., Sonnet reviewing GPT output) to catch blind spots from differing training data; can be combined with Autopilot in a loop (/autopilot rubber duck...repeat until diminishing returns) for more thoroughly hardened code at higher token cost. (from github copilot harness workflow)

multi-model orchestration

• 'sol-advisor' is a free, open-source Codex plugin implementing a 4-role orchestration pattern: GPT-5.6 Sol High as orchestrator, Luna Max for routine implementation tasks, Terra Max for complex implementation tasks, and a fresh Sol instance as reviewer. (from sol advisor codex orchestration)

agent-architecture-layers

• Graph engineering answers 'what is allowed to happen next' via explicit nodes/edges/routing/concurrency. It's worth the added structure when there's meaningful branching, approvals, or parallel specialist handoffs; for a single agent with a few tools, a harness plus loops is sufficient and a graph adds premature rigidity. (from harness loop graph engineering)
• Diagnostic rule for agent failures: if the agent cannot operate at all, fix the harness (missing tools, stale state, bad permissions); if it almost works but is unreliable, fix the loop (inconsistent success, uncontrolled retries); if the process itself is complex, fix the graph (many specialists, branching, approvals). (from harness loop graph engineering)

model-cost-optimization

• Databricks uses task-level smart routing (via @omnigent_ai) to dynamically pick the most efficient model/harness per task, yielding ~30% additional savings on top of default model shifts. (from databricks ai cost reduction)

agent-planning-workflow

• Effective agent-factory planning workflow: describe idea in detail (dictation works), have Fable grill you with question batches to surface edge cases, then dispatch research subagents (Opus-tier) to ground/disprove ideas using internet + existing codebase evidence. (from fable planning workflow software factory)
• Recommended PRD structure for AI-driven projects: project context, goals, non-goals, success criteria, key users/journeys, functional/non-functional requirements, key architecture decisions, data model & flow, contracts & boundaries, security & failure modes, open questions. (from fable planning workflow software factory)
• After drafting a PRD, explicitly read/review it and set project-level cadence and policies (testing approach, documentation practices) before task decomposition—this prevents agents from making random, inconsistent decisions later. (from fable planning workflow software factory)
• Decompose PRDs into individual technical tasks ('beads') optimized for maximum parallelism, even accepting slight merge-conflict risk, because parallel execution speed outweighs the coordination cost. (from fable planning workflow software factory)
• Technical tasks should be detailed enough that an agent with minimal project context could complete them well, with explicit acceptance criteria; after decomposition, dispatch subagents to adversarially review tasks against the PRD to catch translation losses. (from fable planning workflow software factory)
• Heavy front-loaded planning (Fable + PRD + policy-setting + adversarial review) is the tradeoff that enables a software factory to execute large batches of work reliably, mostly or fully unattended, with escalations only for true blockers. (from fable planning workflow software factory)

agent workflow phases

• Program design—specifying types, method signatures, call stacks, and file layout before implementation—is a phase most teams skip but Dex argues is essential; visual pseudocode representations (including diff syntax for changes) make this alignment fast and cheap. (from show me visual coding agents software factories)
• Proposed fix: use 'vertical slices' (build API contract→frontend→services→DB incrementally, testing/reviewing 100-200 lines at a time) instead of models' default 'horizontal plans' (full-stack-order in one shot), since frontier models won't design vertical slices without explicit human steering. (from show me visual coding agents software factories)

lights-off factory failure

• HumanLayer's internal 'lights-off' software factory experiment (July 2025, no human code review) failed repeatedly: unsolvable gnarly bugs surfaced after months of unread agent code, causing outages; by the third failure they rewrote the codebase from scratch by hand. (from show me visual coding agents software factories)

parallel-agent-workflows

• Each task gets its own agent on its own git branch/worktree rather than queuing tasks in one session — enables running ~20 parallel sessions without cross-contamination of files. (from how i work with coding agents)

agent-orchestration

• Multiple specialized single-domain bots placed in a group chat can pass work to each other and self-coordinate (e.g. one bot reproduces a bug, files a ticket, hands debugging to another)—giving the group an objective rather than a task list lets them do their own decomposition. (from grok bot agent teams tutorial)

plan-then-delegate-execution

• For stalled 'evergreen' projects that earlier models couldn't complete, the suggested pattern is: send the frontier model project files, have it run existing tests and trace failed workflows, produce a prioritized change plan with per-change pass/fail checks, then hand the defined execution plan to cheaper models for implementation. (from gpt6 astra first three workflows)

agent-harnesses

• YC's internal agent harness (QM, built by Josh France and JB Ellregan) evolved into OpenClaw running a fleet of ~50 agents; a key design shift was 'pulling the brain out of the sandbox' and letting agents choose their own sandbox and model rather than fixing these at build time. (from yc ai harnesses deep dive)
• YC's 'grind tool' enforces budgets tied to goals rather than raw compute limits, but even with this, agents still struggle to understand social context — a noted unresolved limitation in current harness design. (from yc ai harnesses deep dive)

agentic GTM workflow

• Restructuring GTM around Claude Code as orchestrator (with tools like ColdIQ MCP as endpoints) cut a campaign build from two days of manual CSV-shuffling across four SaaS tools to one prompt and ~20 minutes of agent work. (from gtm on claude code agentic outbound)

agent-role-decomposition

• Cold outbound GTM is decomposed into four persistent GrokBot agents—list builder, outbound copywriter, campaign manager, infrastructure manager—each owning one artifact (lead list, copy, campaign build, sending health) with one owner and one definition of done. (from gtm agent team grokbot astra)

multi-agent-coordination

• Reliable multi-agent handoffs rest on three mechanisms: naming as join key (campaign name = list name so no bot has to ask what belongs where), task-state-as-trigger (marking a task complete fires a webhook waking the next bot, no human forwarding needed), and 'blocking out loud' (a bot missing an input posts what it needs and stops rather than guessing). (from gtm agent team grokbot astra)

multi-agent-shared-state

• Ars Umbris positions itself as a 'meta harness': it connects multiple agent harnesses (Claude Code, Codex) via MCP adapters to one shared durable workspace state, so separate agent sessions with independent context can still read/write the same files and continue each other's work. (from ars umbris knowledge ide alpha)

automated-adversarial-testing

• Parallelizing adversarial/browser-driven test runs across many instances makes exhaustive pre-release stress testing economically viable even for small teams. (from parallel adversarial browser testing)