--- title: "The structured-work harness: a gated, artifact-driven engine for multi-agent knowledge work" slug: structured-work-harness audience: buyer publisher: PortableMind published: 2026-05-29 --- # The structured-work harness ### A domain-agnostic, gated, artifact-driven engine for multi-agent knowledge work > Most "AI agent" products are a chat box wrapped around a model — great at answers, > poor at work. Real knowledge work is a pipeline of artifacts passing through gates. > PortableMind's harness is a general structured-work engine built on that idea, in > which SDLC is simply the first configuration. Swap the vocabulary and the same engine > runs a proposal team or an authoring team. ## Why chat-shaped agents fail at real work - **No memory of the contract.** A handoff carried in conversation evaporates — the next agent reads a scrollback, not a spec, and drifts. - **No independent checks.** A single model reviewing its own output is a weak check. Real quality needs an *independent* reviewer with fresh context and an adversarial mandate. - **No traceability.** When the output is wrong, you can't point to *which requirement* was missed, because requirements were never first-class. - **No control.** No budget, no gates, no "stop and let a human decide here." The harness fixes each of these structurally — not with a better prompt, but with an architecture. ## The architecture — five primitives 1. **Pipeline** — a fixed sequence of phases for a domain. 2. **Artifact** — every phase emits a typed, persisted, *organized and linked* deliverable (`/workflow////…`). The artifact is the contract that crosses each handoff — never a conversation. It can't evaporate, and it's findable forever. 3. **Gate** — every handoff crosses an approval checkpoint with an explicit *holder* and *criteria*. 4. **Role** — independent agents own phases; the producer is never the reviewer. 5. **Traceability spine** — one keystone artifact (acceptance criteria, a compliance matrix, an outline) threads numbered requirements through production, review, and verification, so nothing slips silently. The keystone is the highest-leverage idea: it is the *one* gate whose failures **propagate** — get it wrong and you produce, review, and verify the wrong thing, correctly, then ship a miss. Every other gate catches errors; the keystone gate prevents them. Every domain has one. ## One engine, many domains The same engine, different configuration. Adding a domain is **a YAML file**, not an engineering project — five ship today (SDLC, RFP response, bug-fix, code-improvement, meeting-notes). | Phase | Software (SDLC) | RFP response | Book | |---|---|---|---| | Keystone | acceptance criteria | compliance matrix | outline | | Produce | code + tests | response sections | chapter drafts | | Review | code review vs criteria | SME review | editorial pass | | Verify | tests vs criteria | **compliance check vs the RFP** | continuity vs outline | | Ship | merge + deploy | submit | publish | ## Internal, resale, or autonomous — the same pipeline Internal use, a resellable product, and full autonomy are not three systems — they are the **same pipeline with different gate-holders.** A gate's holder is recorded as data (a human *or* an agent). You don't rebuild to move between them; you change who approves. - **Internal:** humans hold the judgment gates; agents do the work and the independent checks. - **Resale:** ship the pipeline + an agent **role pack** (a team of agents, each carrying its portable best-practice memories) — the customer holds the judgment gates. - **Autonomous:** a drafting agent holds the keystone gate; a human batch-approves; ship/submit stays human, always. You earn each human→agent move with measured escape-rate data. This is the product written into the architecture: *"we run this internally — here is the team that does it for you."* ## Why it is the strongest harness available - **Artifact-as-contract** — durable, organized, linked, traceable deliverables, not chat. - **Structural independence** — reviewer ≠ producer, enforced in every configuration. - **Traceability spine** — requirements thread into the *tests* themselves (a generated test suite cited the exact acceptance-criteria IDs and edge cases). - **Governed autonomy** — per-execution and per-stage cost limits, timeouts, retries with backoff, conditional routing, mid-stage human questions. - **Resale-native** — agents export with their configuration *and* their curated expert knowledge (memories), so a packaged team arrives already knowing how to work. - **Reconfigurable** — internal → resale → autonomous without a rewrite. ## Proof, not promises The harness has been run end-to-end with real models and real artifacts: - A feature request decomposed by a product-owner agent into an organized acceptance-criteria spec → human approval → an engineer agent implemented **to the criteria** (with tests citing the criterion IDs) → an **independent reviewer** approved a real merge request. - A customer bug ticket ran the same loop with the engineer drafting the spec — fix + tests + review, all traceable to the ticket. - Every gate, artifact, and handoff was recorded; failures surfaced as concrete, fixable findings — and the fixes (isolated work contexts, deterministic gate transitions, one artifact engine) hardened the harness. ## The bottom line Anyone can wrap a model in a chat box. The defensible thing is the **engine**: the artifact taxonomy, the gate model, the independence guarantees, the traceability spine, the governed-autonomy guardrails, and a growing **catalog of domain pipelines + expert role packs** that compound. Customers don't buy a chatbot; they buy a *team* and a *process* that already works — and that they can run, resell, or let run. > The harness turns "we have AI agents" into "we have a process that ships."