The Model

Most teams talk about “AI agents” as a single thing. FIT does not.

Three layers, three vocabularies, three different rates of change.

Provider, harness, persona

Layer	What it is	Examples	Who owns it
Provider	The model behind the response	Claude · Codex (GPT) · Kimi · Qwen · open weights	The provider company
Harness	The orchestrator that runs the agent loop	Claude Code · Archon · GSD · Paperclip · OpenFang · n8n · Cursor · Windsurf	The harness company
Persona	The durable FIT identity	Quinn · Sage · Phoebe · Ivy · Maya · Clio · Nico · Sam · Rex	FIT

A persona is loaded into a harness, which calls a provider. None of the three has authority over the others. They compose.

FIT is provider-agnostic and harness-agnostic. The persona — and the constitution that defines it — is the part FIT owns.

Swap the provider and the persona stays. Swap the harness and the persona stays. Quinn is Quinn whether she answers through Claude Code on Sonnet 4.6, through Archon on Opus 4.7, or through a future harness running a future model.

Why the distinction matters

Without it, “agentic AI” collapses into provider lock-in or harness lock-in or both. Move providers and your agents lose their voice. Move harnesses and your workflows break.

FIT’s claim — and the part of the operating model worth showing to investors and partners — is that the persona is the durable asset. Built once. Audited centrally. Re-expressed on whatever stack is right for the task.

The three context layers (ADR-002)

When a FIT persona is expressed in a harness, three context layers assemble into the system prompt. Each layer has a fixed location. Each layer has a different rate of change.

+-----------------------------------------------------+
|  Layer 1 — fit-solutions (the constitution)         |
|  Brand · Registry · ADRs · Skills (canonical files) |
|  Changes: rarely, via accepted ADR                  |
+-----------------------------------------------------+
                        |
                        v
+-----------------------------------------------------+
|  Layer 2 — repo `.agent/CONTEXT.md`                 |
|  Repo purpose · boundaries · `declared skills:`      |
|  Changes: when the repo's scope changes             |
+-----------------------------------------------------+
                        |
                        v
+-----------------------------------------------------+
|  Layer 3 — declared skill files                     |
|  Only the skills listed in `declared skills`         |
|  load. Undeclared skills are invisible.             |
|  Changes: per-task, per-repo                        |
+-----------------------------------------------------+

Layer 1 is the constitution. Brand rules, registry entries, accepted ADRs, and every skill file FIT has ever written live in fit-solutions. No agent invents policy that contradicts what lives there.

Layer 2 is the repo. Every repo in the FITAutomate org has a .agent/CONTEXT.md file that extends the constitution. It states the repo’s purpose, its boundaries, and a single declaration:

declared skills:
  - prp
  - brand-check
  - astro

Layer 3 is what loads. If a skill is not declared, the agent cannot see it. This is intentional. The surface is small on purpose — a small surface makes behaviour predictable.

Current Model — daily drivers

Two harnesses run FIT day-to-day:

• Archon — guided PRP/PIV development. Runs implementation, validation, and PR flows against FIT codebases: issue triage, fixes, multi-repo audits, env checks.
• Hyperagent — operations. Runs FIT personas against HubSpot, Airtable, Microsoft 365, Slack, and GitHub: briefings, coordination, launch ops, content drafts, brand checks.

Active for some workflows, evaluating for others. Both harnesses consume the same agent registry — same name, role, and authority — regardless of which one expresses them on a given task.

What this gives FIT

• Provider portability — pricing, throughput, and capability shift quarter to quarter. The persona doesn’t notice.
• Harness portability — Claude Code today, Archon tomorrow, something new the day after. Same Quinn, same Sage.
• Determinism through scope — declared skills only. The agent cannot drift into capabilities it was not given.
• Audit by reading files — git log fit-solutions/ is the org’s decision log. Every change to brand, registry, or ADR is in there.

Where the personas live

Every FIT persona has a folder under private Vault agent folder\. Inside that folder:

• soul.md — stable identity, voice, working style, boundaries
• memory/ — durable facts learned across sessions, organized by topic
• skills/ — capability bundles loaded by relevance
• notes/ — session records and handoff trails

A persona without a soul file is not a persona. It is an unconfigured chat session.

Where the constitution lives

fit-solutions/. The full path matters because Claude Code and Archon and every other harness FIT uses can reach the same files. The constitution is on disk, not in a chat transcript.

What changes when we add a new provider

A line in the harness config. Nothing in the persona. Nothing in the constitution.

What changes when we add a new harness

A copy of the persona’s soul file, a pointer to fit-solutions, and the harness’s local agent context format. The persona stays the same.

What changes when a persona changes

An entry in agents.yaml and a commit to the soul file. The change is reviewed. If the change affects org structure or decision authority, an ADR is opened in fit-solutions/decisions/.

Next

Walk through Agent Onboarding — the five-step path every persona takes when loaded into a new harness.