frameworks/

AI agent orchestration makes responsibilities visible. A useful framework gives each step a job, a boundary, and a way to pass work on without burying the decision inside a prompt. The engineering rule still applies: interfaces and process limits must be inspectable. Orchestration adds another question: who acts next, with which context, and under whose authority?

Make the workflow visible

The harness is the product sets out the basic shape. Reliable multi-agent work depends on a durable scaffold with stages, routing, artifacts, gates, and human checkpoints, not a loose sequence of chats. An agent harness is the execution scaffold around the model; a multi-agent pipeline gives distinct roles bounded handoffs inside it. An orchestrator agent routes tasks and tracks state, while a subagent does fresh-context, bounded work and returns an inspectable artifact.

The pipeline that wrote this shows that structure in an authoring system. Named and versioned stages, cold inspection, figure grounding, and cross-model review make the work easier to reason about than a request to trust finished prose. The design is not universal. The essay keeps reversibility and stakes as real boundaries on unattended work.

The layer between wording and wiring separates three failure surfaces. Prompt wording shapes the request, runtime context determines what the model can see, and harness wiring controls routes, permissions, and enforcement. Harness engineering changes those routes, read scopes, gates, and failure paths rather than asking a reviewer to compensate for a structural mistake.

Keep the context tension and the gates honest

The corpus does not settle boot-time injection versus tool-driven retrieval as one preferred pattern. Injection is the right response when required context exists behind a retrieval tool but logs show the model does not call it. Retrieval is the right response when preloading context fills the window with material the question never uses. In that design, a tool-calling loop lets the model request context, lets the harness execute the request, and returns the result. The harness owns the choice, but logs must show which failure regime is present. Semantic search alone did not change the injection choice in the cited Rheo case.

Gates need an equally narrow job. Gate the flow, not the judgment limits a gatekeeper to proceed, revise, or escalate against the current artifact. A gatekeeper agent can halt a run; a critic agent gives cold, non-binding review. Who checks the checker? explains why several agreeable reviews still do not replace access to ground truth, and why a genuine gate must sit outside the process it evaluates.

The pillar also includes fit decisions that do not need to become universal rankings. Static Next.js versus WordPress settles one such choice through a site's content model, editing path, maintenance ownership, and feature limits. It belongs here because the decision arranges work and responsibility around a specific publishing system.

Where to start, and where this hub ends

Start with Skills, subagents and MCP: where logic lives to place reusable instructions, delegated work, and integrations. Continue to Claude P backend process for a concrete runtime boundary, then MCP tool design for the interface constraints that shape safe requests. Those three engineering essays lead into the harness, context, and gate essays in this hub. Move to engineering for tool contracts and backend implementation, and to memory only when the question is retention or retrieval itself.