How maestria Works

maestria applies Harness Engineering: the model supplies capability, while the harness supplies the method that makes work repeatable. Here the harness is a dispatcher, specialist roles, explicit handoffs, and independent verification.

request -> route -> focused work -> evidence -> result

Pipeline & Roles describes the mechanics. This page explains the intended benefits and their limits.

The Core Model

The orchestrator decides which work is needed and delegates it to one or more of the 7 specialists. A specialist returns a focused artifact: reconnaissance, a decision, a plan, an implementation, a diagnosis, a review, or documentation.

Boundary	Purpose
Focused specialist	Keeps one concern and its evidence in view
Handoff	Carries the context, constraints, acceptance evidence, and next step
Stage gate	Stops the workflow when the output is incomplete or unsafe
Independent reviewer	Checks the maker’s result without editing it

Direct execution remains valid for small, familiar work. Delegation earns its cost only when it adds information, reduces risk, or provides an independent check. The route is adaptive: a small change may go directly to a worker, while research-only requests stop after the thinker stage; Pipeline & Roles covers sequencing and rejection handling.

Designed Benefits

Benefit	How the harness provides it
Focus	Specialists receive a narrow responsibility instead of one prompt mixing discovery, design, implementation, and review.
Earlier correction	Thinkers can expose missing context or a bad approach before a worker implements it.
Independent validation	The reviewer is a separate, read-only role with different incentives from the maker.
Bounded failure	Repair loops use a verifiable stopping condition: one repair pass after review, capped at three, then escalate if progress stops.
Consistent expectations	Global rules define evidence, authorization, escalation, and commit behavior across integrations.

These are design goals, not guarantees. Quality still depends on the task, model, host runtime, and the evidence produced.

How Much Process to Expect

Specialists choose the investigation and checks that establish the outcome, not a fixed ritual: a diagnosis may use Git history or search similar code, and extra skills load only when relevant. The implementer runs affected checks, the delivery owner runs repository gates on the integrated result, and host permissions still require authorization.

A specialist’s partial result is a handoff, not completion: the orchestrator owns the remaining work through the agreed outcome, while research-only work ends at the requested artifact.

What Depends on the Platform

Native integrations can provide stronger runtime boundaries: read-only permissions, lifecycle hooks, or native subagents. The Agent Plugin package provides skills and contracts, while the client owns discovery, permissions, activation, and session behavior.

Context inheritance and parallel dispatch also differ: a new specialist session may still inherit part of its parent’s context, so treat the handoff as the reliable boundary and read the platform guide before relying on a permission or lifecycle claim.

What It Does Not Promise

It does not make every task faster than direct execution.
It does not replace the host’s sandbox, permission system, or model configuration.
It does not make advisory rules into security controls.
It does not remove the need for tests, evidence, or human judgment on consequential work.