Agent Harness Profile
Lab design standard for all agents and agent crews.
Agent Harness Profile
Lab Design Standard — The Scurry Lab Companion documents: Global Harness Profile · Task Harness Profile
last_updated: 2026-05-09 | status: draft v0.1 previously titled: Harness Design Profile
Purpose
This document defines the design standard for all agents and agent crews in the lab. Every agent — from core infrastructure to project crews — must have an explicit Agent Harness Profile before moving from Idea to In Design status.
The profile serves two purposes:
-
Internal design discipline. Forcing answers to five axes of harness decisions makes implicit choices explicit. Underspecified agents produce unpredictable behavior. This standard prevents that.
-
External communication. The same five axes translate into plain language for the lab’s public-facing work. The lab’s thesis — that human-AI teaming can be intentional, bounded, and demonstrably positive — lives in how these decisions are made and communicated.
Background: What Is Harness Engineering?
AI systems can be shaped from two directions:
- Inner layer — working on the model itself. Fine-tuning, training, activation steering, mechanistic interpretability. The weights change.
- Outer layer (harness) — shaping model behavior from the outside. Prompts, context, tool access, memory architecture, agent orchestration, routing logic, trust boundaries. The model weights don’t change; the environment the model operates in does.
This lab works at the outer layer. That is not a limitation — it is where almost all practical AI deployment lives, and it is where the most consequential design decisions are made. Scaffolding determines what models can reach, what they remember, what they can affect, and when humans stay in the loop.
The term scaffolding is precise: in biology, a scaffold provides structure that enables self-organization without dictating the outcome. The cells do the work; the scaffold creates the conditions. Harness engineering is the design of that scaffold for AI systems.
The Four Harness Layers
The outer layer is not monolithic. Harness engineering operates across four distinct architectural layers. This document governs the second layer — the agent harness. It operates within the global harness and above the task harness.
| Layer | Scope | Architectural position |
|---|---|---|
| Global Harness | System-wide — all agents, all tasks | Persistent shared storage; exists before agents run |
| Agent Harness ← this document | Per-agent — all tasks for one agent | Agent definition; travels with the agent |
| Task Harness | Per-task — one task surface for one agent | Task invocation; loaded when a specific task triggers |
| Infrastructure Harness | Inference boundary — transparent to agents | Between calling agent and model endpoint; active investigation |
Each layer inherits from those above it. Each addresses design questions the others cannot. The agent harness cannot override the global harness. The task harness cannot override either.
Agent harness design decisions operate within the bounds the global harness establishes. If an agent harness decision conflicts with global harness content, the global harness takes precedence. Conflicts should be flagged, not silently resolved.
Vocabulary Reference
At the Model Interface
| Term | Definition |
|---|---|
| Prompt engineering | Shaping model behavior through input construction |
| Context engineering | Managing everything in the context window — what the model sees at inference time |
| RAG | Retrieval Augmented Generation — augmenting context with retrieved information rather than relying on model weights |
At the Agent Layer
| Term | Definition |
|---|---|
| Scaffolding | The structural framework around an agent: tools, memory, routing, constraints |
| Tool use | Giving a model access to external capabilities — search, file write, API calls |
| Memory architecture | How agents store and retrieve information across time |
| Agentic AI | Systems that take sequences of actions autonomously rather than single-turn responses |
At the Multi-Agent Layer
| Term | Definition |
|---|---|
| Orchestration | Coordinating multiple agents — managing sequencing, task routing, conflict resolution |
| Crew | A coordinated team of agents with a shared goal and defined internal roles |
| Human-in-the-loop (HITL) | Human intervenes in the workflow at defined decision points — in the critical path |
| Human-on-the-loop (HOTL) | Human monitors and can intervene but is not in the critical path |
At the Constraint Layer
| Term | Definition |
|---|---|
| Guardrails | Hard constraints on model output or behavior |
| Constitutional bounds | Principled limits derived from a defined value framework; always set at global harness layer |
| Trust boundary | The scope of what an agent can access or affect |
| Escalation path | Defined conditions under which control passes to a human or higher authority |
| Pause authority | The right to suspend agent work pending human review — distinct from termination |
The Five Axes
Every agent and crew must answer all five axes explicitly. Unanswered axes are open design risks.
Axis 1 — Authority Scope
What can this agent read, write, execute, or affect? Where are the hard limits?
This axis defines the agent’s reach into the system. It should specify:
- Read access — what context, files, or data the agent can see. Note: global harness content is governed by the Global Harness Profile permission model; this axis specifies agent-level read scope within those bounds.
- Write access — what it can modify, create, or delete
- Action access — what tools, APIs, or external systems it can call
- Hard limits — what it explicitly cannot do, regardless of instruction
Authority scope interacts with autonomy level as a causal risk model: RISK = f(autonomy × authority). Wide authority with high autonomy is the highest-risk combination and requires the strongest justification. See the Authority × Autonomy Risk Matrix for the full quadrant model and trust progression path.
Design principle: scope authority to the minimum needed for the agent’s role. Wider authority requires explicit justification.
Axis 2 — Memory Model
What does this agent know, how does knowledge persist, and what is it permitted to remember?
Memory in agent systems operates at three levels:
- Episodic — what happened in past interactions (conversation history, task logs)
- Semantic — what the agent knows about the world and the lab (context files, project state). Note: semantic memory sourced from the global harness is governed by the Global Harness Profile scope partitioning dimension.
- Procedural — how to do things (task harnesses, tool definitions, workflow templates)
This axis should specify which memory types the agent uses, where memory persists, how it is updated, and whether any memory is off-limits.
Design principle: memory is a trust surface. What an agent remembers shapes what it does. Scope and audit accordingly.
Axis 3 — Autonomy Level
Where on the autonomy spectrum does this agent sit, and is that placement intentional?
Fully Autonomous ←————————————————————————→ Human-Directed
| | | |
Acts without Human monitors Human approves Human initiates
human review can intervene key decisions every action
(HOTL) (HOTL) (HITL) (HITL)Most agents sit somewhere specific on this spectrum. This axis requires naming that position explicitly and justifying it. An agent’s autonomy level should match its authority scope — wide authority with high autonomy is a high-risk combination requiring strong justification.
Autonomy should be earned through demonstrated reliability within bounded conditions. The trust progression path in the Authority × Autonomy Risk Matrix defines the designed route from constrained to expanded autonomy.
Design principle: default to more human involvement, not less. Autonomy should be earned through demonstrated reliability, not assumed.
Axis 4 — Trust Position
Where does this agent sit in the hierarchy? Who tasks it, who can override it, who monitors it?
This axis maps the agent’s relationships:
- Tasked by — who assigns work to this agent
- Reports to — who receives its outputs and is accountable for its behavior
- Overridden by — who has authority to redirect or halt this agent
- Monitored by — who watches its behavior
This axis should align with the Agent Roster interaction map. Agents whose trust position is ambiguous or unresolved are a coordination risk.
Design principle: every agent has a clear chain of authority. No agent is unmonitored. No agent self-tasks without bounds.
Axis 5 — Observation Surface
What is logged, what triggers escalation, and what is appropriately opaque?
This axis defines the agent’s visibility to the system:
- What is logged — all actions, outputs, or a defined subset
- Escalation triggers — specific behaviors or outputs that route to the Security Agent or human owner
- Opacity bounds — whether any agent activity is intentionally not logged and why
This axis is where constitutional bounds become operational. An agent with no observation surface is unaccountable. Agent-level observation connects to the global harness observation surface — write events to shared context are also governed by the Global Harness Profile Dimension 5.
Design principle: logging is not surveillance — it is the mechanism by which the lab demonstrates that its AI systems operate within defined bounds. That demonstration is part of the lab’s thesis.
Agent Harness Profile Template
### [Agent Name]
**Axis 1 — Authority Scope**
- Read:
- Write:
- Action:
- Hard limits:
- Global harness permission tier:
**Axis 2 — Memory Model**
- Episodic:
- Semantic:
- Procedural:
- Memory limits:
- Global harness context slice:
**Axis 3 — Autonomy Level**
- Position on spectrum: [Fully Autonomous / HOTL / HITL / Human-Directed]
- Justification:
- Escalation condition:
- Current quadrant (Authority × Autonomy matrix):
- Trust progression target:
**Axis 4 — Trust Position**
- Tasked by:
- Reports to:
- Overridden by:
- Monitored by:
**Axis 5 — Observation Surface**
- Logged:
- Escalation triggers:
- Opacity bounds:Gate Requirement
An agent entry in the Agent Roster may not advance from Idea to In Design until all five axes have at least a draft answer. Unanswered axes must be listed explicitly as open design questions with an owner and resolution target.
This is not bureaucracy — it is the mechanism by which the lab makes harness decisions intentionally rather than by default.
Relationship to the Four Harness Layers
| Global Harness Profile | Agent Harness Profile | Task Harness Profile | Infrastructure Harness Profile | |
|---|---|---|---|---|
| Scope | System-wide | Per-agent | Per-task surface | Inference boundary |
| Primary question | What does every agent inherit? | How is this agent scoped and trusted? | How is this task surface engineered? | What is shaped at the inference boundary? |
| Gate | System design → deployment | Idea → In Design | Design → Deployment | Active investigation |
| Override authority | Cannot be overridden | Cannot override global | Cannot override global or agent | Transparent to all layers above |
External Communication Note
These five axes translate directly into plain language for the lab’s public-facing work:
- We scope every agent’s authority to the minimum needed for its role
- We define explicitly where human judgment enters the loop
- We match autonomy level to demonstrated reliability, not assumption
- Every agent has a clear chain of authority and accountability
- All agent behavior is logged against constitutional bounds
That is a coherent, non-jargon description of what intentional human-AI teaming looks like in practice.
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 Agent Harness Standard — at which point they will carry community-facing authority and be structured for external adoption. The profile/standard distinction maps onto per-agent fill-in artifact versus published framework document respectively.
This document is a living standard. As the lab matures and agents are deployed, examples and refinements should be added.
Agents: read this file before accepting task assignments that involve agent design or crew composition. If you encounter a conflict between your agent harness and global harness content, the global harness takes precedence. Flag conflicts rather than resolving them silently.