Add deterministic agent context compiler

[salman1993]

Why

Agent adapters need a deterministic, auditable boundary between durable standing context, prior conversation, and the event authorizing the current turn.

What

• Compile dynamic turns into a Buzz-owned semantic envelope with <ambient-context>, a current <event author="…">, and <delivery>, while standing sections use paired domain tags such as <workspace>, <base>, and <system>
• Keep model-visible framing minimal: section position conveys instruction authority, nonessential source metadata remains manifest-only, and raw events stay available through buzz messages raw
• Publish canonical hashed context-layer manifests, report channel metadata and session-start canvas freshness separately, and incorporate accepted native steers into the completed turn record
• Escape arbitrary standing-context bodies so embedded closing tags cannot spoof boundaries; Desktop diagnostics decode them after parsing and retain legacy prompt-history compatibility

Risk Assessment

Medium — this changes ACP prompt serialization and turn telemetry, but preserves context ordering, keeps legacy observer parsing, and requires no relay storage migration.

Visualizing the change

[salman1993]

Benchmark complete. Recommendation: do not adopt PR #6503 as-is. Its efficiency gains do not preserve important Buzz-native behavior.

Suite	Baseline	Candidate	Outcome
Terminal-Bench	22/22	20/22	−2 passes
Buzz-native	12/18	8/18	−4 passes

Terminal candidate improvements were substantial: active time −32%, wall time −26%, input/output tokens −30%, and estimated cost −34%. Buzz-native efficiency changes were small (roughly 2–7%) and likely noise.

The native regression was concentrated in:

• cross-thread-requests: 2/2 → 0/2; correct answers and thread anchors, but missing human mention tags.
• multiline-message: 1/2 → 0/2; mentions omitted, with one reply posted top-level.
• narrative-agent-names: 1/2 → 0/2; callback mention/thread destination split incorrectly.
• Channel TTL, named-path reads, interleaved reports, and membership behavior were preserved.

[salman1993]

Update: lower active-h is good, but the original Terminal-Bench improvement was partially inflated by two short failed candidate runs.

Looking only at matched attempts where both conditions passed:

Suite	Baseline active	Candidate active	Change
Terminal-Bench, 20 matched passes	1,128.9 s	879.5 s	−22.1%
Buzz-native, 8 matched passes	126.6 s	126.1 s	−0.4%

For Terminal-Bench, the candidate was faster in 17/20 matched pairs. Model time fell 24.7%, output tokens fell 25.2%, and every matched run had a completion message, no exception, reward 1.0, and no failed verifier subchecks. That supports a genuine shorter successful trajectory—not an early runner exit.

The all-trial Terminal figure was −32.4%, rather than −22.1%, because:

• Failed candidate pytorch-model-recovery: 64.6 s versus passing baseline 245.1 s.
• Failed candidate regex-log: 90.1 s versus passing baseline 154.9 s.

So the accurate conclusion is:

• Terminal-Bench: candidate is genuinely faster on common successes, around 22% by summed active time.
• Buzz-native: no credible speed improvement after matching passes.
• Correctness regressions still prevent recommending the candidate as-is.