# Why a Specialized Agent Is Just an 8-File Preconfigured Harness Component Pack

Published: 2026-10-18 | Domain: https://getagentfoundry.si | Catalog: https://agents.baltor.ai

## Outcome first: portable specialization without fine-tuning model weights

Teams often assume that building a specialized agent for 3D WebGL geometry, statutory compliance screening, or distributed-systems verification requires either fine-tuning a model checkpoint or writing a bespoke orchestration daemon. In our Harmony study ([harmony.baltor.ai](https://harmony.baltor.ai) and [agents.baltor.ai](https://agents.baltor.ai)), we proved that a domain-specialized agent is completely determined by an **8-file preconfigured harness component pack** mounted around a fixed open-weight or frontier model.

## The canonical 8-file pack layout

Every task agent published on `getagentfoundry.si` (and indexed across `foundry.baltor.ai` and `agentfoundry.si`) ships as a deterministic directory containing eight files with strict byte budgets:

| File Name | Max Budget | Architectural Role in the Six-Part Harness |
| :--- | :--- | :--- |
| `baltor_contract_card.json` | `<= 2,048 B` | **Context / Discovery**: Typed input/output ports, engine slot ID, refusal codes, and verifier SHA-256. |
| `AGENTS.md` | `<= 4,096 B` | **Control Loop**: Role identity, execution boundaries, and stop conditions. |
| `SKILL.md` | `<= 6,144 B` | **Context (`H_env`)**: Verified domain algorithms, mathematical formulas, and reference snippets. |
| `RULES.md` | `<= 3,072 B` | **Context (`H_gen`)**: Numbered non-negotiable invariants checked on every turn to prevent middle-rule drop. |
| `WORKFLOW.yaml` | `<= 2,048 B` | **State & Loop Graph**: Ordered Loop steps, call budget ceiling, and fallback recovery policy. |
| `TOOLS.json` | `<= 4,096 B` | **Action**: Typed tool schemas with path confinement and taint-tracking annotations. |
| `verifier.py` | Executable | **Verification (`worker != verifier`)**: Independent AST, physics, and known-wrong conformance gate. |
| `README.md` | Human docs | Setup prerequisites, what success looks like, and failure recovery steps. |

## Why factorizing `SKILL.md`, `RULES.md`, and `verifier.py` works

When instructions, domain math, and verification logic are mixed into a single unstructured system prompt, the model treats hard constraints as optional style suggestions. Separating `RULES.md` (numbered invariants) from `SKILL.md` (verified reference implementations) and enforcing `verifier.py` out-of-band ensures that no candidate output is promoted until every numbered rule passes execution.