# Context Files Are Interface Design

Source reference:

- [Principles of AX](https://agentexperience.ax/concepts/principles-of-ax/)

## What The Source Is Saying

- Agents need access, orientation, context, interaction boundaries, feedback, identity, and patterns they can follow.
- Digital services should not assume the model already has enough internal context.
- Agent-facing context needs to stay consistent with human-facing documentation.
- AX includes interactivity patterns, provenance, identity, and feedback loops.

## What Marco Takes From It

This source clarified a sentence I kept circling around:

Context files are interface design.

Not metaphorically. Practically.

When an agent opens `AGENTS.md`, `DESIGN.md`, a source file, or a task checklist, it is using a surface we designed. If that surface is vague, stale, contradictory, or too long to act on, the agent experience is bad. And the output will show it.

In the Design Harness, context is not a folder where we dump everything. It is the agent-facing product surface.

## Agents Need Orientation

A human designer can infer a lot from a product.

An agent cannot always do that.

It may not know what the product is trying to avoid. It may not know which source is trusted. It may not know that a visual style is intentionally restrained. It may not know whether a task is safe to complete or should be escalated.

So the context layer has to answer basic questions:

1. What is this product?
2. What kind of work is allowed here?
3. What sources matter?
4. What design rules are non-negotiable?
5. What output format is expected?
6. When should the agent stop?

That is not bureaucracy.

That is wayfinding.

## Context Is Not A Dumping Ground

The easiest mistake is to add more documents.

More docs do not automatically create better context. Sometimes they create fog.

Good context is shaped. It has hierarchy. It has purpose. It tells the agent what to do with the information and where that information belongs.

This is why I keep separating source material from working rules.

A source file can hold evidence. A rule file tells the agent how to behave. A skill tells the agent how to run a repeatable workflow. A checklist tells the agent what proof is needed before the work counts.

Different surfaces. Different jobs.

## Lab Example

The design-system Lab makes this concrete.

The task does not begin with "make this better." It begins with routing. What kind of work is this? Which skill applies? What project folder holds the brief, sources, findings, and decisions? What design-system files must be respected? What audit gate runs before the work is shared?

That is context as interface.

The agent is not wandering around the repo hoping to find meaning. The Harness gives it a path.

## Harness Artifact

### Context File Anatomy

Each context file should have a clear job:

| File | Job |
| --- | --- |
| `AGENTS.md` | global working rules, constraints, verification expectations |
| `DESIGN.md` | taste, design intent, visual rules, anti-drift standards |
| `brief.md` | what this task is trying to achieve |
| `sources.md` | where evidence comes from |
| `findings.md` | what has been learned |
| `decisions.md` | what a human has decided |
| `log.md` | what happened and what changed |

Good context files do not only store information.

They orient the next action.