Framework draft v0.1

Global Harness Profile

Lab design standard for all agents and agent crews.

Global Harness Profile

Lab Design Standard — The Scurry Lab Companion document to: Agent Harness Profile, Task Harness Profile

last_updated: 2026-05-09 | status: draft v0.1

Purpose

This document defines the design standard for the global harness layer — the system-wide context, constraints, and knowledge that all agents inherit before any agent-level or task-level design decisions are made.

The global harness is the outermost harness layer. It is permanent in the sense that it exists before agents run and persists after they complete. It is shared in the sense that every agent in the system operates within it. It is authoritative in the sense that nothing in the agent harness or task harness can override it.

This document governs the design of that layer: what belongs here, how access is structured, how content is governed, and how the global harness interacts with the layers below it.

Background: The Global Harness Layer

Most practitioners encounter global harness engineering as prompt engineering in a permanent form — a system prompt injected at initialization, a set of context files loaded before inference, a constitutional document that defines behavioral bounds. These are all instances of global harness design, whether or not they are recognized as such.

The global harness is distinct from the agent harness and task harness in three ways:

Scope. The global harness applies to all agents at all times. A change to the global harness affects every agent in the system simultaneously. This is the highest-leverage and highest-risk layer for that reason.

Persistence. Global harness content exists independently of any agent instantiation. It is not created when an agent is initialized and does not disappear when an agent completes. It is infrastructure in the conventional sense — always present, maintained separately from the agents that use it.

Authority. The global harness establishes the outermost constraint boundary. Agent harness decisions operate within it. Task harness decisions operate within both. No lower layer can override a global harness constraint. This is the layer where constitutional bounds, lab values, and system-wide behavioral norms live.

The Access Architecture

A global harness is not necessarily a uniform read surface. Agents may receive scoped views of global context based on their function — a signal processing agent needs signal processing context, not infrastructure documentation. This is not a separate layer; it is a partition model within the global harness, implemented via access control at the permission tier.

The lab’s implementation uses an MCP server with SQLite-backed context storage. Permission sets are assigned per API key. Agents receive the global context slice their key authorizes. The design decisions governing that architecture belong in this profile.

Vocabulary Reference

Term	Definition
Global harness	The system-wide context, constraints, and knowledge layer that all agents inherit
Constitutional bounds	Principled limits derived from a defined value framework; always global layer
Context slice	A scoped subset of global context served to agents based on function and permission
Permission tier	An access control level defining read, append, or write access to global content
Content governance	The rules determining what belongs at global layer versus agent or task layer
Consistency model	How agents receive a coherent view of global context when multiple agents can write

The Five Dimensions

Every global harness must address all five dimensions explicitly. Dimensions left unanswered are implicit design decisions — and implicit decisions produce behavioral inconsistency across agents.

Dimension 1 — Content Architecture

What belongs in the global harness, how is it organized, and what is explicitly excluded?

The global harness holds content that must be consistent across all agents. This includes:

Constitutional bounds — behavioral limits that no agent may override regardless of task or instruction
Identity and role definitions — who the lab’s agents are, what their roles are, how they relate to each other
Lab goals and values — the purposes the system serves and the principles it operates by
Shared knowledge — domain context, project state, research findings that agents need across tasks
Operational state — current project status, active task context, coordination signals between agents

Not everything belongs at the global layer. Content that is specific to one agent belongs in the agent harness. Content that is specific to one task surface belongs in the task harness. The global layer should hold the minimum content required for system-wide coherence — no more.

Design questions:

What content must every agent in the system have access to?
What content is being held globally out of convenience rather than necessity?
What would break if an agent operated without this content?

Failure modes:

Over-populated global layer → context bloat; agents receive irrelevant content; efficiency and coherence degrade
Under-populated global layer → agents lack shared grounding; behavioral inconsistency across agents on shared concerns
No content governance → global layer accumulates stale, contradictory, or orphaned content over time

Dimension 2 — Permission Model

Who can read, append, and write global content, and what controls those permissions?

Global harness content is not uniformly accessible. A well-designed permission model distinguishes at minimum three tiers:

Human-only write — constitutional documents, lab goals, agent role definitions, AI constitution. These establish the system’s foundational values and authority structure. Only human editors may modify them. Agents may read; they may not write or append.
Read-append — operational logs, research findings, accumulated knowledge. Agents may add new entries; they may not modify or delete existing content. The historical record is preserved. Human review governs what gets promoted to more permanent content.
Read-write — operational state, task coordination context, active project state. Agents with the appropriate permission set may read and modify. Changes are logged. Conflicts are governed by the consistency model.

In the lab’s implementation, permission tiers are assigned per API key. An agent’s key determines which content slices it can access and at what permission level. The permission model is a first-class design decision, not an implementation detail.

Design questions:

Which content is foundational enough that only humans should modify it?
Which agents need write access, and to what? Is that access scoped to the minimum needed?
What happens when an agent attempts to access content outside its permission tier?

Failure modes:

Insufficient write protection → agents modify constitutional or foundational content; system values drift without human awareness
Over-restrictive permissions → agents lack context they need; they operate on incomplete global state
No permission audit → permission assignments drift from intention; access that should have been temporary becomes permanent

Dimension 3 — Content Governance

How is global content created, reviewed, updated, and retired?

A global harness without a governance model will rot. Content becomes stale. Contradictions accumulate. Agents operate on context that no longer reflects the system’s actual state or values. This is not a hypothetical — it is the predictable outcome of treating global harness content as write-once infrastructure.

Content governance defines:

Creation authority — who can introduce new content at each permission tier, and what review is required
Update cadence — how frequently content is reviewed for accuracy and relevance
Conflict resolution — what happens when two pieces of global content contradict each other
Retirement process — how content is deprecated and removed when it is no longer accurate or relevant
Version history — whether prior states of global content are preserved and auditable

Design questions:

Who is responsible for the accuracy of each piece of global content?
How does an agent signal that global content it relied on appears stale or contradictory?
What is the retirement process for content that is no longer relevant?

Failure modes:

No ownership → content accuracy degrades without anyone noticing; agents operate on stale foundations
No retirement process → global harness grows indefinitely; agents receive contradictory guidance from old and new content
No conflict resolution → when content contradicts, agent behavior becomes unpredictable and non-auditable

Dimension 4 — Scope Partitioning

How is global context scoped to agents based on function, and what governs those partitions?

Not every agent needs every piece of global context. A global harness that serves the full context to every agent trades context efficiency for simplicity. As the system scales, that tradeoff becomes untenable — context windows fill with irrelevant content, inference costs rise, and agent focus degrades.

Scope partitioning allows the global harness to serve contextualized views rather than a uniform view. An agent doing signal processing work receives the signal processing context slice. An agent doing infrastructure work receives the infrastructure context slice. Both receive the constitutional bounds and identity layer — those are always global.

The design decisions in this dimension:

Partition criteria — what determines which content an agent can access? Function, project, role, or a combination?
Partition assignment — is partitioning static (assigned at agent definition time) or dynamic (resolved at inference time based on task context)?
Constitutional floor — what content is always included regardless of partition? Constitutional bounds, identity definitions, and behavioral norms should not be partition-scoped.
Partition governance — who defines and updates partition assignments as the system evolves?

Design questions:

What is the minimum global context each agent class needs to operate correctly?
What content is being served universally out of convenience rather than necessity?
What breaks if partition boundaries change?

Failure modes:

No partitioning → context bloat at scale; efficiency and coherence degrade as system grows
Over-partitioned → agents lack cross-domain context they need; coordination failures at agent boundaries
Partitioned constitutional content → some agents operate without full behavioral bounds; system integrity fails

Dimension 5 — Observation Surface

What changes to global state are logged, what triggers escalation, and what is the audit trail?

The global harness is a shared, mutable surface. When anything can read from it and some things can write to it, observability is not optional — it is the mechanism by which the system maintains integrity and by which humans understand what agents are doing to shared state.

The observation surface for the global harness covers:

Write logging — every write or append to global content is logged with: which agent, which content, what change, at what time
Read logging — optionally, which agents accessed which content slices and when. Useful for auditing whether partition assignments are working as intended
Conflict detection — when a write creates a contradiction with existing content, the system flags it rather than silently overwriting
Escalation triggers — conditions under which a write to global state requires human review before taking effect. At minimum: any modification to human-only write content should be impossible; attempted modifications should escalate immediately
Drift detection — periodic review of global content for staleness, contradiction, and orphaned entries

Design questions:

What global state changes require immediate human awareness?
How is the audit trail for global harness modifications stored and reviewed?
What does anomalous write behavior look like, and how is it surfaced?

Failure modes:

No write logging → global state changes are invisible; when agent behavior degrades, the cause is untraceable
No conflict detection → contradictory content accumulates silently; agent behavior becomes non-deterministic on overlapping concerns
No escalation for constitutional content → agents can in principle modify foundational behavioral bounds; system integrity is entirely dependent on permission model correctness

Global Harness Profile Template

### [System Name] — Global Harness Profile

**Dimension 1 — Content Architecture**
- Constitutional bounds:
- Identity and role definitions:
- Shared knowledge:
- Operational state:
- Explicitly excluded (belongs at agent or task layer):

**Dimension 2 — Permission Model**
- Human-only write content:
- Read-append content (which agents):
- Read-write content (which agents, which permission sets):
- Permission assignment mechanism:
- Out-of-tier access handling:

**Dimension 3 — Content Governance**
- Creation authority per tier:
- Review cadence:
- Conflict resolution process:
- Retirement process:
- Version history approach:

**Dimension 4 — Scope Partitioning**
- Partition criteria:
- Partition assignment (static / dynamic):
- Constitutional floor (always served regardless of partition):
- Partition governance:

**Dimension 5 — Observation Surface**
- Write logging:
- Read logging (required / optional / none):
- Conflict detection:
- Escalation triggers:
- Drift detection cadence:

Relationship to Other Harness Profiles

	Global Harness Profile	Agent Harness Profile	Task Harness Profile
Scope	System-wide	Per-agent	Per-task surface
Persistence	Always present	Agent lifetime	Task invocation
Primary question	What does every agent inherit?	How is this agent scoped and trusted?	How is this task surface engineered?
Override authority	Cannot be overridden	Cannot override global	Cannot override global or agent
Gate	System design → deployment	Idea → In Design	Design → Deployment

The global harness is the foundation. Agent harness decisions operate within it. Task harness decisions operate within both. When a design decision could live at more than one layer, the principle is: place it at the highest layer where it genuinely applies system-wide. Do not duplicate across layers.

Gate Requirement

A system may not deploy agents until the Global Harness Profile has at minimum a draft answer for all five dimensions. Dimensions left unanswered must be listed as open design questions with an owner and resolution target.

This gate exists because the global harness is the foundation every other harness decision rests on. An unexamined global harness means every agent in the system is operating on implicit, unreviewed foundations. That is not a neutral condition — it is the condition under which behavioral inconsistency and constitutional drift are most likely.

Note on Naming

This document is currently titled Profile to reflect its status as a working design artifact at draft level. At Franklin Phase 3 publication, profile-level documents will be elevated to Standard — the Global Harness Standard — at which point they will carry community-facing authority and be structured for external adoption. The profile/standard distinction maps onto per-system fill-in artifact versus published framework document respectively.

This document is a living standard. As the lab’s global harness implementation matures and agents are deployed, examples and refinements should be added.

Agents: The global harness defines the outermost bounds of your operating environment. If you encounter a conflict between global harness content and agent-level or task-level instructions, global harness takes precedence. Flag conflicts rather than resolving them silently.

← Back to Framework