A language model can produce a convincing answer. An agent has to remain useful after the first answer: it needs to understand its environment, choose an action, recover from failure and leave the system in a state we can trust.

A model can answer. A system has to act.

The model is only one part of the loop. The moment software reads private context, calls a capability or changes persistent state, the quality of the answer stops being the only measure that matters.

Now the system needs boundaries. It needs to know what the person is trying to accomplish, which information is current, which actions are allowed and what should happen when reality disagrees with the plan. A better model can help, but it cannot replace those decisions.

The harness is the product

The harness decides what the model can see and do. It shapes context, exposes capabilities, carries memory, applies policy, records traces and determines how work is resumed or repaired.

This is where an impressive demo becomes dependable software. Reliability comes from the quiet structure around the model: explicit state, small contracts, observable execution and recovery paths that do not depend on the model improvising perfectly every time.

MCP is a boundary, not the brain

MCP is useful because it gives capabilities a clear transport boundary. It can make tools discoverable and interoperable without forcing every integration to invent its own language.

But a transport should not become the agent’s internal worldview. The intelligence layer still needs its own durable concepts for intent, context, policy and execution. Keeping that separation lets the system evolve without confusing how a capability is reached with what the capability means.

What Artemis is teaching me

I am building Artemis as an AI-native operating workspace. The work has pushed me to separate the experience people touch, the intelligence that plans, the world of available capabilities and the shared grammar that keeps those layers coherent.

That separation is not architecture for its own sake. It lets each layer change at a different speed. The interface can become calmer, the runtime can become more reliable and the capability fabric can expand without turning the whole product into one inseparable prompt.

Writing the underlay

Underlay is the name I use for the work beneath the visible product. It is not a company façade. It is the collection of systems, experiments and decisions that make Artemis possible.

These notes are where I make that work legible. I will write about agent harnesses, MCP, memory, capability design and the ideas that appear while building—especially the ones that are not finished yet, but are clear enough to test.