A Tour of the Four Primitives

I told you the space between the models is where it breaks. I never told you what lives there. Four primitives do. Here they are.

The parts list I owe you

Last issue I made a claim and left it hanging. The thing that actually breaks in production agent systems is not the model, it is the space between the models. Fine. But "the space between" is not something you can build against. It is a gesture.

So here is the design. The AOS Harness (open source) is built on four primitives: agents, skills, domains, and profiles. Each one fixes a specific composition problem the ad-hoc frameworks hit and patch over badly.

The space between the models is not one gap. It has four moving parts.

I am going to tour all four using one decision as the running example the whole way: should our deployment agent be allowed to merge and ship to production on its own, and for which change-classes? Keep that question in your head. It is a real council question. Ambiguous, no industry consensus, and it lives exactly where Issue 1 said these systems die, at the deploy boundary.

Agents: put the disagreement in on purpose

Start with the failure. One model, one prompt, seven roles in the system message, all told to "collaborate." What you get back is one voice wearing seven hats, and it agrees with itself every time. That is not deliberation. It is a mirror with good lighting.

An agent is the fix. It is a persona with a defined bias, a temperament, and an evidence standard, each written into its own file. The harness holds it to that stance.

For the auto-deploy decision you want at least two specialists in the room who do not want the same thing. Catalyst pushes velocity. Sentinel guards blast radius. Here is Catalyst, minimal:

schema: aos/agent/v1
id: catalyst
name: Catalyst
role: "Acceleration and monetization strategist. Pushes for commercial velocity, revenue capture, and shipping speed."
cognition:
  core_bias: speed-and-monetization
  risk_tolerance: moderate
  default_stance: "I want a version customers will pay for in 90 days."
persona:
  evidence_standard:
    convinced_by:
      - "Revenue data, conversion metrics, or willingness-to-pay signals from real users"

Sentinel is the counterweight: a protection-and-durability bias, convinced by change-failure rate and time-to-recovery, not by how fast the pipeline moves. Put those two in a room and the disagreement is structural. You are assembling two specialists that cannot help but pull against each other.

Skills: the moves an agent already knows

Next failure. Every time an agent needs to review code or scan for a vulnerability, you re-describe the whole procedure inline, in that prompt, for that run. Do it in ten places and you have ten slightly different definitions of "review this," drifting apart quietly.

A skill is a reusable capability an agent can invoke, each defined once in its own skill.yaml. They live under `core/skills/`; two of them are code-review and security-scan. Here is code-review:

schema: aos/skill/v1
id: code-review
name: Code Review
description: "Reviews code artifacts against quality standards and security best practices"
input:
  required:
    - id: code_artifact
      type: artifact
output:
  artifacts:
    - id: review_report
      format: markdown
compatible_agents: [sentinel, architect, operator]
platform_bindings:
  claude-code: "superpowers:requesting-code-review"

security-scan sits right beside it with the same shape. Note compatible_agents and platform_bindings: the skill declares who can pick it up and what real platform capability it maps to.

Domains: the field the argument happens in

Third failure. Your agents deliberate in a vacuum. They give you competent, generic advice because nobody told them what counts as evidence in your field. So you paste the same page of context into every single run.

A domain pack supplies that context, and the field's evidence standards, once. For the auto-deploy decision the domain is platform-engineering, and it ships the exact metrics the argument turns on:

schema: aos/domain/v1
id: platform-engineering
name: Platform Engineering Context
lexicon:
  metrics:   # excerpt; the file carries more, with fuller wording
    - "deployment_frequency: a key DORA metric"
    - "change_failure_rate: % of deploys that degrade service or need rollback (a DORA metric)"
    - "MTTR: mean time to recovery after a production incident"
overlays:
  catalyst: ...   # per-agent overlays sharpen each perspective for this field

Now Catalyst's velocity argument has deployment_frequency to cite, and Sentinel's caution has change_failure_rate and MTTR. Same agents, sharper argument, because the domain gave them a shared vocabulary and a shared bar for proof. The overlays block is the mechanism. It tunes each perspective for the field without rewriting the agent.

Profiles: the assembler

Last failure, and the one Issue 1 named. In most frameworks the logic that decides which agents show up, in what pattern, held to what standard, lives in orchestration code. Rewritten per use case, reused never. Every new decision starts from an empty file.

A profile is that assembly made a first-class thing. It names the orchestrator, selects the agents, and adopts a workflow pattern. It does not invent evidence standards of its own. Those live on the agents (you saw Catalyst's evidence_standard) and on the domain's overlays; the profile only decides which of them get a seat. Here is strategic-council, minimal:

schema: aos/profile/v1
id: strategic-council
assembly:
  orchestrator: arbiter
  perspectives:
    - agent: catalyst
      required: true
    - agent: sentinel
      required: true
    - agent: architect
      required: true
    - agent: provocateur
      required: true
      structural_advantage: speaks-last
    # plus optional: navigator, advocate, pathfinder,
    #   strategist, operator, steward, auditor (each required: false)
delegation:
  default: broadcast
  tension_pairs:
    - [catalyst, sentinel]     # velocity vs blast radius
output:
  format: memo

Read what it does. Under assembly it names the orchestrator (arbiter) and lists its perspectives: four required, the rest optional, with provocateur set to speak last. It marks catalyst and sentinel as a tension pair (velocity versus blast radius, the exact fault line in our decision), and fixes the output as a memo. The agents, skills, and domain are ingredients. The profile is the recipe that turns them into a council pointed at one question.

How the four compose

Here is the whole thing in one picture:

                    ┌───────────────┐
                    │    PROFILE    │
                    └───┬───┬───┬───┘
             selects    │   │   │   draws on
             ┌──────────┘   │   └──────────┐
             │       draws on│             │
             ▼              ▼              ▼
       ┌──────────┐   ┌──────────┐   ┌──────────┐
       │  AGENTS  │   │ DOMAINS  │   │  SKILLS  │
       └────┬─────┘   └──────────┘   └────▲─────┘
            │              invoke          │
            └──────────────────────────────┘

the profile is the assembler; the other three are what it assembles or draws on.

Look at the edges. The profile is the only node connected to all three others. Agents get selected by it, domains and skills get drawn on by it, and agents in turn invoke skills. Take the profile out and you do not have three-quarters of a system. You have a parts bin. Agents with nobody to convene them, skills with nobody to call them, a domain with nobody to read it.

The costume

Notice what every one of those four blocks had in common. A schema: line and some YAML. All four fit inside config. That is the costume, and I am coming back for it.

Because here is the trap, and it is the whole reason ad-hoc frameworks miss the profile. When something can be written as a config file, people assume it is one. They build their agents and their orchestration code and skip the assembler entirely. A framework without primitives is a pile of prompts with good posture. It looks like architecture. It composes like a script.

The profile is the primitive that makes the other three reusable instead of rebuilt. That is the one thing to carry out of this issue: the assembler. The other three are what it assembles. There is more in the docs when you want the full shape.

Enough diagrams. In two weeks we install the harness, point strategic-council at one real decision, should the agent ship to prod on its own, and read what comes back.