Position paper
The Agent Delivery Harness
A seven-invariant conformance profile for accountable delivery above one or more model runtimes.
A field guide for AI systems that can answer for their work.
Start with the responsibility you own now. Move across the guide as the system crosses from technique to capability, execution, and trust.
Four responsibilities, one delivery system.
84 core content pages, excluding product projections: 24 patterns; 9 capability overviews plus 36 implementation lenses; and 15 Harness and Security chapters.
If the vocabulary is the blocker, begin here.
Start is a plain-English on-ramp, not a fifth pillar. It decodes the terms and core mental models, then hands you into the deeper guide when you are ready.
Enter through the decision in front of you.
The pillars are peers, but they do different jobs. Each row names the question it answers, its boundary, and the shortest useful starting paths.
24 patterns across 6 chapters
What repeatable move solves this class of problem?
Use the pattern language when the problem is how to frame, decompose, steer, verify, or recover the work.
Portable techniques for shaping work with coding agents. Not vendor features, runtime machinery, or generic productivity advice.
9 capabilities with 36 implementation lenses
Which durable capability do I need, and how do products implement it?
Start with the engineering capability, then inspect documented behavior and product-specific implementation details.
Capability pages compare documented product behavior. Deep implementation lenses retain product-specific examples where portability would be misleading. Documentation evidence is not runtime conformance evidence.
7 chapters across runtime and delivery control
What machinery keeps the work durable, verifiable, and bounded?
Follow the machinery from the agent loop and context window to evidence, policy, and authorization above the runtime.
The machinery that turns model capability into controlled work — the runtime harness beneath a model owns its loop, context, compaction, tools, and system prompt; the delivery harness above one or more runtimes owns work, policy, evidence, and authorization. Not vendor features (Toolkit). Not portable working techniques (Patterns). Not the trust and privacy surface (Security).
8 chapters across the agent trust surface
What can leave, act, or be exploited?
Trace data, credentials, permissions, tool calls, model output, and supply-chain exposure through the system.
The privacy and trust surface of building with agents — what data leaves, what the model retains, what a tool can do on your behalf, and how an attacker turns your own context window against you. Not generic appsec. Not model alignment. The boundary between your secrets and a stateless model you do not control.
A short crosswalk across the system.
Real decisions do not stay inside one pillar. These curated paths show where one responsibility hands off to the next; they are reading routes, not dependency graphs.
How do I keep a long-running task coherent?
- PatternContext Priming
- CapabilityPersistent Memory
- HarnessCompaction & Continuity
- SecurityData & PII in Context
How do I delegate work without surrendering authority?
- PatternParallel Fan-Out
- CapabilityMulti-Agent Coordination
- HarnessDelivery Control
- SecurityPermission Architecture
How do I connect tools without widening trust by accident?
- PatternScope Fence
- CapabilityMCP Integration
- HarnessTool Result Curation
- SecuritySupply Chain & Audit
Applied in public.
The field guide names the machinery. These records show one position and one public implementation, with the evidence boundary left intact.
Public system
delivery-harness
Process-tested locally and published for inspection. Live authenticated multi-provider delivery and external acceptance remain unproven.