Eight dimensions of an iOS agent harness

The previous lesson showed one turn of the loop. This one steps back to the whole project and asks what the environment around an iOS codebase must provide for an agent to do real work in it.

To answer, the course uses a model with eight dimensions. It is a teaching model, built for this course. It is not an industry standard, and nobody certifies harnesses against it.

The eight dimensions

Dimension	What a capable environment provides	Evidence that it does
1. Repository intelligence	An understanding of targets, Swift packages, dependencies, schemes and conventions	A correct package and target map, and the right modules named as affected by a change
2. Context engineering	The project and task context a mission needs, and nothing that gets in the way	The relevant instructions and decisions reach the agent for a given mission
3. Tooling and capabilities	Reliable operations on files, Git, Xcode, tests and project-specific analysis	Tools run, validate their inputs and return structured, useful results
4. Execution control	Bounded command execution, with the right environment, scope, timeouts and output limits	Commands run in the intended macOS and Xcode setup, are bounded and leave a log
5. Governance and security	Permissions, restrictions, approval gates, protection of secrets	An unauthorized operation is blocked in a test, not merely discouraged in a prompt
6. Feedback and validation	Build, test and inspect changes, and feed failures back into the loop	Build and test results are captured, and a failure leads to a diagnosis and a correction
7. Orchestration	Decomposition of complex work, dependencies between missions, isolated agents	Dependencies and worktree boundaries are respected, and integration is deliberate
8. Evaluation and observability	Measures of quality, reliability, cost, duration and human intervention	Repeatable reports and comparable outcome metrics

These are concerns, not eight pieces of software. In a small project several of them are handled by one tool or one workflow. The permission rules of Claude Code cover a good part of dimensions 4 and 5 on their own.

What complete means

A project has a complete enough harness when an agent can take a defined mission within explicit boundaries, understand the constraints that matter, use the capabilities it is allowed, validate its changes and hand back evidence of the result.

Complete does not mean that every imaginable feature is installed. A utility app maintained by two people does not need the orchestration layer of a modular commerce app maintained by several squads. Completeness is relative to the scope, the risk and the complexity of the work you intend to give the agent. Adding a component that no mission needs makes the harness heavier, not better.

Where agents get stuck

When a run goes wrong, the cause usually falls into one of a few situations, and each one points to a dimension.

What you observe	Dimension	A Swift example
The agent guesses what you wanted	2. Context	“Add search”, with no word on case, accents or an empty query
It ignores a convention of the team	1. Repository, 2. Context	It writes XCTest in a codebase that uses Swift Testing
It spends the session repairing its setup	4. Execution control	A missing xcconfig, or a scheme that does not build from the command line
It announces success on code that fails	6. Feedback	No test command was given, so nothing contradicted it
The next session starts from zero	2. Context	Yesterday’s decisions lived only in the conversation
It does something you never asked for	5. Governance	It edits the project file, or pushes a branch
Two agents produce branches that disagree	7. Orchestration	Both changed what a shared type means
You cannot say whether last month’s change helped	8. Evaluation	Nothing was measured before or after

None of these lines blames the model. In each case the model did what it could with what it had. Switching to a larger model is the expensive answer, and often the wrong one. If the same model succeeds on a similar task that was better prepared, the model is not what failed.

A short log builds the habit. For each task, note whether it succeeded and, when it did not, which dimension was missing. After ten lines a pattern shows, and that is where an hour of your time pays most.

Four maturity levels

To talk about where a project stands, the course uses four levels. Like the dimensions, they are a teaching aid and not a certification.

Level	Name	What it looks like
1	Prompt-driven	The agent gets task prompts and ad hoc instructions, and a person supervises every step.
2	Configured	Repository instructions, reusable skills, conventions and useful tools are in place.
3	Governed	Execution boundaries, permissions, automated validation and feedback loops are integrated.
4	Measured	The environment is evaluated systematically, with observability, repeatable runs, outcome metrics and deliberate orchestration where needed.

The levels describe a progression, and real projects are uneven. A codebase can have strong validation and no observability at all. So an assessment records a level per dimension rather than one label for the whole project.

Read your own harness

Take the project where you use an agent today and give each dimension a level from 1 to 4. Leave a line empty when you do not know, since an empty line is a finding too.

Dimension	Level today	What would move it up one step
1. Repository intelligence
2. Context engineering
3. Tooling and capabilities
4. Execution control
5. Governance and security
6. Feedback and validation
7. Orchestration
8. Evaluation and observability

Keep the table. You will fill it in again at the end of the course, and the difference between the two is the measurable result of the sixteen hours.

The next lesson follows one mission through such an environment, from the moment an agent reads the task to the moment it hands back evidence.

Sources

• Learn Harness Engineering, WalkingLab, MIT license. The failure situations and the failure log are adapted from its first two lectures.