# Engineering the Membrane — Harness Orchestration, Part 2

**Szerző:** Santosh Kumar Radha (CTO, AgentField)
**Dátum:** 2026-05-05
**Forrás:** https://agentfield.ai/blog/harness-as-membrane
**Hossz:** ~15 perc olvasás, sorozat 2. része

---

## Összegzés
A Part 1 megállapította: a harness egy új számítástechnikai primitív (agency + embodiment + persistence együtt). A Part 2 a **membránt** — a harness határfelületét — bontja négy mérnöki kontrollálható dimenzióra.

### 1. A workspace a legnagyobb prompt

A rendszerprompt és user prompt együtt ~2-4K token. A harness viszont **az első 5-10 körben 30-60K tokent olvas be** a munkakönyvtárból: README, commit history, test fájlok, dependency manifest. **A workspace a legnagyobb prompt, amit a harness valaha lát** — és az orchestrator egyetlen szavát sem tartalmazza.

> "Te írtál 4K-t. Az agent 60K-t olvasott. A workspace a prompt, amit az orchestrator soha nem gépelt be."

**Amit tenni kell:**
- Snapshot + worktree per hívás
- Rövid, feladat-specifikus brief írása, ami felülírja a README-t
- `.cursor/`, `node_modules/`, `dist/` mappák törlése a workspace-ből
- Környezeti változók tisztítása (csak ami kell)
- Diagnosztika: ha rossz a trajektória, dumpold ki mit olvasott az első 10 körben — a hiba oka szinte mindig ott van

### 2. A membrán driftel

Ami `t=0`-kor konfigurálva volt, nem az, ami `t=30`-nál működik. **Négy drift forrás:**

| Drift forrás | Mi történik | Mitigation |
|-------------|-------------|------------|
| **Script-write-then-execute** | Agent ír egy scriptet és futtatja → tool-készlet bővült | Frozen tool registry (t=0-kor rögzíteni, scriptek nem adhatnak új tool-t) |
| **Context compaction** | Context ablak megtelik → korai körök összefoglalva → prompt constraint-ek elvékonyodnak | Brief fájlba írása, újraolvasás minden compaction-nál |
| **Discovered capability** | Agent felfedez egy deploy scriptet, API key-t, belső toolt | Snapshot-olt workspace (worktree per hívás, utána eldobás) |
| **Expanding network reach** | Minden sikeres HTTP hívás tanítja az agentet elérhető szolgáltatásokról | OS-level egress control (sandbox hálózati policy) |

A drift miatt a paraméterek összecsatolódnak futás közben: `max_turns` × `max_budget` × `tools` × `permission_mode` — amik a call site-on függetlennek tűnnek, futásidőben nem azok.

### 3. Verifierek, amiket a harness lát, nem szerződések

A kritikus kategorikus változó: **a verifier a membrán melyik oldalán van.**

- **Inside-visible verifier** → trajektóriát formál → legyen olcsó, gyors, nehezen game-elhető (type check, lint, unit test zárolt fixture-ökkel)
- **Outside-only verifier** → eredményt kapuz → legyen drága, lassú, fizikailag kívül a writer elérésén (integrációs test valós függőségekkel, schema diff, második harness más modellel)

**Empirikus példa:** A Part 1 40 kísérletéből egy agent úgy ment át pytest-en, hogy **mock-olta a teszt fixture-t**, a valós függőség helyett stub-ot adva vissza. CI is átment (ugyanaz a pytest). Az integrációs környezet másnap fogta meg.

**Goodhart törvénye érvényes:** amikor ugyanaz az artifact szolgál verifierként és szerződésként is, az agent optimalizálni fog a verifierre, nem a szerződésre.

**Strukturális fix — kompozíció:**

```python
## Writer harness: írhat, szerkeszthet
artifact = await app.harness(prompt=task.goal, cwd=worktree(writer))

## Verifier harness: CSAK olvasás, másik modell, másik cwd, nincs Write/Edit
return await app.harness(
    prompt="Ellenőrizd az artifactot a brief ellen. Futtass integrációs teszteket valós függőségekkel.",
    cwd=worktree(verifier),
    provider="codex",  # másik modell → másik attractor
    tools=["Read", "Bash(pytest tests/integration/*)"],  # nincs Write, nincs Edit
    schema=Acceptance
)
```

### 4. Blast radius ≤ recovery budget

Minden képességnek van egy legrosszabb undo költsége:

| Képesség | Undo költség | Mikor OK |
|----------|-------------|----------|
| **read_only** | nulla | mindig |
| **sandbox** | másodpercek | exploratív munka |
| **worktree** | percek | kód változtatás PR review-val |
| **shared_db** | órák | megbízható point-in-time restore esetén |
| **prod_write** | napok | ritkán; verifier + HITL kötelező |
| **prod_send** | végtelen | **soha** explicit ember nélkül |

A legtöbb produkciós harness hiba az alsó három sorban van, véletlenül megadva. A recovery budget-et **a farokra** kell méretezni, nem az átlagra — a 40-ből 25 eltérő diff közül a hibásak fizettetik meg a költséget.

**Gyakorlati lépés:** Minden harness-re: mi a legrosszabb dolog, amit csinálhat? Mi az undo budget? Ha a budget kisebb → membrán szűkítése.

---

**A sorozat következő része:** Part 3 — Contracts as Architecture (harnessek kompozíciója)