Tessl Academy Agent Enablement Curriculum
Reference

The three engineering disciplines

Context, harness, and loop engineering — the three layers where you can improve a coding agent, and how they relate.

When you want a coding agent to behave better, there are three places you can intervene: the context the model sees, the harness around it, and the loop that drives them both. Each is its own discipline with its own tooling, its own measurement, and its own failure modes.

Naming them separately matters because most agent issues are mis-diagnosed at the wrong layer. "Skills don't fire reliably" is usually a context problem, not a model problem. "The agent burns through tokens" is usually a loop problem, not a context problem. Getting the layer right gets the fix right.

1. Context engineering

What the model sees on each turn.

The model has no memory of its own. Every turn, the harness re-assembles a fresh prompt: a system message, your latest user message, the conversation so far, plus any files, rules, skills, and tool results the harness has decided are relevant. Context engineering is the discipline of getting that assembly right.

What you control here:

  • System prompts — the preamble the harness injects at every turn.
  • Skills — short, description-routed bundles of instructions and examples that load only when relevant. The primary subject of this curriculum.
  • Rules files — CLAUDE.md, AGENTS.md, Cursor rules; always-on context for a repo or session.
  • Retrieval — files the harness fetches based on the user's prompt (often via embedding similarity).
  • Examples — input/output pairs that show the model the desired shape of an answer.

Common failure modes:

  • Too much context, lower quality. Every additional token displaces something. A 5,000-line CLAUDE.md is doing damage, not help.
  • Wrong context, confident answers. The model will use whatever it's given. Out-of-date docs produce confident, wrong answers.
  • Missing trigger. A skill whose description doesn't match the user's actual phrasing will never fire. The skill is fine; the routing is wrong.

This is where Tessl spends most of its product attention today. The foundations of this curriculum are essentially a context-engineering course.

2. Harness engineering

The program around the model.

The harness is everything the model is not: tool definitions, output parsing, permission gates, session storage, MCP server registration, the rules that decide whether to auto-run a command or ask the user first. Two agents using the same model can produce wildly different output because their harnesses differ.

What you control here:

  • Tool selection. Which tools the harness exposes; what their descriptions say; which ones are described as preferred.
  • Permissions. Auto-approve, ask-each-time, deny-by-default. The same skill is dangerous or safe depending on this setting.
  • MCP servers. External tool servers the harness connects to. tessl init registers Tessl's MCP server with your agent so installed skills are discoverable.
  • System instructions. Behavioral guidance baked into the harness itself, separate from anything you write.
  • Output parsers. How the harness interprets diffs, code blocks, file paths, tool calls.

Common failure modes:

  • Right context, no way to act. The skill says "run git diff" but the harness doesn't expose a shell tool. Nothing happens.
  • Tool name confusion. Two tools with overlapping descriptions; the model picks the wrong one consistently.
  • Hidden system prompts. The harness's own instructions contradict your skill. Hard to debug without harness logs.

Tessl operates here through tessl init (MCP registration) and agent-specific sync formats (.claude/skills/, .cursor/rules/).

3. Loop engineering

How multi-turn execution converges — or doesn't.

A user request can trigger many round-trips: the model calls a tool, sees the result, calls another, refines its answer, asks a question, makes an edit. Loop engineering is the discipline of making this cycle converge cheaply and reliably.

What you control here:

  • Planning structure. A skill body that lists steps explicitly is doing loop engineering: it tells the model what "done" looks like.
  • Self-correction prompts. Asking the model to review its own output before stopping.
  • Tool descriptions. Better descriptions mean fewer wrong tool calls per turn.
  • Iteration caps. Hard limits that prevent runaway cost.
  • Evals. The measurement layer for loop health. Did it converge? In how many turns? At what cost?

Common failure modes:

  • No convergence. Model keeps trying alternatives. Usually a context problem upstream: it doesn't know what success looks like.
  • Tool-call thrash. Same tool, same arguments, over and over. Often a sign the tool description is ambiguous.
  • Premature stop. Returns an answer before doing the work. Skill bodies that list steps explicitly fix this.
  • Cost blowout. Loop runs longer than expected and burns tokens. Eval traces show where the iterations went.

This is where task evals live. Evals don't just measure correctness; they measure how the loop behaves.

How the disciplines relate

The three layers are tangled in practice. A bad fix at the wrong layer can mask the real problem:

Symptom Looks like Often actually is
Skill doesn't fire Context (description tuning) Harness (routing) — or a different skill is matching first
Output is wrong Context (skill body) Loop (didn't iterate to convergence)
Same prompt, different output Model (randomness) Context (different files were retrieved this time)
Burns through tokens Loop (iteration cap) Context (no clear success criterion in the skill)

Diagnosing well means asking which layer the change should land at before making it.

Where Tessl operates today

Discipline Tessl tooling
Context engineering Skills, plugins, the registry, tessl install, review evals
Harness engineering tessl init, agent-specific sync, MCP server
Loop engineering Task evals, scenarios, eval gates

Most of this curriculum sits in context engineering. The harness layer is where the platform's plumbing lives; the loop layer is what evals measure. Knowing which layer a given improvement targets is what makes the work tractable.

Where to go next