The layer that turns AI into a reliable worker.

The skills layer defines the agent's tool registry: which systems it can connect to, which actions it can execute, and which tasks it has the capability to complete. A harness with the wrong skills — too broad, too narrow, or pointed at the wrong systems — produces either scope creep or dead ends. Skills are scoped to the use case, not inherited from a general model configuration.

Instincts encode the agent's operating character: its tone, its decision defaults, its boundaries, and the rules it follows when a situation is ambiguous. This is where tacit organizational knowledge becomes explicit agent configuration. The most common failure in early agent deployments is not a technical one — it is that nobody has articulated how the work should be done at the level of specificity an agent requires. Instincts is where that gap gets closed.

Memory defines what the agent retains across steps and sessions: what it knows about the task in progress, what it has already tried, and what context it carries from previous runs. Without a memory layer, every session starts from zero. The agent cannot learn from its own failures within a run, cannot carry state across a multi-step task, and cannot accumulate the organizational context that makes its outputs progressively more reliable.

Memory architecture also governs in-session context management: as a task grows longer and approaches the limits of what the model can hold in context at once, the harness determines what gets compressed, what gets summarized, and what gets offloaded to external storage. An unmanaged context window produces silent degradation — the agent continues running but becomes progressively less accurate as earlier context is displaced. This is one of the hardest failure modes to diagnose in production because it does not produce an error.

Memory is one of the most commonly underbuilt layers in early production harnesses — and one of the most expensive gaps to discover after deployment.

The security layer defines the agent's permission envelope: what data it can read, what systems it can write to, what actions it can execute autonomously, and what requires explicit approval before proceeding. A general model has no permission model of its own. The harness supplies one — scoped to the use case, aligned to your data governance, and enforced at the level of individual tool calls, not just top-level access. Governance is built into the operating model, not bolted on after deployment.

The method layer defines the agent's operating procedure: how it structures a task, how it sequences steps, how it verifies its own progress, and when it escalates rather than proceeding. The method layer also defines what happens when a run is interrupted: task execution must be idempotent — interrupted runs can be resumed from the last completed step without repeating work that has already been executed. A harness that cannot safely resume is a harness that cannot safely be stopped, which in a production environment is not a recoverable property.

This is also the layer where CompanyOS harnesses connect directly to the GPDT execution method — the same artifact structure a leadership team uses to run a priority is the structure the agent uses to execute it. The method layer is what makes a harness built inside CompanyOS different from a general-purpose agent configuration: the agent is not working from a generic instruction set, it is working from the same operating model as the rest of the organization.

Authority defines the principal relationship: which person or role the agent is acting on behalf of, what that delegation covers, and when it expires. A harness without an explicit authority layer has fuzzy accountability — it has access to systems and data, but no clear answer to who authorized it to act, for how long, and within what scope. In an enterprise environment, fuzzy authority is not a governance edge case. It is the most common reason a capable agent cannot be deployed into a process that matters. Authority makes the delegation explicit, bounded, and revocable.

The oversight layer is the difference between an agent that finishes and an agent whose work can be trusted. It has four components: a verification step that checks output against an external standard before accepting it as done (an agent that self-certifies completion is not a production-grade agent); an audit trail that records every step, every tool call, and every decision; a correction path that allows a human to review, adjust, and re-run without losing context; and a kill switch that operates at multiple layers — runtime, identity, tool access — not just a prompt instruction that the model can route around. Oversight is not a control added after deployment. It is infrastructure that has to be designed in from the start.